--- name: privacy-review description: "Use when reviewing data flows, support macros, refund templates for GDPR/CCPA/HIPAA fit — regime, consent, PII redaction (email, order-id), breach triage. Triggers 'is this GDPR-safe', 'PII redact'." status: active tier: senior source: package domain: process context_spine: [regulatory-regime, customer-segment, product] recommended_for_user_types: [ops, finance, creator] workspaces: - engineering packs: - engineering-base lifecycle: active trust: level: core confidence: high human_review_required: false install: default: true removable: false --- # privacy-review ## When to use - A new feature, integration, or vendor introduces a data flow and the question is *which regulatory regime applies*, *what consent / lawful basis is required*, *what the breach-impact tail looks like*. - An existing data flow is being re-scoped (new geography, new customer segment, new processor) and the regulatory-regime delta must be read before the change ships. - A customer / counterparty requests a DPA, BAA, or SCC and the question is *what we can credibly sign* given current data-handling reality. Do NOT use as a substitute for qualified privacy counsel (this skill produces the non-lawyer cognition that prepares the counsel conversation), as a contract-level read (route to `contracts-cognition` (P5); P5 composes this skill for data-clause depth), or for privacy-platform SaaS configuration / audit-tool administration. ## Cognition cluster - **Mental model 28 — Inversion.** *"What's the worst-case if this data flow leaks, is subpoenaed, or is mis-consented?"* Inversion sizes the regulatory tail before consent / DPA shape is debated. See [`mental-models.md`](../../../docs/contracts/mental-models.md) § 28. - **Mental model 1 — First principles.** Strip the data flow to: *who* (data subject), *what* (data category), *why* (lawful basis / purpose), *where* (residency / transfer), *how long* (retention), *who else* (sub-processors). Six primitives anchor every regime delta. See `mental-models.md` § 1. - **Mental model 21 — Second-order thinking.** Consent design at signup interacts with marketing automation; retention defaults interact with data-subject-rights workflow; sub-processor chains interact with breach-notification timelines. Each privacy choice has downstream regime obligations. See `mental-models.md` § 21. - **Context-spine — regulatory-regime + customer-segment + product.** Read **regulatory-regime** (J1) for the applicable floor (GDPR, CCPA/CPRA, HIPAA, PIPEDA, LGPD, sector-specific). Read **customer-segment** for who the data subjects are (B2C-EU = GDPR primary; US-healthcare = HIPAA primary; B2B-EU-of-US-customers = mixed). Read **product** for which features touch sensitive categories. ## Cross-wing handoff - Cites J1 `regulatory-regime` (foundation slot) for the regime floor read; without J1, this skill cannot bind which regime applies. - Hands off to P5 `contracts-cognition` for clause-level redlines on DPAs / BAAs / SCCs. - Hands off to P7 `data-handling-judgment` for the classification, retention, and cross-border-transfer surface that this skill flags. ## Procedure ### Step 0: Bind the regulatory-regime floor Read the J1 `regulatory-regime` slot for the customer-segment and geography in scope. For each applicable regime, name: 1. *Which data subjects does it protect?* (EU residents → GDPR; California residents → CCPA/CPRA; US patients in covered entities → HIPAA). 2. *What categories does it gate?* (GDPR special categories; HIPAA PHI; CCPA "sensitive personal information"). 3. *What lawful-basis / consent shape does it require?* (GDPR Art. 6 + Art. 9; HIPAA authorization; CCPA notice + opt-out). Multiple regimes can apply simultaneously; the floor is the strictest applicable. ### Step 1: Map the data flow For the feature / integration / vendor in scope, enumerate every hop: 1. **Collection** — what data category, from whom, where, with what notice / consent. 2. **Processing** — who processes (us, sub-processor), where, for what purpose. 3. **Storage** — where stored (region, system), encrypted at rest, retention default. 4. **Transfer** — cross-border hops, transfer mechanism (SCC, adequacy, BCR). 5. **Disclosure** — who sees it (internal roles, third parties, government-access risk). 6. **Deletion** — retention end-state, data-subject-rights workflow, hard-delete vs soft-delete. A flow without all six hops named is not mapped; it's assumed. Force the enumeration. ### Step 2: Compute the regulatory-regime delta For each hop × each applicable regime, name the obligation: 1. **Lawful basis / consent** — what's the basis for this hop under this regime; is it documented; is it user-affirmative where required. 2. **Notice** — what notice was given at the collection hop; does it cover the downstream hops. 3. **DPA / BAA / SCC** — for each sub-processor / cross-border hop, what contract is required; is it in place. 4. **Data-subject rights** — for each hop, can we deliver access / deletion / portability / objection within the regime's window. 5. **Breach-notification surface** — what's the notification timeline (GDPR 72 h, HIPAA 60 d, CCPA varies), to whom, with what content. Gaps = obligations un-met. Surface them, don't smooth them. ### Step 3: Consent design read For each lawful-basis claim: 1. *Is the basis defensible?* (legitimate-interest balancing test documented; consent freely given / specific / informed / unambiguous; contractual necessity actually necessary). 2. *Is withdrawal as easy as granting?* (GDPR Art. 7.3; CCPA opt-out parity). 3. *Are sensitive categories handled with explicit consent / authorization?* Consent-as-checkbox-at-signup is the canonical failure mode. Inversion check: *"if a regulator inspects the consent flow tomorrow, what would they find un-defensible?"* ### Step 4: Breach-impact triage For each data category × hop, size the breach tail: 1. **Volume** — how many subjects per hop. 2. **Sensitivity** — special-category / PHI / financial / identity-document presence. 3. **Notification surface** — 72-hour clock starts when; who notifies (us as controller, vendor as processor); content requirements. 4. **Regulatory-fine exposure** — GDPR up to 4 % global turnover or €20M; HIPAA tiered; CCPA per-record statutory damages. A hop without a sized breach-tail is unstressed. ### Step 5: Validate the privacy read before emitting Before producing the artifact, verify three things: 1. **Hop coverage** — confirm all six data-flow hops (collection, processing, storage, transfer, disclosure, deletion) were inspected; silent skips mean the flow was not mapped. 2. **Regime delta completeness** — assert every applicable regime was checked for lawful basis, notice, DPA/BAA/SCC, data-subject rights, breach notification; un-checked obligations are gaps in disguise. 3. **Counsel handoff** — verify the artifact explicitly flags which findings need privacy-counsel sign-off vs which are operational decisions; this skill does not replace counsel. All three must pass. If any fails, return to the failing step. ### Step 6: Emit the privacy-review note Produce the privacy-review artifact for the feature owner, legal / counsel, and DPO if applicable. The artifact is the non-lawyer cognition that prepares the counsel conversation and gates the ship decision; it is not the legal opinion. ## Related Skills **WHEN to use this** - Reviewing a new feature / integration / vendor data flow against applicable regulatory regimes. - Re-scoping an existing flow under a new geography, segment, or processor. - Sizing the breach-impact tail before a ship decision. **WHEN NOT to use this** - Contract-clause redline depth — route to [`contracts-cognition`](../contracts-cognition/SKILL.md) (P5); P5 composes this skill for data-clause sections. - Data-classification / retention / cross-border judgment in isolation — route to [`data-handling-judgment`](../data-handling-judgment/SKILL.md) (P7); P7 is composed by this skill. - Regulatory-regime floor read in general — route to `regulatory-regime` (J1); this skill cites J1, doesn't replace it. - Legal privacy opinion — route to qualified privacy counsel. ## When the agent should load this - "Is this GDPR-safe?" - "Do we need a DPA / BAA / SCC for this vendor?" - "What's the breach exposure on this data flow?" - "Review the consent flow for the new signup." - "Wir starten in der EU — was ändert sich datenschutzrechtlich?" ## Output 1. **`data-flow-map.md`** — six hops × what / who / where / how-long / who-else per hop. 2. **`regime-delta.md`** — applicable regimes × obligations × gaps per hop. 3. **`consent-design-note.md`** — lawful-basis defensibility, withdrawal parity, sensitive-category handling. 4. **`breach-impact-triage.md`** — sized tail per category × hop; notification clock; fine exposure. 5. **`counsel-handoff.md`** — findings that need counsel sign-off vs operational decisions. ## Gotcha - "We're US-only, GDPR doesn't apply" is often wrong; GDPR follows the data subject, not the company. - Consent checkboxes pre-ticked at signup are not consent under GDPR; this is a canonical regulator-attention pattern. - Sub-processor chains drift silently; a vendor adds a sub-processor 6 months in and your DPA is stale. - Retention defaults of "forever" interact badly with data-subject-rights timelines under every regime. ## Do NOT - Do NOT issue privacy legal opinions; this skill prepares cognition for counsel, not replaces counsel. - Do NOT collapse multiple regimes into the most familiar one; the floor is the strictest applicable. - Do NOT skip breach-impact triage; un-stressed flows ship with un-sized tail. ## Runnable example Growth-stage SaaS adds an EU customer cohort; existing US-only flow now serves EU data subjects. - Step 0 — Bind regime: GDPR applies (EU data subjects); CCPA still applies for California subset; HIPAA n/a (no PHI). - Step 1 — Map flow: collection (signup, EU IP), processing (US-east region), storage (US-east + analytics warehouse), transfer (US-east → analytics vendor in US-west; analytics vendor uses sub-processor in India), disclosure (internal CS team, no third parties), deletion (soft-delete, 7-year retention default). - Step 2 — Regime delta: lawful basis missing for analytics (no opt-in); notice doesn't disclose Indian sub-processor; no SCC with analytics vendor; data-subject-rights workflow is manual ticket only; breach-notification process undocumented. - Step 3 — Consent: signup checkbox is pre-ticked for marketing — fails Art. 7. Withdrawal requires support email — fails parity. - Step 4 — Breach-impact: 12k EU subjects, no special categories, GDPR fine exposure up to 4 % global turnover; 72-hour notification clock with no documented owner. - Step 5 — Validate: six hops mapped; both regimes checked; counsel-handoff names SCC + analytics-vendor sub-processor chain + consent UX redesign as counsel-led; retention default + DSR workflow as operational. Pass. - Step 6 — Emit privacy-review note; gate EU launch on (a) SCC with analytics vendor; (b) consent UX redesign; (c) DSR workflow with named owner and 30-day window; (d) breach-notification runbook.