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.

Regulatory landscape (engineering-relevant subset)

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

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):

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.