data-privacy

Handle personal data with minimisation and control

Personal data is anything that relates to an identifiable person. That includes emails, IP addresses, device and cookie ids, location, behaviour, and free text that might contain any of those. GDPR requires minimisation (Art. 5(1)(c)), storage limitation (5(1)(e)), and data protection by design and by default (Art. 25). People have rights of access (Art. 15), erasure (Art. 17, with notice to recipients under Art. 19) and portability (Art. 20), and controllers must answer them within one month (Art. 12(3)). CCPA/CPRA gives similar rights with a 45-day clock. This skill turns that into code and tests. You do not decide the lawful basis, the retention period or a new processor. Those are human decisions: raise them.

Procedure

1. Inventory before you code. For every personal field the ticket touches, write one line with: the field, its purpose, its classification (the repo's scheme, or direct identifier / indirect / special category), and every place it lands: the primary DB, replicas, caches, search indexes, object storage, queues, logs, traces, metrics, analytics, error reporting, third-party APIs, LLM prompts, backups. Call search_lore for the classification scheme, the field registry, retention periods, the processor list and any existing redaction, export or erasure helpers. The inventory goes in your evidence.
2. Minimise. Collect only what the stated purpose needs.
   • No purpose, no field. If the ticket asks for data without a purpose, or for special-category data (health, biometrics, religion and so on), raise request_decision with severity: security_required.
   • Prefer coarser or derived forms: a birth year instead of a birth date, a truncated IP, a city instead of GPS coordinates.
   • A salted hash or tokenised id is pseudonymised, not anonymous. It is still personal data and still subject to erasure (Recital 26).
   • Return only the fields each caller needs (ASVS 14.2.6).
3. Register the field in code. Use the repo's annotation, schema tag or registry, so redaction, export and erasure find it automatically. A test should fail when a personal-looking column (email, phone, ip, name, dob, address) is added without a classification. An unregistered field is a field nobody deletes.
4. Protect every flow.
   • Access goes only through authorization-checked paths (the security-authz skill).
   • Encryption in transit, and at rest where the platform offers it. Field-level encryption for special categories if the repo has it.
   • The field is never in logs, traces, metric labels or error reports: add it to the redaction list of the structured-logging-and-tracing skill.
   • Never in URLs or query strings (ASVS 14.2.1). Never in browser storage (14.3.3). Sensitive responses carry Cache-Control: no-store.
   • Never sent to analytics, trackers or LLM endpoints unless there is a recorded purpose and processor, and then only the minimum (ASVS 14.2.3).
5. Implement erasure end to end.
   • One erasure routine walks the registry across every store in the inventory. It deletes, or anonymises where law requires the record to stay (ledgers, invoices), and calls each processor's deletion API or queues that call.
   • Write a tombstone or suppression entry so that late writes, queue redelivery, replays and backup restores cannot resurrect the person. A restore must re-apply tombstones, which is how backups are kept "beyond use".
   • The routine is idempotent and retry-safe (the idempotency-and-retries skill), and it emits an audit event without the erased data.
6. Implement access and export. Build the export from the same registry. It must be structured and machine-readable (JSON or CSV), authorization-checked for the requester, gated by re-authentication, delivered through a short-lived link, and exclude other people's personal data. Record request and completion timestamps so the deadline can be shown to have been met.
7. Enforce retention. Every registered field has a retention rule. A job from the scheduled-jobs skill deletes or anonymises expired rows in bounded, resumable batches, and a crashed run must be safe to re-run. If the period is not documented, ask with request_decision.
8. Gate on consent where required. Non-essential cookies and tracking are off until consent is granted (ePrivacy Art. 5(3)). Withdrawing consent is as easy as granting it (GDPR Art. 7(3)), and a consent change is stored with a timestamp and the policy version. Honour Global Privacy Control where CCPA applies.
9. Test with a PII canary. Seed a unique sentinel (for example canary-<uuid>@example.test) into every touched field and drive the flows. Then assert:
   • the canary is absent from captured logs and error payloads;
   • after erasure, a query of every store in the inventory finds no canary (not just the main table);
   • a write or queue message that arrives after erasure does not recreate the record;
   • the export contains the canary and no other user's data;
   • the retention job removes expired rows and leaves live rows alone;
   • with consent off, no tracking event is sent. Record the command and summary as test_output through the record-evidence skill, with the inventory paragraph, then stop.