/sota-privacy-compliance

name: sota-privacy-compliance
description: State-of-the-art privacy and compliance engineering guidance for building privacy-respecting systems and auditing existing code for privacy/compliance gaps. Use when work involves privacy, GDPR, PII, personal data, consent, data retention, deletion, DSAR (data subject access requests), SOC 2, ISO 27001, HIPAA, PCI DSS, compliance evidence, data residency/sovereignty, data classification, anonymization/pseudonymization, breach notification, or EU AI Act obligations — whether designing new data flows, implementing user-rights features (export/delete), preparing for an audit, or reviewing a codebase for places personal data is over-collected, under-protected, retained forever, or impossible to delete.

SOTA Privacy & Compliance Engineering

Engineering-facing privacy and compliance architecture: how to design, build, and audit systems so that data protection is a property of the code and infrastructure, not a binder of policy documents. Compliance that lives in schemas, TTLs, IAM policies, and CI checks survives staff turnover and audit scrutiny; compliance that lives in wiki pages does not.

> **This is engineering guidance, not legal advice.** Regulations change, vary by > jurisdiction, and turn on facts about your business that code review cannot see. > Regulatory facts below were verified against primary sources as of June 2026 — > re-verify deadlines and statuses before relying on them, and route legal > interpretation (lawful basis selection, contract terms, breach reportability > decisions) to qualified counsel or your DPO. This skill tells you how to build > the machinery those decisions require.

**Related skills — reference, don't duplicate:**

• `sota-databases` rules/06 — DB-level PII mechanics (column encryption, row-level security, GDPR-friendly schema design)
• `sota-secrets-management` — credentials, KMS, key rotation (crypto-shredding depends on it)
• `sota-observability` — log redaction and PII-safe telemetry pipelines
• `sota-threat-modeling` — LINDDUN privacy threat modeling methodology
• `sota-code-security` / `sota-devsecops` — vulnerability management, supply chain (SOC 2/ISO control overlap)

BUILD mode

When designing or implementing systems that touch personal data:

1. **Inventory first.** Before writing a schema or integrating a vendor, classify every field you intend to collect and record where it flows (rules/01). The cheapest control is the field you never store. 2. **Annotate at the source.** Schemas, structs, and API contracts carry classification and purpose annotations; tooling derives the data map from code, not the other way around (rules/01, rules/02). 3. **Build user rights as features, not afterthoughts.** Export, deletion, and consent are product capabilities with APIs, state machines, and tests — design them with the first table, because retrofitting deletion into a 200-table schema with denormalized copies is a quarter-long project (rules/03). 4. **Automate retention.** Every datastore gets a TTL, lifecycle rule, or partition-drop schedule at creation time. "We'll clean it up later" is how seven-year-old PII ends up in a breach disclosure (rules/03). 5. **Emit evidence as a byproduct.** Access reviews, change approvals, and config baselines should fall out of normal engineering workflow (PRs, IaC, IdP logs) so audits are queries, not scrambles (rules/05). 6. **Know your regimes.** Check rules/04 for which regulations the system triggers (data types × subjects' locations × sector) before architecture freezes — data residency and breach-clock requirements shape topology.

AUDIT mode

When reviewing an existing codebase/infrastructure for privacy and compliance gaps:

**Process:** (1) Build or obtain the data inventory — grep schemas, API payloads, log statements, analytics events, object storage for personal data (rules/01 has discovery patterns). (2) Trace lifecycle per data category: collection → purpose → storage → sharing → retention → deletion. (3) Test user rights paths end-to-end (does deletion actually propagate?). (4) Check evidence trails for auditable controls. (5) Map findings to applicable regimes (rules/04).

**Severity conventions:**

| Severity | Meaning | Examples | |---|---|---| | CRITICAL | Active violation with regulatory/breach exposure; fix now | PII in world-readable bucket; deletion endpoint that doesn't delete; special-category data collected without any consent record; cardholder PANs stored unencrypted in app DB | | HIGH | Violation likely under normal operation or on first DSAR/audit/breach | No deletion propagation to backups/analytics; consent not versioned or not propagated to processors; no retention enforcement anywhere; PII in logs shipped to third party without DPA | | MEDIUM | Gap that degrades posture or audit readiness | Classification annotations missing; data map stale/manual; soft-delete only with no purge job; access reviews manual and undocumented | | LOW | Hardening/hygiene | Cookie banner lacks granular toggles; export format not machine-readable; missing purpose comments on schema fields |

**Finding format:**

[SEVERITY] <title>
Location: <file:line / table / bucket / service>
Data: <what personal data, what classification tier>
Regimes: <GDPR Art. X / CCPA / HIPAA / PCI DSS req N / SOC 2 CC-N — as applicable>
Issue: <what is wrong, lifecycle stage affected>
Impact: <realistic consequence: fine exposure, breach scope, audit failure, DSAR failure>
Fix: <concrete engineering remediation>
Evidence: <how you verified — query, code path, test>

Report findings grouped by data lifecycle stage (collection / storage / sharing / retention / deletion), not by file — that is how regulators and auditors think.

Rules index

| File | Read this when... | |---|---| | [rules/01-data-inventory-classification.md](rules/01-data-inventory-classification.md) | Starting any privacy work; building/auditing a data map; de