GDPR Privacy Engineering skill for Claude Code

Done well means: there is a data map that matches the actual schema, every personal-data field has a purpose and a retention period, consent is recorded with what was shown and when, a data subject request can be fulfilled end to end in hours (not weeks) including processors, and deletion is provable. The legal decisions (lawful basis, whether a DPIA is needed, what counts as “sale”) belong to counsel; this skill makes the system able to carry them out.

This is engineering guidance, not legal advice. Regulations, guidance, and enforcement change and vary by jurisdiction. State this to the user when delivering privacy work, and route lawful-basis, cross-border transfer, and notice-wording decisions to their privacy counsel or DPO.

Ground rules

• Map before you build. No consent banner or deletion endpoint until you know where personal data lives, including logs, analytics, search indexes, caches, files, and third parties.
• Minimize first: the cheapest field to protect is the one you never collect. Challenge every new personal-data column in review (“what is it for, and when do we delete it?”).
• Purpose limitation in code: tag fields and events with purposes; do not reuse support data for marketing without a basis.
• Deletion must be real or explainably retained (legal hold, tax records), never a silent is_deleted = true that keeps everything forever.
• Consent is per purpose, recorded, versioned, and as easy to withdraw as to give.
• Treat identity verification as part of every DSAR; an export sent to an impostor is a breach.

Workflow

- [ ] 1. Build the data map from schema and integrations
- [ ] 2. Tag purpose, lawful basis (from counsel), retention, and processors per field
- [ ] 3. Consent and opt-out: record, gate, honor GPC
- [ ] 4. Retention: automated deletion or anonymization jobs
- [ ] 5. DSAR flows: verify, access/export, correct, delete, track deadlines
- [ ] 6. Propagate to processors, logs, analytics, backups
- [ ] 7. Verify with a seeded test subject; keep evidence

1. Data map

Start from the schema, then add what schemas miss:

python3 scripts/pii_column_scan.py db/migrations prisma/schema.prisma app/models.py --format md > data-map.md
python3 scripts/pii_column_scan.py . --format csv > data-map.csv
python3 scripts/pii_column_scan.py . --fail-on-special    # exit 1 if special-category columns exist (CI gate)

The script flags columns by name (contact, identity, government ID, financial, credentials, location, online identifiers, special category, free text) in SQL DDL, Prisma, Django or SQLAlchemy models, and TypeORM entities, and emits a table with TODO columns for purpose, basis, retention, and processors. It is a heuristic; then search for what it cannot see:

# Personal data leaving the system
grep -rnE "posthog|mixpanel|segment|amplitude|gtag|fbq|intercom|hubspot|sentry|datadog|mailchimp|sendgrid|resend|stripe" --include=*.{ts,tsx,js,py,rb,go} . | cut -d: -f1 | sort -u
# JSON blobs and free text that hold personal data without a column name
grep -rnE "JSONB?|jsonb|metadata|payload|extra_data" db/ --include=*.sql | head
# Files: avatars, uploads, exports
grep -rnE "s3|bucket|upload|presign" --include=*.{ts,py,go,rb} . | cut -d: -f1 | sort -u

Data map row format (also serves as the engineering input to the Article 30 record):

System / table.field	Category	Purpose	Lawful basis	Retention	Processors	Deletion method
users.email	contact	account, transactional email	contract	life of account + 30 d	Resend, Postgres host	hard delete
events.ip	online identifier	fraud prevention	legitimate interests	90 d	Datadog	TTL drop
orders.billing_address	contact	invoicing	legal obligation	10 y (tax, confirm locally)	Stripe	retain, restrict access

2. Tags in code

Put the map next to the schema so it stays current:

# models.py (Django) - privacy metadata colocated with fields
class User(models.Model):
    email = models.EmailField(unique=True)          # privacy: contact | purpose=account | retention=account+30d
    marketing_opt_in = models.BooleanField(default=False)

PRIVACY = {
    "User.email": {"category": "contact", "purposes": ["account"], "export": True, "erase": "delete"},
    "Order.billing_address": {"category": "contact", "purposes": ["invoicing"], "export": True, "erase": "retain_legal"},
}

Add a CI check that fails when a new model field matching personal-data patterns has no PRIVACY entry (the scanner’s CSV output diffed against the registry works).

3. Consent and opt-outs

Situation	Requirement to implement (confirm with counsel)
EU/UK visitors, non-essential cookies or trackers	Prior opt-in before setting them; reject as easy as accept; no pre-ticked boxes
Analytics needed for product	Cookieless or server-side with IP truncation, or gate behind consent
California residents, ads or cross-context sharing	“Do Not Sell or Share” opt-out; honor Global Privacy Control (Sec-GPC: 1 / navigator.globalPrivacyControl) as an opt-out
Marketing email	Separate, unticked consent; one-click unsubscribe
Sensitive data (health, precise location)	Explicit consent or a specific basis; CPRA “limit use” right

Consent record (append-only, one row per change):

CREATE TABLE consent_events (
  id            BIGSERIAL PRIMARY KEY,
  subject_id    UUID,                 -- null for anonymous visitor, then linked on login
  anon_id       TEXT,                 -- first-party visitor ID
  purpose       TEXT NOT NULL,        -- 'analytics' | 'ads' | 'marketing_email' | ...
  granted       BOOLEAN NOT NULL,
  source        TEXT NOT NULL,        -- 'banner' | 'settings' | 'gpc' | 'api'
  notice_version TEXT NOT NULL,       -- hash or version of the text shown
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);

Gate loading, not just firing: tag scripts must not load until the purpose is granted.

const gpc = (navigator as any).globalPrivacyControl === true;
const consent = readConsent();                       // from first-party cookie set by your banner
if (gpc) recordConsent({ purpose: "ads", granted: false, source: "gpc" });
if (consent.analytics && !gpc) loadScript("/analytics.js");
if (consent.ads && !gpc) loadScript("https://ads.example/tag.js");

On the server, read Sec-GPC: 1 and suppress sharing with ad partners for that request and the linked account. If using Google tags, Consent Mode v2 signals (ad_storage, analytics_storage, ad_user_data, ad_personalization) must default to denied for regions that require opt-in.

4. Retention

• Every table with personal data gets a retention rule in the data map and a scheduled job.
• Prefer partition drops or TTL indexes for high-volume data (events, logs); batched deletes for the rest.

-- nightly, batched to avoid long locks
DELETE FROM login_events
WHERE id IN (SELECT id FROM login_events WHERE created_at < now() - interval '90 days' LIMIT 10000);

• Anonymize instead of delete when aggregates must survive: drop direct identifiers and coarsen quasi-identifiers (birth date to year, location to region). Hashing an email is pseudonymization, not anonymization; it is still personal data.
• Before enabling a new deletion job in production, run it in report-only mode and get user confirmation on the row counts; deletion is irreversible.

5. Data subject requests

Right	GDPR	CCPA/CPRA	Implementation
Access / know	Art. 15	Yes	Export of all data linked to the subject plus purposes, recipients, retention
Portability	Art. 20	Covered by access	Machine-readable (JSON/CSV in a zip)
Rectification / correct	Art. 16	Yes (CPRA)	Self-service edit where possible
Erasure / delete	Art. 17	Yes	Delete job across systems with exceptions log
Object / opt out	Art. 21	Opt out of sale/sharing	Purpose flags, suppression lists
Deadline	One month, extendable for complex cases	45 days, extendable	Track due date per request

DSAR pipeline:

1. Intake (settings page, email, form) creates a privacy_requests row with type, received date, due date, status.
2. Verify identity: signed-in session with recent re-auth is best; otherwise verify control of the account email. Never accept identity documents by email into a general inbox.
3. Resolve the subject across systems: user ID, emails (including historical), customer IDs at processors, anonymous IDs linked by consent records.
4. Execute: run export or erase handlers registered per system (below), collect results.
5. Deliver: export via an expiring, authenticated download link (24-72 h), never as an email attachment.
6. Close with an evidence record: what ran, row counts, exceptions (legal retention), dates.

Handler registry so new systems cannot be forgotten:

DSAR_HANDLERS: dict[str, "Handler"] = {}

def dsar_handler(system: str):
    def wrap(cls):
        DSAR_HANDLERS[system] = cls()
        return cls
    return wrap

@dsar_handler("postgres.users")
class UsersHandler:
    def export(self, subject) -> dict: ...
    def erase(self, subject) -> dict:   # returns {"deleted": n, "retained": [{"table": ..., "reason": "tax law"}]}
        ...

@dsar_handler("stripe")
class StripeHandler:
    def export(self, subject) -> dict: ...
    def erase(self, subject) -> dict: ...   # delete customer or redact per provider API; record request ID

Erase ordering: revoke sessions and API keys, stop processing (suppress emails), delete or redact in primary DB, call processor deletion APIs, purge search indexes and caches, then queue analytics and log deletions. Keep a minimal suppression record (hashed email) so the person is not re-imported or re-mailed, and document why it is retained.

6. Logs, analytics, backups

• Logs: keep personal data out at write time (see security-logging); short retention for what remains. Searching logs per DSAR does not scale.
• Analytics tools: use their user-deletion APIs keyed by your distinct ID; record request IDs.
• Backups: you usually cannot edit them. Keep backup retention bounded (for example 30-35 days), maintain a deletion ledger, and re-apply deletions after any restore before the data is used.
• Crypto-shredding: per-subject encryption keys for high-volume immutable stores let you erase by destroying the key.

Gotchas

• Soft delete is not erasure. If you soft-delete for undo, hard-delete after a short window.
• Foreign keys with ON DELETE CASCADE can delete business records you must keep (invoices); decouple them (null the user reference, keep the record) deliberately.
• Personal data hides in free text: support tickets, notes, file names, URLs, and search queries.
• IP addresses, device IDs, and cookie IDs are personal data under GDPR.
• Consent banners that load tags before the choice, or that make reject harder than accept, are a frequent enforcement target.
• Processors: a deletion request to your own DB without propagating to the CRM, email tool, and data warehouse is incomplete.
• Breach clock: GDPR expects notification to the supervisory authority within 72 hours of becoming aware. The data map and security logs are what make that assessment possible in time.
• Exports must not include other people’s data (messages from other users, shared documents they own); redact third parties.

Verification

1. Seed a test subject with data in every mapped system (DB, files, search, analytics, CRM, email provider in test mode).
2. Run access: the export contains every mapped field and nothing about other users.
3. Run erasure: query every system; only documented retained records remain, each with a reason in the evidence record.
4. Consent: with analytics declined, the network panel shows no analytics requests or cookies; with Sec-GPC: 1, ad partners receive nothing.
5. Rerun pii_column_scan.py in CI; new flagged columns without a registry entry fail.

Output contract

## Privacy engineering: <app>
Disclaimer: engineering implementation, not legal advice; lawful bases supplied by <counsel/DPO>.
### Data map
<table: system.field | category | purpose | basis | retention | processors | deletion>
### Consent
Purposes: analytics, ads, marketing_email; GPC honored client and server; records in consent_events
### Retention jobs
<job, table, rule, schedule, last run row count>
### DSAR
Handlers: postgres.users, s3.uploads, stripe, posthog, hubspot (5/5 systems in map)
Test subject run: access OK, erase OK, retained: orders (tax, 10 y)
### Open items for counsel
- <basis for X, transfer mechanism for Y>