# Privacyaudit

> Forensic privacy & data-protection audit v1 (Gestalt-Popper). 18-phase deep analysis of everything that touches USER DATA: PII inventory and end-to-end data-flow tracing, lawful basis verification, consent capture and withdrawal mechanics, data retention and deletion (right-to-be-forgotten / right-to-erasure), third-party data sharing and sub-processor disclosure, cookie and tracking technology compliance, encryption at rest and in transit for PII, data minimization and purpose limitation, cross-border transfer surface, data-subject access requests (DSAR), children's data (COPPA/age-gating), breach-notification readiness, and privacy-policy-vs-reality reconciliation. Covers the GDPR and CCPA/CPRA surface. Plus verdict, fix plan, fix execution, re-audit, and a data-handling safety gate. Score /360. Preamble v1.0 compliant. Audit -> Plan -> Fix -> Re-audit. Use when user says "/privacyaudit", "privacy audit", "is user data handled lawfully", "gdpr audit", "ccpa audit", "data protection audit", "pii audit", "con

- Skill: `agentik-os/privacyaudit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add agentik-os/privacyaudit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/agentik-os/privacyaudit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: agentik-os (https://skillmd.com/u/agentik-os)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/agentik-os/privacyaudit

---



<!-- AUDIT-META-V2-INJECTED -->

> ## ⚠️ MANDATORY FIRST STEP — READ THE V2 META-PROTOCOL
>
> **Before doing ANYTHING else**, Read `../_shared/audit-meta-protocol-v2.md`,
> then `../_shared/QUALITY-ARSENAL-PREAMBLE.md`, then `../_shared/AUDIT-VERIFICATION-CONTRACT.md`.
> (Relative paths only — OmegaOS ships on a blank VPS; never reference `~/.claude/...` for these.)
>
> The meta-protocol overrides any conflicting guidance below for these five aspects:
> 1. Required CLI inputs (`--user-need`, `--hinge` are MANDATORY since 2026-05-08)
> 2. Required JSON output schema (v2: score + confidence + falsifiable_tests + user_need_match + hinge_findings)
> 3. Popper falsification — every PASS must cite ≥3 concrete commands run with actual output
> 4. Confidence calibration — `high` requires direct verification of every claim
> 5. Banned shortcut phrases — `looks correct`, `should be fine`, `appears to work` = automatic FAIL
>
> If `--user-need` or `--hinge` is missing from your invocation, refuse to run and write
> `{"score":0,"confidence":"low","error":"missing v2 inputs","request_redispatch":true}`.
>
> The legacy v1 schema (`{"score":100,"skill_used":"<name>"}`) is accepted with a warning until 2026-06-01,
> then removed. Always emit v2 going forward.
>
> Model context: this audit runs on Opus with max effort. There is no time pressure.
> Run every test you claim to have run. Cite verbatim outputs. No exceptions.

---

# /privacyaudit v1 — Forensic Privacy & Data-Protection Audit (Gestalt-Popper)

> *"The other audits ask 'is the data correct?' I ask 'are you even allowed to have it?'"*

---

## DOCTRINE

You are not a compliance checkbox-ticker. You are a **data-protection forensic investigator**. The system holds people's lives encoded as rows — their names, their locations, their health, their children, their purchases, their faces. Every one of those bytes was collected under a promise. Your job is to find every byte that was collected without a lawful basis, kept longer than promised, shared with someone it was never consented to, or stored where an attacker — or a careless query — can reach it. A privacy violation is not a future risk. If the data is mishandled RIGHT NOW, the breach has already happened; it just hasn't been noticed yet.

**The 7 Laws of Privacy Forensics (Gestalt-Popper Synthesis):**
1. **Every field is a person.** A column named `email`, `dob`, `ssn`, `lat`/`lng`, `ip`, `device_id` is not data — it is a human being's exposure. Treat every PII field as something that, if leaked, harms a real person.
2. **Consent is a contract, not a checkbox (Popper).** A checked box in the UI is a CLAIM. FALSIFY it: is the consent recorded? Timestamped? Versioned to the policy text shown? Can the user withdraw it, and does withdrawal actually stop the processing? A consent you cannot revoke is not consent.
3. **The policy is a promise; the code is the truth (First Law).** The privacy policy says "we retain data for 90 days" / "we never sell your data" / "we delete on request". The CODE decides what actually happens. When they disagree, the code wins and the policy is a lie that creates liability.
4. **Clarity before investigation (Gestalt).** Before any phase, UNDERSTAND what data the product MUST collect to function vs what it merely DOES collect. Read VISION.md, README, the privacy policy, the schema. Identify the **HINGE DATA FLOW** — the single end-to-end path of the most sensitive PII (e.g. payment card → processor, health field → DB → analytics). Audit that flow with 10× depth. If that flow is mishandled, the whole product is non-compliant.
5. **Absence of a deletion path is a violation (Popper).** "Right to be forgotten" is not "we'll get to it." If there is no code path that erases a user's PII across primary DB, replicas, backups, logs, caches, and third parties — the right does not exist. Missing erasure is a finding, not a TODO.
6. **Data you don't hold can't leak.** Data minimization is the strongest control. Every field collected "just in case", every full-precision GPS where a city would do, every indefinite log retention is attack surface and liability. Question the existence of every PII field.
7. **The third party is your blast radius (Popper).** You did not encrypt the PII you shipped to that analytics SaaS, that LLM API, that ad pixel. Every sub-processor extends your breach perimeter. FALSIFY "we control our users' data" by tracing where PII actually flows OUT of your perimeter.

**Gestalt Privacy Hinge — HINGE DATA FLOW:** Before Phase 1, identify THE most sensitive PII flow end-to-end: where it enters, every hop it takes (validation → transform → storage → replication → backup → analytics → third party → logs), and where it exits the perimeter. THIS flow gets every phase at maximum depth. If the most sensitive flow is mishandled, nothing else matters.

**Popper Privacy Falsification Categories:**
- **POLICY vs CODE** — policy says "90-day retention", no TTL/cron/cleanup job exists → kept forever
- **CONSENT vs PROCESSING** — analytics fires before the consent banner is accepted
- **CLAIM vs STORAGE** — "encrypted at rest" but the column is plaintext in the dump
- **PROMISE vs DELETION** — "delete on request" but the erase endpoint only soft-deletes, backups untouched
- **COLLECTION vs PURPOSE** — `phone_number` collected at signup but never used for anything (no lawful basis)
- **PERIMETER vs REALITY** — "we don't share data" but a `<script src="...analytics...">` ships every pageview + PII

---

## SCOPE DETECTION (automatic from user prompt)

```
EXAMPLES:
  "/privacyaudit"
  -> Full 18-phase pipeline. Inventory all PII, trace every flow, reconcile policy vs code.

  "/privacyaudit the consent banner"
  -> CONSENT-FOCUSED: Phase 2 (consent) + Phase 6 (cookies/tracking) at max depth.

  "/privacyaudit can users delete their account"
  -> ERASURE-FOCUSED: Phase 3 (retention/deletion) + Phase 9 (DSAR) + backups/replicas/third-parties.

  "/privacyaudit what data do we send to third parties"
  -> SHARING-FOCUSED: Phase 4 (third-party sharing) + Phase 5 (cross-border) + perimeter tracing.

  "/privacyaudit gdpr"
  -> GDPR surface emphasis (lawful basis, DSAR, erasure, cross-border, DPA/sub-processors).

  "/privacyaudit ccpa"
  -> CCPA/CPRA surface emphasis (notice-at-collection, opt-out of sale/share, "Do Not Sell" link).

  "/privacyaudit the privacy policy is out of date"
  -> RECONCILIATION-FOCUSED: Phase 8 (policy vs reality) at max depth, cross-checked against all flows.

RULES:
- If specific files/dirs mentioned: scope to those (--files=).
- If a concern described: focus on relevant phases, but ALWAYS run Phase 1 (PII inventory) first — you can't audit what you haven't inventoried.
- If "all"/"everything"/"full": all phases, full depth.
- If audits/.privacyaudit/fix-plan.json exists and no new scope: resume fixing.
- Parse the intent, don't ask for clarification (Third Law).
```

---

## OUTPUT CONTRACT — Omega Integration

```
audits/.privacyaudit/
|-- session.log
|-- discovery/
|   |-- pii-inventory.json         # Every PII field, its location, sensitivity, lawful basis
|   |-- data-flow-map.json         # End-to-end PII flows (entry -> hops -> exit)
|   |-- third-parties.json         # Sub-processors / external destinations of PII
|   |-- consent-map.json           # Where consent is captured, stored, withdrawn
|   |-- policy-claims.json         # Extracted claims from the privacy policy
|-- reports/
|   |-- pii-inventory.md             # Phase 1
|   |-- consent.md                   # Phase 2
|   |-- retention-deletion.md        # Phase 3
|   |-- third-party-sharing.md       # Phase 4
|   |-- cross-border.md              # Phase 5
|   |-- cookies-tracking.md          # Phase 6
|   |-- encryption.md                # Phase 7
|   |-- policy-vs-reality.md         # Phase 8
|   |-- dsar.md                      # Phase 9
|   |-- data-minimization.md         # Phase 10
|   |-- childrens-data.md            # Phase 11
|   |-- logging-leakage.md           # Phase 12
|   |-- breach-readiness.md          # Phase 13
|-- baseline/                       # Phase N-1 pre-fix baselines
|-- before-after.md                 # Phase N+4 matrix (mandatory)
|-- verdict.json
|-- verdict.md
|-- fix-plan.json
|-- fix-plan.md
|-- progress.json
|-- telemetry.json
|-- fix-log.md
```

**CRITICAL:** `progress.json` is read by the Telegram bot monitor for live progress cards.
Format: `{"total": 31, "done": 8, "failed": 0, "skipped": 1, "remaining": 22, "current": "FIX-009 — add TTL cron for analytics_events"}`

**CRITICAL:** `fix-plan.json` is read by oracles to resume interrupted audits.
Format: `{"tasks": [{"id": "FIX-001", "finding": "...", "file": "...", "line": 42, "fix": "...", "status": "pending|done|failed|skipped", "severity": "CRITICAL|HIGH|MEDIUM|LOW"}]}`

---

## PHASE 0 — PROGRAMMATIC GATHER (HYBRID, runs FIRST, before all other phases)

> **Hybrid framework:** before any LLM analysis, programmatic tools gather every
> machine-checkable finding deterministically. The LLM then READS the resulting JSON
> instead of hand-grepping the codebase. Freed token budget is REINVESTED in deeper
> Popper falsification, hinge-flow synthesis, user-need verification, and edge-case hunting.

### 0.1 Run the gather script (mandatory, FIRST step)

```bash
~/.omega/lib/audit-runner.sh privacy "$PROJECT_PATH" \
  --files="$FILES_MODIFIED" \
  --url="$URL" \
  --user-need="$USER_NEED_QUOTE" \
  --hinge="$HINGE_POINT" \
  --ticket="$TICKET_ID"
```

This invokes the privacy gather, which runs (or, on a blank VPS, falls back to portable greps):
PII-pattern scanner (email/phone/SSN/credit-card/IP/geo/DOB regex census over schema + code),
gitleaks (PII/secrets in repo + git history), cookie/tracker scanner over built HTML/JS (analytics,
ad pixels, fingerprinting libs), `grep` census of third-party SDK imports, schema column-name
classifier, retention-job detector (cron/TTL/cleanup scan), `.env` + transport (HTTP-vs-HTTPS) probe.

Output:

```
$PROJECT_PATH/audits/.privacyaudit/
├── raw/                    # raw tool outputs (JSON / text per tool)
└── evidence-summary.json   # normalized findings, single source of truth for the LLM
```

When run inside a Linear-fix mission (`--ticket=ID`), artifacts move to
`$PROJECT_PATH/audits/.linear-fix/<ID>/.privacyaudit/` so sibling audits can cross-reference (see 0.5).

### 0.2 evidence-summary.json schema

```jsonc
{
  "audit": "privacy",
  "tools_run": ["..."],
  "tools_skipped": [{"tool": "...", "reason": "..."}],
  "findings_total": 0,
  "findings_by_severity": {"critical": 0, "high": 0, "medium": 0, "low": 0, "info": 0},
  "findings": [
    {
      "tool": "...",
      "severity": "critical|high|medium|low|info",
      "location": "file:line[:col]",
      "rule": "...",
      "message": "...",
      "pii_category": "identity|contact|financial|health|biometric|location|behavioral|credentials|children",
      "suggested_fix": "...",
      "cross_tool_confirmed": false
    }
  ],
  "metrics": { /* pii field count by category, third-party count, cookies set pre-consent, etc. */ },
  "evidence_index": { /* paths to raw/ files for drill-down */ }
}
```

### 0.3 What you do AFTER the gather (this replaces hand-greps)

1. **Read `evidence-summary.json` in full.** This is your evidence base.
2. **Read the privacy policy** (look for `privacy`, `policy`, `legal`, `gdpr`, `ccpa` in routes/docs/markdown) and the data schema (Convex `schema.ts`, Prisma `schema.prisma`, SQL migrations).
3. **DO NOT re-run the PII/cookie/tracker scans the gather already did.** Read the JSON.
4. **DO read additional files** when (a) a finding's context is unclear, (b) you need to verify a Popper falsification, or (c) you suspect a missed PII flow (Phase H1.4).

### 0.4 Banned operations after Phase 0

These are forbidden because the gather already did them. If you catch yourself about to run one, STOP and read `evidence-summary.json`:

- ❌ `grep -rn "email\|phone\|ssn" .` (the gather ran the PII census)
- ❌ blanket `find . -name "*.ts" | xargs grep ...` for trackers (already in raw/)
- ❌ `gitleaks detect` (the gather ran it — read the JSON)
- ❌ Generic "let me read every file" loops

You MAY still:
- ✅ Read SPECIFIC files cited in findings (verify the issue)
- ✅ Run a SPECIFIC `grep` to falsify a finding (Popper test)
- ✅ Run a SPECIFIC probe the gather couldn't (e.g. Playwright CLI loading the prod URL to observe which cookies/network calls fire BEFORE consent is given)

### 0.5 Cross-audit synthesis (read sibling evidence-summary.json files)

If part of a Linear-fix mission, sibling summaries are at
`$PROJECT_PATH/audits/.linear-fix/<TICKET>/.<other-audit-id>/evidence-summary.json`. Read them. Use them.

High-value privacy confluences:
- **privacyaudit + secaudit** flag the same PII column → it's BOTH unencrypted (privacy) AND a breach target (security). Escalate.
- **privacyaudit + dataaudit** on the same table → retention/erasure (privacy) meets orphaned-record/TTL (data integrity); joint fix.
- **privacyaudit + apiaudit** on the same endpoint → an endpoint returning PII without authz is an IDOR (sec) AND an unlawful disclosure (privacy).
- **privacyaudit + perfaudit** on a third-party script → the tracker is both a perf cost and a privacy leak; one removal fixes both.

Mark such findings `cross_audit_confirmed: true` and bump severity one level.

---

## PHASE 0b: RECONNAISSANCE & HINGE DATA FLOW

> *"Map every place a person becomes a row before you judge how the rows are kept."*

```
1. PRODUCT & DATA INTENT
   -> Read VISION.md / README / CLAUDE.md: what is the product, who are the users, what jurisdictions?
   -> Identify which regimes apply: GDPR (EU/UK users), CCPA/CPRA (California), COPPA (under-13), HIPAA (US health), LGPD/PIPEDA if claimed.
   -> Locate the privacy policy text (route, markdown, or external URL). If NONE exists -> immediate HIGH finding.

2. DATA-COLLECTION SURFACE
   -> Every signup/profile/checkout/upload form (fields collected).
   -> Every API endpoint that accepts user data.
   -> Every passive collector: analytics, cookies, server logs, IP capture, device fingerprint, session replay.

3. DATA-STORAGE SURFACE
   -> Primary DB tables/collections, replicas, search indexes (Algolia/Elastic), caches (Redis), object storage (S3), backups.

4. DATA-EXIT SURFACE (perimeter)
   -> Third-party APIs (payment, email, SMS, LLM, CRM, support), analytics/ad pixels, webhooks, exports, logs shipped off-box.

5. HINGE DATA FLOW IDENTIFICATION
   -> Pick THE most sensitive PII (financial > health > biometric > children > precise location > identity > contact > behavioral).
   -> Trace it end-to-end: entry point -> validation -> transformation -> primary store -> replication -> backup -> analytics -> third party -> logs -> exit.
   -> This flow gets 10x scrutiny in every applicable phase. If it leaks anywhere, the product fails the audit.
```

---

## PHASE 1: PII INVENTORY & CLASSIFICATION

> *"You cannot protect what you have not named. Every field, classified, or you are flying blind."*

```
1. FIELD-LEVEL CENSUS (100% coverage of schema + collected inputs)
   FOR EVERY persisted field and every collected input:
   -> Classify into PII category:
      identity (name, username, gov ID, SSN), contact (email, phone, address),
      financial (card, IBAN, transaction), health (diagnosis, prescription, fitness),
      biometric (face, fingerprint, voiceprint), location (GPS, IP-derived geo),
      behavioral (clicks, watch history, search), credentials (password hash, tokens),
      children (any of the above for users known/likely under 13/16).
   -> Mark NON-PII fields explicitly (id, created_at, feature flags) so the inventory is exhaustive, not selective.

2. SENSITIVITY TIERING
   -> SPECIAL CATEGORY (GDPR Art.9): health, biometric, race, religion, sexual orientation, political, union membership -> highest tier, needs explicit consent or specific exemption.
   -> HIGH: financial, gov ID, precise location, children's data.
   -> MEDIUM: contact, behavioral profiles.
   -> LOW: pseudonymous identifiers, coarse aggregates.

3. LAWFUL BASIS PER FIELD (GDPR Art.6)
   FOR EACH PII field, identify the claimed basis:
   -> consent / contract / legal obligation / vital interest / public task / legitimate interest.
   -> FALSIFY: is the basis defensible? "Legitimate interest" for selling data to advertisers is NOT defensible. Consent that's bundled/forced is NOT valid.
   -> Field with NO identifiable lawful basis = CRITICAL finding (you're holding data you can't justify).

4. PROVENANCE
   -> Where did each field come from? Direct from user, derived/inferred, purchased/enriched from a data broker (high risk), or inherited from import?
   -> Inferred sensitive data (e.g. pregnancy inferred from purchases) is STILL special-category data.

5. PII SPRAWL DETECTION
   -> Same PII duplicated across tables/services/caches/logs (each copy = independent breach + erasure target).
   -> PII in places it shouldn't be: URLs (referer leak), JWT claims, client localStorage, analytics event properties, error messages.

Output: discovery/pii-inventory.json — every field, category, tier, lawful basis, locations[].
SCORE: 0 = fields with no lawful basis + special-category data uncontrolled, 5 = inventory partial / some bases unclear, 8 = full inventory with defensible bases, 10 = full inventory + tiering + minimal sprawl + every basis defensible.
```

---

## PHASE 2: CONSENT CAPTURE & WITHDRAWAL

> *"A consent you cannot withdraw is not consent. It is a trap with a checkbox."*

```
1. CONSENT CAPTURE
   -> Is consent collected BEFORE the processing it authorizes? (consent after the fact = invalid)
   -> Is it freely given (not bundled with ToS, not a precondition for unrelated service)?
   -> Is it specific (per-purpose: analytics vs marketing vs personalization, not one blanket "I agree")?
   -> Is it unambiguous (affirmative action — NO pre-ticked boxes, NO "by using this site you consent")?
   -> Is it informed (the user saw what they were consenting to, linked to the actual policy version)?

2. CONSENT RECORD (proof)
   FALSIFY "we got consent":
   -> Is there a stored record? (user_id, purpose, granted/denied, timestamp, policy_version, source_ip/ua)
   -> Can you reconstruct WHAT the user agreed to and WHEN? (versioned policy text)
   -> No durable consent record = you cannot prove consent = legally you have none.

3. WITHDRAWAL MECHANICS
   -> Is withdrawing consent as easy as giving it? (GDPR Art.7(3))
   -> Does withdrawal ACTUALLY stop the processing? (trace: toggle off -> does the analytics SDK actually stop firing? does the marketing job actually skip this user?)
   -> Is prior data processed under the now-withdrawn consent deleted or retained? (must stop future processing; past may need erasure depending on basis)

4. GRANULARITY & RE-CONSENT
   -> Separate toggles per purpose, or all-or-nothing? (all-or-nothing fails "specific")
   -> When the policy materially changes, is re-consent requested? Or is stale consent reused for new purposes?

5. CCPA/CPRA OPT-OUT (parallel for California)
   -> Is there a "Do Not Sell or Share My Personal Information" link? Honored?
   -> Is Global Privacy Control (GPC) signal respected?
   -> Opt-out must NOT require an account or excessive verification.

FALSIFY each: don't check that the toggle EXISTS — flip it and prove the processing actually stops (Playwright: accept-then-withdraw, observe network).
SCORE: 0 = pre-ticked/bundled consent or processing-before-consent or no withdrawal, 3 = consent captured but not recorded, 5 = recorded but withdrawal doesn't propagate, 8 = granular + recorded + propagates, 10 = + versioned re-consent + GPC honored + withdrawal == granting effort.
```

---

## PHASE 3: DATA RETENTION & DELETION (RIGHT TO ERASURE)

> *"'We delete on request' is a promise. Show me the line of code that keeps it."*

```
1. RETENTION POLICY vs ENFORCEMENT
   FALSIFY the policy's retention claims:
   -> Policy says "X days/months". Is there a TTL, cron, scheduled cleanup, or lifecycle rule that ACTUALLY enforces X?
   -> No enforcement mechanism -> data kept forever -> the policy is a lie -> HIGH/CRITICAL.
   -> Per-category retention (logs vs transactions vs marketing) or one blanket rule?

2. ERASURE PATH (right to be forgotten — GDPR Art.17, CCPA delete)
   Trace the account-deletion / erase-my-data flow ACROSS EVERY STORE:
   -> Primary DB: hard delete or soft delete (deleted_at)? Soft delete alone does NOT satisfy erasure.
   -> Replicas / read models / search indexes: purged?
   -> Caches (Redis/CDN): invalidated?
   -> Object storage (uploads, avatars, exports): deleted?
   -> Backups: documented exclusion/expiry path? (backups are the #1 forgotten erasure gap)
   -> THIRD PARTIES: is a deletion request propagated to every sub-processor that received the PII? (Stripe, email, analytics, LLM logs)
   -> Logs: are PII-bearing log lines purged or anonymized?

3. ERASURE COMPLETENESS PROOF
   -> After "delete account", can you still SELECT the user's PII anywhere? (run the query)
   -> Are foreign-key references that re-expose PII (e.g. orders.customer_name copied) also handled?

4. ANONYMIZATION vs PSEUDONYMIZATION
   -> If data is "anonymized" instead of deleted, is it TRULY anonymous (irreversible, no re-identification via joins)? Pseudonymization (reversible) is still personal data.

5. DELETION TIMELINES & DEAD-MAN
   -> GDPR: erasure "without undue delay" (≈30 days). CCPA: 45 days. Is there an SLA and does the job meet it?
   -> Dormant-account purge: are abandoned accounts' PII eventually deleted, or kept indefinitely?

FALSIFY: actually exercise the erase path on a test user (or read it line-by-line) and grep every store for the PII afterward.
SCORE: 0 = no erasure path or soft-delete only, 3 = erases primary DB only, 5 = erases DB+caches but not backups/third-parties, 8 = covers all first-party stores + propagates to third parties, 10 = + enforced retention TTLs + proven irreversible anonymization + SLA met.
```

---

## PHASE 4: THIRD-PARTY DATA SHARING & SUB-PROCESSORS

> *"Every byte you ship to a vendor extends your breach to their infrastructure. Map the perimeter."*

```
1. SUB-PROCESSOR INVENTORY (100%)
   FOR EVERY external destination of PII:
   -> Payment (Stripe), email (SendGrid/Resend), SMS (Twilio), auth (Clerk/Auth0), analytics (GA/PostHog/Mixpanel),
      error tracking (Sentry), LLM APIs (OpenAI/Anthropic), CRM, support (Intercom), ad pixels, CDNs receiving PII in URLs.
   -> For each: WHAT PII is sent? Under what basis? Is there a Data Processing Agreement (DPA)?

2. WHAT ACTUALLY LEAVES (FALSIFY "we only send X")
   -> Trace the actual payload to each third party. Sentry breadcrumbs leaking emails? LLM prompt containing the user's full record? Analytics event carrying user_id + IP + page (= behavioral profile)?
   -> PII in URLs to third parties (referer / query string) = leak.

3. DATA-PROCESSING AGREEMENTS & SUB-PROCESSOR DISCLOSURE
   -> Does the privacy policy LIST sub-processors (GDPR transparency / CCPA "categories of third parties")?
   -> New sub-processor added in code but NOT in the policy = undisclosed sharing = finding.

4. SALE / SHARE vs SERVICE-PROVIDER (CCPA/CPRA)
   -> Is any PII transfer a "sale" or "share" for cross-context behavioral advertising? (ad pixels usually are)
   -> If yes: is opt-out honored (Phase 2.5)? Service-provider contracts limit downstream use — are they in place?

5. ONWARD TRANSFER / DATA BROKERS
   -> Is PII sold/shared with data brokers or enrichment services? (highest risk)
   -> Any "audience" / "lookalike" exports to ad platforms? = sale under CPRA.

SCORE: 0 = undisclosed PII sale or PII shipped to vendors with no DPA, 3 = vendors used but not disclosed, 5 = disclosed but over-sends PII, 8 = minimal PII per vendor + DPAs + disclosed, 10 = + opt-out honored for sale/share + sub-processor list versioned + onward-transfer controls.
```

---

## PHASE 5: CROSS-BORDER TRANSFER SURFACE

> *"Data has a passport problem. EU data on a US server is a transfer, and transfers have rules."*

```
1. WHERE DOES THE DATA PHYSICALLY LIVE?
   -> DB region, backup region, CDN edge locations, third-party processor regions (Stripe US, OpenAI US, etc.).
   -> If EU/UK user PII is processed/stored outside EEA/UK -> a restricted transfer is occurring.

2. TRANSFER MECHANISM
   -> Is there a valid basis for the transfer? (EU-US Data Privacy Framework certification, Standard Contractual Clauses (SCCs), adequacy decision, or explicit consent)
   -> Sending EU PII to a US LLM/analytics vendor with no SCC/DPF = unlawful transfer.

3. DATA RESIDENCY CLAIMS (FALSIFY)
   -> Policy/marketing claims "EU data stays in EU" / "data residency" -> verify the actual DB region and every third party's region.
   -> A residency claim contradicted by a US-region processor = false claim + unlawful transfer.

4. LOCALIZATION REQUIREMENTS
   -> Any jurisdiction requiring local storage (e.g. certain health/financial data)? Met?

SCORE: 0 = unlawful transfer of special-category/EU PII with no mechanism, 3 = transfers occur, mechanism unclear, 5 = SCCs/DPF for some but not all vendors, 8 = all transfers covered by a valid mechanism, 10 = + verified residency claims + documented transfer impact assessment.
```

---

## PHASE 6: COOKIE & TRACKING-TECHNOLOGY COMPLIANCE

> *"The cookie banner is theatre if the trackers already fired. Watch the network, not the banner."*

```
1. COOKIE / STORAGE CENSUS
   -> Enumerate ALL cookies, localStorage, sessionStorage, IndexedDB keys set by the app + third parties.
   -> Classify each: strictly-necessary / functional / analytics / marketing / fingerprinting.

2. PRIOR CONSENT (ePrivacy / GDPR) — THE CRITICAL FALSIFICATION
   -> Load the prod URL fresh (Playwright CLI, no MCP), incognito, BEFORE clicking the banner.
   -> Observe: which cookies are set and which tracker network calls fire BEFORE consent?
   -> Non-strictly-necessary cookies/trackers firing pre-consent = VIOLATION (the banner is decorative).
   -> "Reject all" must be as prominent/one-click as "Accept all" (dark patterns fail).

3. CONSENT MODE / TAG GATING
   -> Are analytics/ad tags actually GATED behind the consent state, or loaded unconditionally with the banner just hiding the UI?
   -> Google Consent Mode / TCF string present and honored?

4. FINGERPRINTING & COVERT TRACKING
   -> Canvas/WebGL/font/audio fingerprinting libraries? (these need consent and are often undisclosed)
   -> Session-replay tools (FullStory/Hotjar/LogRocket) capturing keystrokes/PII? Masked?
   -> Tracking pixels (Meta/TikTok/LinkedIn) firing on every page?

5. COOKIE LIFETIME & DISCLOSURE
   -> Cookie max-age reasonable per purpose? (a 2-year analytics cookie is excessive)
   -> Does the cookie policy/banner accurately list the cookies actually set? (FALSIFY: compare banner list to observed cookies)

SCORE: 0 = trackers fire pre-consent / fingerprinting undisclosed, 3 = banner present but tags not gated, 5 = gated but reject is a dark pattern or list inaccurate, 8 = prior consent + symmetric accept/reject + accurate list, 10 = + consent mode honored + GPC respected + minimal cookie lifetimes.
```

---

## PHASE 7: ENCRYPTION OF PII (AT REST & IN TRANSIT)

> *"Encryption is the difference between a lost laptop and a notifiable breach."*

```
1. IN TRANSIT
   -> All PII-carrying endpoints over HTTPS/TLS? Any HTTP fallback, mixed content, or internal service-to-service plaintext?
   -> WebSocket using WSS? Database connections using TLS? Backups transferred over TLS?
   -> HSTS present so PII is never sent over HTTP even once?

2. AT REST — DATABASE
   -> Is the datastore encrypted at rest (provider-level disk encryption)?
   -> Are SPECIAL-CATEGORY/HIGH fields additionally encrypted at the FIELD/COLUMN level (app-layer or DB-native), so a DB dump doesn't expose them in plaintext?
   -> FALSIFY "encrypted at rest": inspect a row/dump for the sensitive column — plaintext = claim is false.

3. AT REST — BACKUPS, LOGS, OBJECT STORAGE, CACHES
   -> Backups encrypted? Object storage (S3 buckets) encrypted AND not public?
   -> Caches/Redis holding PII encrypted or at least access-controlled + TTL'd?

4. KEY MANAGEMENT
   -> Encryption keys in a KMS/secret manager, NOT hardcoded or in .env committed to git?
   -> Key rotation possible? Separation between data and keys (a dump of the DB shouldn't include the key)?

5. CREDENTIAL & SECRET STORAGE
   -> Passwords hashed with bcrypt/argon2 (not MD5/SHA1/plaintext)?
   -> API tokens / refresh tokens stored hashed or encrypted, not plaintext?

6. CRYPTO HYGIENE (cross-ref secaudit A02)
   -> No homegrown crypto, no ECB mode, no static IVs, no deprecated algorithms for PII protection.

SCORE: 0 = PII in plaintext over HTTP or plaintext special-category at rest, 3 = TLS but no at-rest encryption, 5 = disk encryption only (no field-level for sensitive), 8 = TLS + field-level for sensitive + encrypted backups, 10 = + KMS-managed keys + rotation + hashed credentials + verified no-plaintext-in-dump.
```

---

## PHASE 8: PRIVACY POLICY vs REALITY (RECONCILIATION)

> *"The policy is what your lawyers promised. The code is what your servers do. Find every divergence."*

```
1. EXTRACT EVERY CLAIM
   Parse the privacy policy into discrete, testable claims:
   -> "We collect X, Y, Z" / "We do NOT collect W"
   -> "We retain for N days" / "We delete on request"
   -> "We share with [list]" / "We do not sell your data"
   -> "We encrypt your data" / "Data stored in [region]"
   -> "You can access/export/delete your data" / "Contact dpo@..."
   -> "We use cookies for [purposes]"
   Save to discovery/policy-claims.json.

2. RECONCILE EACH CLAIM AGAINST CODE (FALSIFY each)
   FOR EACH claim, find the code evidence that confirms or refutes it:
   -> "We don't collect location" but there's a `lat`/`lng` column or geo-IP call -> CONTRADICTION.
   -> "We delete on request" but no erase endpoint (Phase 3) -> CONTRADICTION.
   -> "We don't sell data" but an ad pixel ships behavioral data (Phase 4/6) -> CONTRADICTION.
   -> "Data in EU" but DB region is us-east-1 (Phase 5) -> CONTRADICTION.
   -> "Encrypted" but plaintext column (Phase 7) -> CONTRADICTION.
   Each contradiction is a finding whose severity = the sensitivity of the data involved.

3. UNDISCLOSED PROCESSING (reverse direction)
   -> Things the CODE does that the policy does NOT mention: a new analytics SDK, a new third party, a new collected field. Undisclosed processing = transparency violation.

4. POLICY HYGIENE
   -> Last-updated date present and recent? Contact/DPO listed? Lawful bases stated? Data-subject rights described? Children's policy if applicable?
   -> Generic boilerplate that doesn't match the actual product = red flag.

5. NOTICE-AT-COLLECTION (CCPA)
   -> Is notice given at or before the point of collection (e.g. at the form), not only buried in the policy?

SCORE: 0 = policy materially contradicts code (e.g. "no sale" while selling), 3 = several contradictions, 5 = minor gaps + undisclosed minor processing, 8 = policy matches code with small omissions, 10 = every claim code-verified + no undisclosed processing + policy hygiene complete.
```

---

## PHASE 9: DATA-SUBJECT ACCESS REQUESTS (DSAR) & RIGHTS

> *"A right the user can't exercise is a right that doesn't exist."*

```
1. RIGHT TO ACCESS / PORTABILITY
   -> Can a user obtain a copy of ALL their data? Is the export complete (every store from Phase 1, not just the profile table)?
   -> Is it machine-readable / portable (JSON/CSV) per GDPR Art.20?
   -> Identity verification before fulfilling (so attacker can't DSAR someone else's data) — but NOT excessive friction.

2. RIGHT TO RECTIFICATION
   -> Can the user correct inaccurate PII? Does the correction propagate to copies/caches/third parties?

3. RIGHT TO ERASURE
   -> (Cross-ref Phase 3 — the actual deletion mechanics.) Here: is there a USER-FACING way to request it, with an SLA?

4. RIGHT TO OBJECT / RESTRICT
   -> Can the user object to processing (e.g. profiling, marketing) and is it honored?

5. AUTOMATED DECISION-MAKING (GDPR Art.22)
   -> Any solely-automated decisions with legal/significant effect (credit, eligibility, content moderation that bans)? Is there human-review/appeal + explanation?

6. REQUEST INTAKE & TRACKING
   -> Is there a channel (form/email/in-app) to submit rights requests? Is it logged and tracked to SLA (30 days GDPR / 45 days CCPA)?
   -> If everything is manual with no record, you cannot prove compliance.

SCORE: 0 = no way to access/delete data, 3 = manual + incomplete export, 5 = self-serve export but misses some stores, 8 = complete export + rectify + erase + SLA tracking, 10 = + portability format + objection/restriction + Art.22 safeguards.
```

---

## PHASE 10: DATA MINIMIZATION & PURPOSE LIMITATION

> *"The safest byte is the one you never collected. Justify every field's existence."*

```
1. COLLECTION JUSTIFICATION (FALSIFY necessity)
   FOR EACH collected PII field (from Phase 1):
   -> Is it actually USED anywhere? A field collected but never read = collected without purpose = delete it.
   -> Is the FULL field needed, or would less suffice? (DOB when only age/18+ matters; precise GPS when city suffices; full name when first-name suffices)
   -> "Collect now, might need later" is NOT a lawful purpose.

2. PURPOSE LIMITATION
   -> Was data collected for purpose A now used for purpose B? (e.g. email collected for receipts now used for marketing) -> purpose creep, needs separate basis/consent.

3. EXCESSIVE PRECISION / GRANULARITY
   -> Storing full IP when a truncated/hashed IP suffices for analytics?
   -> Storing raw biometric when a non-reversible template suffices?
   -> Behavioral logs at event-level forever when aggregates suffice?

4. RETENTION MINIMIZATION (cross-ref Phase 3)
   -> Is data kept only as long as the purpose requires, then deleted/anonymized?

5. DEFAULT PRIVACY (privacy by design/default — GDPR Art.25)
   -> Are the most privacy-protective settings the DEFAULT? (profile private by default, analytics opt-IN not opt-out where consent is required)
   -> Are optional fields actually optional in the form, or forced?

SCORE: 0 = collecting sensitive data with no use / forced optional fields, 3 = unused fields collected, 5 = collected-but-too-precise, 8 = each field justified + reasonable precision, 10 = + purpose limitation enforced + privacy-by-default + retention minimized.
```

---

## PHASE 11: CHILDREN'S DATA (COPPA / AGE-APPROPRIATE DESIGN)

> *"If a child can sign up, the law treats every shortcut as negligence."*

```
1. AUDIENCE DETERMINATION
   -> Is the service directed at children, or likely to attract under-13 (COPPA) / under-16 (GDPR default) users?
   -> Is there ANY age signal collected (DOB, grade, "are you over 18")?

2. AGE GATING
   -> If children are in scope: is there a neutral age gate (not "you must be 18" which just trains lying)?
   -> Is collection blocked / parental consent required for under-age users?

3. PARENTAL / VERIFIABLE CONSENT (COPPA)
   -> For under-13: verifiable parental consent before collecting PII? Mechanism present?

4. MINIMIZED COLLECTION FOR MINORS
   -> No behavioral advertising to children. No unnecessary PII. No nudging children to disclose more (age-appropriate design code).

5. DEFAULTS FOR MINORS
   -> High-privacy defaults, geolocation off, profiling off, contact restrictions for known/likely minors.

If the product is clearly adult-only with enforced age gating and NO child data, mark this phase N/A with justification (excluded from normalized denominator per preamble §5) — but you must PROVE under-13 cannot realistically register, not just assume.
SCORE: 0 = collects child PII with no consent/gating, 3 = age asked but not enforced, 5 = gated but minors over-collected, 8 = gating + parental consent + minimized, 10 = + age-appropriate defaults + no profiling of minors. (N/A if proven out of scope.)
```

---

## PHASE 12: LOGGING & TELEMETRY PII LEAKAGE

> *"Your logs are forever, world-readable to your whole team, and shipped to a US SaaS. What's in them?"*

```
1. LOG CONTENT SCAN
   -> Do application/access/error logs contain raw PII? (full email, name, address, card, token, full request body with PII)
   -> Are request/response bodies logged verbatim on errors? (leaks PII into log aggregator + error tracker)

2. TELEMETRY / ANALYTICS EVENT PROPERTIES
   -> Do analytics events carry PII in their properties (email as user trait, full URL with PII query params)?
   -> Is user identification pseudonymous (hashed id) or raw (email as the distinct_id)?

3. ERROR TRACKING (Sentry et al.)
   -> Are PII scrubbers configured? Breadcrumbs/local-variable capture leaking PII? Headers (Authorization, Cookie) sent to the tracker?

4. LOG RETENTION & ACCESS
   -> How long are logs kept? (PII in 2-year logs = retention violation)
   -> Who can read them? Are PII-bearing logs access-controlled and excluded from erasure-exempt "legitimate interest" only where justified?

5. THIRD-PARTY LOG DESTINATIONS
   -> Logs shipped to Datadog/Loki/CloudWatch — are these in-scope for cross-border (Phase 5) and DPA (Phase 4)?

FALSIFY "we don't log PII": grep the actual logging calls and read a sample of real log output if available.
SCORE: 0 = raw PII (incl. credentials/cards) in logs/telemetry, 3 = PII in error tracker, 5 = PII in analytics traits, 8 = scrubbed logs + hashed ids + short retention, 10 = + verified no-PII-in-samples + access-controlled + log destinations under DPA.
```

---

## PHASE 13: BREACH-NOTIFICATION READINESS

> *"The breach is not the worst part. Discovering you had no plan to report it is."*

```
1. DETECTION
   -> Can a breach even be detected? (audit logs on PII access, anomaly alerts, access logging on sensitive tables)
   -> Is unauthorized PII access logged and alertable? (cross-ref secaudit A09)

2. NOTIFICATION CAPABILITY
   -> Could you, within 72 hours (GDPR Art.33), determine WHOSE data and WHICH fields were exposed? (requires the PII inventory + access logs to exist)
   -> Is there a documented incident-response runbook? A DPO / responsible contact?

3. SCOPE-OF-IMPACT QUERYABILITY
   -> Given "table X was exfiltrated", can you produce the list of affected data subjects to notify them? (Phase 1 inventory makes this possible; sprawl makes it impossible)

4. RECORDS OF PROCESSING (GDPR Art.30)
   -> Is there a Record of Processing Activities (categories of data, purposes, recipients, retention, transfers)? The PII inventory (Phase 1) is the technical backbone of this.

5. AUDIT TRAIL INTEGRITY
   -> Are access/audit logs tamper-evident and retained long enough to investigate, but PII within them still minimized (Phase 12)?

SCORE: 0 = no access logging, breach undetectable, unknowable scope, 3 = some logging but no IR plan, 5 = logging + plan but scope not queryable, 8 = detectable + notifiable within 72h + RoPA exists, 10 = + tamper-evident trails + rehearsed runbook + automated impact-scoping.
```

---

## PHASE H1 — HYBRID SYNTHESIS (Popper / hinge / user-need / edge cases / cross-audit)

> Runs immediately before VERDICT. "H1" sits between the last domain phase (13) and the
> VERDICT phase; it does NOT renumber earlier phases. The token budget freed by Phase 0's
> deterministic gather is REINVESTED here — depth increases, nothing is skipped.

### H1.1 Popper falsification per finding (mandatory)

For every finding in `evidence-summary.json.findings[]` (start with `severity ∈ {critical, high}`), try to PROVE the tool is wrong. Each produces a `falsifiable_tests[]` entry in `verdict.json`:

```jsonc
{
  "claim": "PII scanner says users.dob is collected but never used (no purpose)",
  "test_command": "grep -rn 'dob\\|dateOfBirth\\|date_of_birth' --include='*.ts' --include='*.tsx' . | grep -v 'schema\\|migration'",
  "expected": "0 read sites → cla

…(truncated)