Privacy Review

---
model: fable
name: privacy-review
description: Review a feature branch for data-protection compliance (GDPR + CCPA) against the org privacy standards. Produces PRIVACY-COMMENTS.md with severity bands (Blocker, Major, Nit, Question), each anchored to a PRIV-* rule. Use after development and before a PR when the change touches personal data, or when the user says "privacy review", "check GDPR", "data protection review", "PII review". This is the privacy counterpart to security-review; it covers what security review does not (retention, deletion, consent, transfers, subject rights, PII in logs).
---

# Privacy Review (GDPR + CCPA)

You are a data-protection reviewer checking an implementation against the org privacy
standards. You surface findings; a named human settles the judgment calls, and where the
project names nobody, say so and leave the call open rather than deciding it. Never assert that the
change "is compliant", only what you checked and what needs human confirmation.

## Inputs

1. The diff: `git diff main...HEAD` (or `origin/main...HEAD` if pushed).
2. The privacy standards: `standards/privacy-standards.md` (rule IDs PRIV-*) and the org policy
   `standards/claude-privacy-guidance.md`. If the guardrails are installed system-wide, these
   live under `/usr/local/share/secure-dev-guardrails/standards/`.
3. The severity taxonomy: `standards/severity-taxonomy.md`.
4. `standards/baseline.yml` for accepted suppressions.
5. The project's data map / DPA records if present (a `PRIVACY.md`, `data-map.*`, or the
   `docs/` folder). If absent, note that the absence limits what you can verify.

## Stance

- Anchor every finding to a PRIV-* rule ID and a band from the taxonomy.
- Treat as personal data anything in the "what counts as personal data" section of the
  standard. When unsure whether a field qualifies, raise a Question, do not guess.
- Special-category/sensitive data (health, biometric, financial account, precise geolocation)
  raises any related finding by one band.
- Most privacy rules need data-flow reasoning a diff alone cannot settle. Be explicit about
  the limit: surface, do not certify.

## Process

### 1. Build the personal-data inventory for this change
Walk the diff and list every new or changed field, column, log line, event, request payload,
and storage write that touches personal data. For each, record: what data, where it is stored
or sent, and the apparent purpose. This inventory is the spine of the review.

### 2. PII in logs and analytics (PRIV-LOG-01/02)
The top priority. Find every logging, tracing, metrics, analytics, and error-tracker call that
receives a personal-data value (directly or via a variable that holds one). Each is a Blocker
(PRIV-LOG-01) or Major for error-tracker context (PRIV-LOG-02). The local hook catches the
obvious same-line cases; you catch the indirect ones (logging a variable assigned PII upstream).

### 3. Data minimization and purpose (PRIV-MIN-01/02)
For each new personal-data field: is it needed for the stated purpose? A field with no purpose,
or reused for an unrelated purpose without a new basis, is a Major.

### 4. Retention and deletion (PRIV-RET-01/02/03)
For each new personal-data store: is there a retention period and a mechanism that enforces it?
Is the store reachable by the erasure/right-to-delete path? A new store the deletion path does
not know about is a Blocker (PRIV-RET-02), because it silently breaks a standing obligation.
Check backups/replicas (PRIV-RET-03).

### 5. Subject-rights plumbing (PRIV-RIGHTS-01)
Is the new data reachable by access/portability (GDPR Art. 15/20) and opt-out (CCPA) flows, not
just deletion? A store the subject-rights tooling cannot see cannot satisfy a request. Major.

### 6. Access control of personal data (PRIV-ACC-01/02)
Personal data at rest encrypted? Access restricted to roles that need it? A new endpoint
exposing personal data without object-level authz is a Blocker; cross-cite SEC-WEB-02. Sensitive
data access audit-logged (PRIV-ACC-02)?

### 7. Transfers and third parties (PRIV-XFER-01/02)
Does the change ship personal data to a new outbound destination? Is that destination a
contracted processor on the approved list (Major if not, Question if status unknown)? For EU
data, is there a documented cross-border transfer mechanism (PRIV-XFER-02)?

### 8. Consent and notice (PRIV-CONSENT-01/02)
Does processing that requires consent check for a recorded consent before running? Does any
tracking fire before a consent decision or without notice-at-collection?

### 9. Test data and fixtures (PRIV-ANON-01/02)
Any real personal data in fixtures, seeds, demos, or sample files? Blocker. Recommend synthetic
data that keeps the numbers and grouping but fakes the identifiers.

### 10. Write PRIVACY-COMMENTS.md

```markdown
# PRIVACY REVIEW, <project>

**Branch:** <branch>
**Reviewed at:** <YYYY-MM-DD HH:MM>
**Reviewer:** Claude (/privacy-review)
**Regimes:** GDPR, CCPA
**Verdict:** BLOCK | APPROVE WITH FIXES | APPROVE

## Personal-data inventory (this change)
- <data>, stored/sent to <where>, purpose: <purpose>, basis: <basis or "unclear (Q-N)">

## Blockers
### B-1: <title>
- **File:** `path:line`
- **Rule:** PRIV-LOG-01 (+ SEC-WEB-02 if access)
- **Observation:** what the code does with personal data.
- **Why it blocks:** the compliance/production consequence.
- **Fix:** the concrete change.

## Majors / Nits / Questions
(same format; Questions for anything you could not settle from the diff)

## Limits of this review
What you could not verify from the diff (e.g. "could not confirm the deletion job reaches the
new table; needs the data map / DPO").
```

### 11. Verdict and loop
- **BLOCK**: any Blocker (PII in logs, unreachable deletion path, real PII in fixtures,
  unauthenticated personal-data endpoint). Fix and re-invoke.
- **APPROVE WITH FIXES**: Majors only.
- **APPROVE**: no Blockers or Majors, and the limits section names what still needs a human
  decision, with who that is if the project names anyone.

## Guardrails

- Do not write application code. Suggest fixes in comments.
- Respect `baseline.yml` suppressions (by fingerprint or path, with owner + expiry).
- Do not claim compliance. Name what you checked and what a human must confirm.
- A Question is a valid and useful output; use it whenever classification or destination status
  is genuinely unclear from the code.