privacy-engineering

Privacy Engineering — GDPR / CCPA Technical Implementation

Implement privacy controls at the code, data, and infrastructure layers. This skill is not legal compliance theater — it is the engineering work that turns the legal requirements into systems that actually do what they claim.

Privacy and security overlap but are not the same. Security protects against unauthorized access; privacy protects against authorized-but-improper use. A perfectly secure system that logs every keystroke and shares the log with vendors is a privacy disaster. This skill covers the privacy half of that distinction.

Cross-references: owasp-audit for the security side, iam-audit for access control to personal data, secrets-audit for credential handling, incident-triage for the response side of a privacy breach (72-hour GDPR notification clock starts when you find out, not when you finish investigating), security-comms for the customer-disclosure draft.

Authorization

Review systems the user's organization owns or has engaged them to review. Trace data flows through schemas, code, configs and synthetic records, not by pulling real personal data. If you find personal data where it shouldn't be, record the location and category without copying the values. Legal conclusions (lawful basis, whether a breach is notifiable) belong to the DPO and counsel.

Regulatory landscape (engineering-relevant subset)

The skill produces compliant technical implementations. Final compliance determinations stay with counsel; this skill is the technical execution layer.

Regulation	Scope	Key engineering hooks
GDPR (EU)	Any processing of personal data of EU/EEA residents	Articles 5 (principles), 6 (lawful basis), 7 (consent), 15-22 (data subject rights), 25 (privacy by design), 30 (records of processing), 32 (security), 33 (breach notification — 72 hours), 35 (DPIA)
CCPA / CPRA (California)	Businesses processing CA resident data above thresholds	Right to know, delete, correct, opt out of sale / share. Sensitive PI category. Annual privacy notice. Service-provider contracts
LGPD (Brazil)	Brazilian residents	Similar shape to GDPR with local twists
PIPEDA (Canada)	Federal commercial	Consent-based with reasonable expectation, breach notification
State laws (US)	Varies — VA, CO, CT, UT, etc.	Roughly CCPA-shaped; engineering practices that meet GDPR + CCPA usually cover state laws

Engineering reality: build for the strictest regime that applies and stop worrying about the rest. GDPR is the strictest in most dimensions; CCPA adds the "opt out of sale / share" and sensitive-PI category.

Privacy by design — the engineering practices

Practice 1: Data classification

You cannot enforce privacy on data you have not classified. Every data store needs a classification.

A minimal classification (more is fine, less is not):

Class	Definition	Engineering treatment
Public	Information published or freely sharable	No special handling
Internal	Internal business data, no PI	Standard access controls
Personal	Data identifying a natural person (email, name, IP, device ID, account ID)	Access logging, retention limits, deletion path
Sensitive personal	GDPR Art 9 special categories (health, biometric, political, sexual orientation, race, religion), CCPA SPI (precise location, race, religion, biometric, genetic, sex life, mail content, government ID, financial account, citizenship, union membership)	Stricter access (need-to-know), encryption at rest with separate KMS key, audit on every read
Regulated	PHI under HIPAA, PCI cardholder data, NPI under GLBA	Regulation-specific controls; out of scope here, see hipaa-audit and pci-audit

Audit step: for each data store (database, S3 bucket, BigQuery dataset, etc.), confirm classification is documented and matches the actual data. Many systems start "internal" and quietly become "personal" because someone added an email column.

Practice 2: Data minimization

Collect the minimum to deliver the service; retain the minimum to deliver value; share the minimum with vendors.

Common minimization findings:

• IP address logged in every request when it is only needed for rate limiting (truncate to /24 after rate-limit decision)
• Full user-agent stored when only the device class matters (truncate)
• Date of birth collected for age verification when only "over 13 / over 18 / over 21" is needed (store the boolean, not the date)
• Phone numbers collected for "optional" notifications and retained after opt-out
• Backup data retained for years past the operational need
• Analytics platforms receiving full URL paths that contain order IDs / user IDs

Audit grep patterns:

• Personal-data column names in DB schemas: email, phone, name, address, ssn, dob, birth, gender, ip, user_agent, device_id, ip_address
• Logging statements emitting these: log\..*\$\{user\.email\}, console\.log\(.*user\., logger\.info\(.*email
• Analytics integrations sending more than they need: analytics\.identify\(.*email, full-page URL parameters

Practice 3: Lawful basis (GDPR) / purpose (CCPA)

Every processing activity needs a documented lawful basis under GDPR Article 6. CCPA requires purpose-of-use disclosure.

Common bases and where they fit:

• Contract (Art 6(1)(b)) — necessary to provide the service the user signed up for
• Consent (Art 6(1)(a)) — opt-in, freely given, specific, informed, revocable. The bar is high. The bar is especially high for sensitive data (Art 9 requires explicit consent on top of the lawful basis)
• Legitimate interest (Art 6(1)(f)) — the catch-all for security, fraud prevention, internal analytics. Requires a balancing test documented somewhere
• Legal obligation, vital interest, public task — narrow applicability

Engineering hook: the application logs every processing activity (insert into data_processing_log or equivalent) with the lawful basis. When DSARs arrive, this is the source of truth for what to disclose.

Practice 4: Consent management

Consent is the most over-engineered and under-built part of privacy. The skill is keeping it simple and provable.

The consent record:

• User ID (or device ID for pre-auth)
• Specific purpose (marketing emails ≠ product analytics ≠ third-party advertising)
• Timestamp
• Version of the consent text shown
• Source (which form / banner / API)
• Whether granted or denied
• Revocation timestamp if withdrawn

Withdrawal of consent must be as easy as granting it (GDPR Art 7(3)). If "accept all" is one click on the cookie banner, "reject all" must also be one click. Banners that require traversing five panels to refuse are non-compliant.

Common audit findings:

• Cookie banner that loads tracking scripts before the user clicks anything
• "Legitimate interest" set as the default for non-essential cookies
• Consent timestamp not stored, so the app cannot prove when (or whether) consent was obtained
• Marketing consent bundled with terms-of-service acceptance (consent must be specific)
• No way for the user to see their consent history or withdraw

Practice 5: Data subject rights (the DSAR pipeline)

Users have rights under GDPR Articles 15-22 and CCPA. The technical implementation often falls down in the same places.

Right to access (Art 15 / CCPA "right to know"): The user gets a copy of personal data held about them. Implementation:

• Enumerate every data store containing personal data tied to a user ID
• Pull from each store on request
• Format in a machine-readable export (JSON / CSV)
• Verify identity before disclosing — verification standard must be appropriate to sensitivity, not "we sent an email to the address on file"
• 30-day delivery (GDPR) / 45-day (CCPA)

Right to deletion (Art 17 / CCPA "right to delete"): The user gets data deleted. The technical reality is harder than it looks.

• Primary database: straightforward DELETE / soft-delete with retention
• Replicas / standbys: confirm replication propagated, or schedule for purge
• Backups: retention windows mean backups will continue to contain deleted data until they age out. GDPR is OK with this if you document the retention and re-delete on any restore
• Caches: Redis, CDN, application-level caches — invalidate on delete
• Search indexes: Elasticsearch / Algolia / Meilisearch — re-index, do not just delete the source
• Analytics: Mixpanel, Amplitude, Segment, GA — separate deletion APIs per vendor
• Data warehouses: BigQuery / Snowflake / Redshift — separate pipeline; usually batched
• Logs: application logs containing the user's PII age out by retention. Verify log retention is shorter than the user can reasonably expect
• Third parties / sub-processors: every vendor processing personal data on your behalf needs a deletion fan-out

Audit grep patterns:

• Search for places PII flows out: analytics\.track, segment\.identify, sentry\.setUser, mixpanel\.people\.set, datadog.*user, posthog\.identify
• Find vendor SDK initializations: Sentry\.init, analytics\.load, LogRocket\.init, FullStory\.init
• Each is a deletion-fanout destination

Right to portability (Art 20): Machine-readable export of data the user provided. Distinct from access — only covers data they gave you, in a structured format. JSON / CSV is fine.

Right to rectification (Art 16 / CCPA "right to correct"): Update incorrect data. Engineering hook: build the correction path into the product; do not require email-to-support.

Right to object (Art 21): Stop processing for direct marketing / specific other purposes. Engineering hook: a suppression list / opt-out flag honored everywhere processing happens.

Audit step: simulate a DSAR end to end against your own account before a real user does. Most teams find broken parts on first try.

Practice 6: Vendor / sub-processor management

Every vendor processing personal data is a sub-processor. GDPR requires a Data Processing Agreement (DPA) with each one and a documented sub-processor list available to users.

Engineering audit:

• Inventory every SaaS / API integration in the codebase that touches user data
• For each, confirm DPA on file (legal can answer)
• For each, confirm the data sent is the minimum needed
• For each, confirm deletion API or process exists
• For each, confirm data-residency (where is the data stored — EU, US, elsewhere) and that cross-border transfer mechanism is in place (Standard Contractual Clauses for transfers out of EU)

Common findings:

• Sentry / Datadog / LogRocket / FullStory capturing PII in error reports and session recordings
• Slack used for customer-data discussion (Slack becomes a sub-processor if PII is shared in DMs/channels)
• Analytics tools pre-2024 cross-border transfer (US adequacy decision after EU-US Data Privacy Framework — verify your vendors are listed)
• Webhook deliveries to vendors not under DPA

Practice 7: Breach notification

GDPR Article 33: notify supervisory authority within 72 hours of becoming aware of a personal data breach. Article 34: notify affected individuals without undue delay if breach poses high risk.

Engineering hooks (this skill is for the technical detection / scoping side; legal handles the actual notification):

• Detection: SIEM rules for personal-data exfiltration / unauthorized-access patterns (see siem-detection)
• Scoping: ability to determine quickly which records / fields / individuals were involved (audit logs, access logs, query history)
• Containment: revoke access, rotate credentials (see secrets-audit, incident-triage)
• Documentation: timeline-of-awareness clock starts when anyone on the team becomes aware, not when leadership is briefed — your detection-to-leadership latency directly impacts the 72-hour clock

Practice 8: DPIA (Data Protection Impact Assessment)

Required for high-risk processing (Art 35) — large-scale processing of sensitive data, systematic monitoring, automated decision-making affecting individuals.

Engineering input to a DPIA:

• Data flow diagram (re-use the threat-modeling artifact)
• Categories of personal data
• Categories of data subjects
• Recipients (internal + vendors)
• Retention periods per category
• Security measures (link to owasp-audit, iam-audit, crypto-audit outputs)
• Risk assessment + mitigations

This skill produces the engineering inputs; legal / privacy counsel produces the DPIA itself.

Verify, then record

A gap against a mandatory obligation (an Art 17 erasure path that misses a store, tracking that fires before consent, personal data sent to a vendor beyond the stated purpose) is a finding: the obligation is the intended control. Rate it by the exposure it creates for the personal data, not by the size of a possible fine. A gap with no exposure (a record of processing that doesn't list a basis, a retention period that isn't written down but is enforced) is a documentation gap, and a defense-in-depth gap is a hardening note. Neither goes in findings.json. Close every candidate with one verdict, as defined in references/findings-format.md:

• confirmed: a trace from where personal data enters to where it ends up in breach of the obligation, with no control on the way. Examples: DELETE /account removes the users row, but nothing calls the Segment deletion API or removes the Algolia record, so the user's profile stays searchable; Sentry.init({ sendDefaultPii: true }) plus setUser({ email }) ships every user's email and IP to the error tracker; the analytics snippet loads in the page head, before the consent banner records a choice.
• needs_validation: the code supports the claim but one fact lives with legal or in a console. Examples: whether a DPA is on file for a vendor that receives personal data; the vendor's retention setting, set in its dashboard; backup retention, set in the cloud console; whether the CDN caches authenticated profile pages. A DSAR or cookie check you describe but don't run is also needs_validation.
• rejected: a named control at a named location covers every path. Examples: jobs/erase-user.ts fans out to every vendor SDK the inventory found; a Sentry beforeSend hook strips user.email and cookies before any event leaves. A control inside a dependency counts: for an SDK whose default is sendDefaultPii: false and is never overridden, ruled_out_by.location is the lockfile line that pins the SDK, and control names the default and the version. "Not reachable" (a vendor SDK that's installed but never initialized) points at the dependency declaration.

1. Run the refutation pass in references/verification.md before confirming anything. A privacy notice, a DPA, or "legal approved it" does not rule out a data flow the code performs; a documented retention period doesn't rule out a store that never purges.

2. Calibrate severity with references/severity-calibration.md. The affected principal is the data subject. Sensitive personal data (Practice 1) reaching an ad vendor sits higher than an email in an error tracker under a DPA. A static trace caps confidence at medium; high needs a reproduced check ("reproduced": true), such as a test-account DSAR whose export or deletion you inspected.

3. Fingerprint as privacy-engineering/<class>/<file or resource>/<symbol or name>, with <class> one of classification, minimization, logging-pii, consent, lawful-basis, dsar-access, deletion-fanout, retention, vendor-sharing, transfer, breach-scoping. Examples: privacy-engineering/deletion-fanout/src/routes/account.ts/deleteAccount, privacy-engineering/vendor-sharing/src/lib/sentry.ts/Sentry.init, privacy-engineering/retention/aws/rds/prod-users-db/backup-retention. No line numbers; write ARNs and host:port with slashes. Use cwe where one fits (CWE-359 exposure of private personal information, CWE-532 personal data in logs, CWE-212 data not removed before transfer).

4. Put domain fields under ext:

   ext key	Value	Example
   obligation	Regulation and article or section the gap is against	"GDPR Art. 17(1)", "CCPA 1798.105", "GDPR Art. 7(3)"
   data_class	Classification from Practice 1	"personal", "sensitive_personal"
   processor	The vendor or sub-processor involved, when there is one	"Segment", "Sentry"

5. Findings about deployed resources rather than files (a cloud backup policy, a vendor dashboard setting, the cookies a staging page sets before consent): save the read-only output, redacted, to <audit dir>/evidence/<name>.json or .txt and point location and evidence[] at that file and line. Never save a personal data value or a secret; record field names and categories, not contents.

6. Write findings.json sorted by fingerprint and validate it:

   node references/validate-findings.mjs findings.json
   

   Optionally export SARIF: node references/to-sarif.mjs findings.json -o findings.sarif.

Output Format

Write findings.json first and validate it. The report is rendered from it and never changes a verdict or severity the JSON doesn't already say.

# Privacy Engineering Audit / Implementation Report
## Scope: [system / product / data flow]   ## Regulation context: [GDPR / CCPA / both / other]   ## Date: [date]
## findings.json: [path] — validated: [yes]

### Summary
- Confirmed: [N] (Critical [n] | High [n] | Medium [n] | Low [n])   Needs validation: [N]   Rejected: [N]

### Confirmed findings
#### [SEVERITY] [Title]  `fingerprint`
**Location:** `path:line`   **Obligation:** [ext.obligation]   **Data class:** [ext.data_class]   **Processor:** [ext.processor]
**Confidence:** [medium | high (reproduced)]
**Data flow:** [where the personal data enters → where it ends up]
**Exposure:** [whose data, which fields, who can now see or keep it]
**Fix:** [concrete change]
**Verify the fix:** [the DSAR, deletion or consent check that proves it]

### Needs validation
| Finding | Blockers | Check for the owner (engineering or legal) to run |
|---|---|---|

### Hardening notes (not findings)
- [gap] — [why it isn't a finding] — [effort]

### Documentation gaps (not findings)
- [record of processing, retention schedule, or DPIA input that's missing, with no exposure in the code]

### Rejected (do not re-raise)
| Fingerprint | Ruled out by | Location |
|---|---|---|

### Data inventory
| Data store | Classification | Categories of PI | Lawful basis | Retention |
|------------|----------------|------------------|--------------|-----------|

### DSAR pipeline status
- [ ] Access — implemented and tested end-to-end
- [ ] Deletion — implemented with full fan-out (DBs, caches, search, analytics, vendors)
- [ ] Portability — implemented in machine-readable format
- [ ] Rectification — self-service path exists
- [ ] Objection / opt-out — honored in all processing paths

### Vendor / sub-processor inventory
| Vendor | Purpose | Data shared | DPA | Deletion path | Data residency |
|--------|---------|-------------|-----|---------------|----------------|

### Consent records (if applicable)
[State: present / partial / missing. Storage location. Fields captured.]

### Remediation plan
| Priority | Item | Owner | Deadline |
|---|---|---|---|

Dispositions for confirmed findings (set later, usually by finding-triage): Fixed / Deferred / Accepted Risk / Mitigated (platform/config) / Requires major migration. Accepted-risk decisions for privacy findings often need legal sign-off as well as engineering; note this in the writeup.

Boundaries

• This skill produces technical implementations and audit findings; final compliance determinations require legal / privacy counsel
• For breach notification: the skill produces the technical scope and timeline; the notification itself requires legal review and goes through security-comms
• Refuse to help build systems designed to violate privacy laws — including dark-pattern consent flows, surveillance-as-marketing, or PI hoarding past lawful retention
• "Anonymization" is a high bar — pseudonymization (replacing direct identifiers with surrogate keys while retaining ability to re-identify) is not the same as anonymization (irreversibly removing identifiability). Treat re-identification risk seriously
• Cross-border transfer to non-adequate jurisdictions requires Standard Contractual Clauses or equivalent — the legal mechanism is not this skill's scope, but the engineering work of routing data through compliant pipelines is

References

• GDPR — full regulation: eur-lex.europa.eu/eli/reg/2016/679
• EDPB Guidelines — the European Data Protection Board issues binding guidance on GDPR interpretation
• ICO (UK) — accessible, practitioner-oriented guidance: ico.org.uk
• CCPA / CPRA — California AG: oag.ca.gov/privacy/ccpa
• IAPP — International Association of Privacy Professionals (training, certification, resource library)
• NIST Privacy Framework — companion to CSF, useful for translating between security and privacy controls
• ISO/IEC 27701 — privacy extension to ISO 27001
• "Privacy by Design" — Ann Cavoukian's seven foundational principles
• "Privacy Engineering" — Bibi Lin, M. Selvi, A. Acar (academic / practitioner overview)
• "The Algorithmic Foundations of Differential Privacy" — Dwork & Roth (for the anonymization / differential-privacy slice)
• Data Privacy Framework (EU-US, US-UK, US-Swiss) — current cross-border transfer mechanisms
• Shared references (copied into references/ at build time): findings-format.md, findings.schema.json, validate-findings.mjs, to-sarif.mjs, severity-calibration.md, verification.md