---

name: plan-privacy-compliance description: > Plan-only audit mapping real personal-data flows to the privacy policy, GDPR, Japan APPI, and store labels. Use when "privacy compliance", "what data do we collect?", "App Store privacy labels", or before a consumer launch. license: MIT effort: high

plan-privacy-compliance — Data-flow & legal-surface plan

Degree of freedom: HIGH — interpretive inventory and plan. Stay plan-only. T4 before presenting the burndown.

Role: Privacy engineer (operational compliance, not legal advice).

Task: Map what the code collects, diff it against the written policy and store labels, emit plan-privacy-compliance.md. Audit & plan only — no policy rewrites, SDK gates, or deletion jobs until each phase is approved.

The gap that sinks apps is collection-vs-claimed: the code gathers more than the privacy policy admits, and the store label is wrong.

Not legal advice. This operationalizes common GDPR and Japan APPI (個人情報保護法) requirements into engineering findings. Flag genuine ambiguity for a lawyer.

This skill vs neighbors

Skill	Owns
plan-privacy-compliance (this)	Data inventory, consent timing, deletion/export, store labels
audit-analytics	Event taxonomy + whether analytics fires before consent
plan-mobile-readiness	Submission mechanics (demo account, 2.5.2) — not the data-flow diff
plan-rls-audit	Who can read rows — not what you promised to collect
plan-error-handling	PII in Sentry/logs
enhance-email-deliverability	Lawful send / unsubscribe (consent to mail)

Do not fire for "privacy manifest / Data Safety form paperwork only" if the user is mid-store-submit → still run this for the data-flow half, then plan-mobile-readiness for the rest.

How to reason (every plan item)

1. Propose — what must change (policy, SDK gate, deletion path, label)
2. Risk — what stays non-compliant or leaking if we skip it
3. Keep-working — collection that is already disclosed and gated
4. Phase — P0 / P1 / P2 (do not execute)

Worked example

Propose: delay PostHog init until consent; add account-deletion that reaches Sentry + the analytics project. Risk: GDPR consent-after-fire + incomplete erasure (PII in traces). Keep-working: essential auth cookies already disclosed. Phase: P0 — consent timing + deletion completeness. Execute-via: audit-analytics (event gate) + plan-error-handling (logs).

---

Phase 0 — Inventory personal data actually collected [HIGH freedom]

Do not trust the privacy policy. Derive collection from the code:

• Direct: forms, signup, profile, uploads, voice/photo, location
• Automatic: IP, device IDs, analytics, crash reports, cookies, session
• Special-category / 要配慮個人情報: health, biometrics, precise location
• Third-party SDKs: every analytics/ads/attribution/crash SDK and what it exfiltrates by default

Build: item → collected where → stored where → shared with → retention → basis.

Consent-gating handoff: if analytics/ads SDKs initialize on app start, log the finding here and point at audit-analytics for the event-level matrix.

---

Phase 1 — Audit against requirements [HIGH freedom]

Collection vs claimed — Diff inventory vs privacy policy vs App Store Nutrition Label / Play Data Safety. Collected-but-undisclosed is P0.

Consent — Obtained before non-essential collection? Granular where GDPR requires? Withdraw path? APPI: 利用目的 specified and notified?

Data-subject rights — Working deletion (account + data, not deactivate) and export. Must reach DB, buckets, logs, analytics, backups, third-party SDKs. A delete that leaves PII in Sentry is non-compliant.

Retention — Defined windows + an enforcer (cron/TTL), or prose only?

Cross-border — Processor region. EU→US needs a transfer basis. APPI restricts transfers outside Japan without consent/adequacy.

Minors — Age-gating and stricter defaults if the app can be used by children.

Logs & LLM traces — Raw PII in app logs / Langfuse → plan-error-handling, audit-langfuse-llm.

---

Phase 2 — Phased plan (approve before executing) [HIGH freedom — plan only]

• P0 — undisclosed collection, absent deletion, consent after fire, PII in logs
• P1 — incomplete deletion, missing export, no retention job, wrong store form
• P2 — consent granularity, policy wording, processor docs

Each item: what's wrong, requirement (GDPR art. / APPI / store), fix shape, execute-via (audit-analytics, plan-rls-audit, plan-error-handling, or a policy/text change).

Self-critique before the burndown [LOW freedom — do not skip]

1. From code, not the policy — inventory derived from collection sites
2. Not legal advice — ambiguity flagged for a lawyer
3. Collected-but-undisclosed is P0 — do not bury it in P2 wording
4. Right owner — analytics fire-before-consent also → audit-analytics
5. Nothing rewritten — no policy/SDK/deletion job until approved

Definition of Done

• Inventory complete (collection → storage → sharing → retention)
• Every third-party SDK's exfiltration documented
• Real collection diffed against policy and store label
• Consent timing + withdraw path checked; analytics handoff to audit-analytics
• Deletion + export traced to all stores
• Retention enforcement identified or flagged absent
• Cross-border map per processor
• Plan approved before any change

Output format

1. Data inventory — item | where | stored | shared | retention | basis
2. Findings — issue | GDPR/APPI/store | severity | evidence
3. Store-label diff — claimed vs actual
4. Phased plan — P0/P1/P2 → executing skill
5. Recap and await approval — end the turn with a standalone recap in chat: the two or three highest-impact findings (collected-but-undisclosed first) and the first phase to approve. plan-privacy-compliance.md is the deliverable; write it before the recap.

Related

• audit-analytics — event coverage + consent-gated firing (run both)
• plan-mobile-readiness — store submission mechanics
• plan-rls-audit — access control
• plan-error-handling / audit-langfuse-llm — PII in logs/traces
• enhance-email-deliverability — marketing-mail consent
• plan-aso — listing copy after labels are honest