kensaurus 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)
- Propose — what must change (policy, SDK gate, deletion path, label)
- Risk — what stays non-compliant or leaking if we skip it
- Keep-working — collection that is already disclosed and gated
- 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]
- From code, not the policy — inventory derived from collection sites
- Not legal advice — ambiguity flagged for a lawyer
- Collected-but-undisclosed is P0 — do not bury it in P2 wording
- Right owner — analytics fire-before-consent also →
audit-analytics - 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
- Data inventory — item | where | stored | shared | retention | basis
- Findings — issue | GDPR/APPI/store | severity | evidence
- Store-label diff — claimed vs actual
- Phased plan — P0/P1/P2 → executing skill
- Await approval.
Related
audit-analytics— event coverage + consent-gated firing (run both)plan-mobile-readiness— store submission mechanicsplan-rls-audit— access controlplan-error-handling/audit-langfuse-llm— PII in logs/tracesenhance-email-deliverability— marketing-mail consentplan-aso— listing copy after labels are honest