/privacy-engineering

name: privacy-engineering
description: "Implement and audit privacy controls in product and infrastructure — GDPR, CCPA / CPRA, LGPD, PIPEDA. Covers data minimization, lawful basis, consent management, data subject access requests (DSARs — access, deletion, portability), data processing agreements, DPIA / TIA, breach notification timing, data classification, and the technical implementation of 'right to be forgotten' across backups, caches, analytics, and third parties. Use when the user mentions 'GDPR,' 'CCPA,' 'CPRA,' 'data privacy,' 'privacy engineering,' 'data subject access request,' 'DSAR,' 'right to deletion,' 'right to be forgotten,' 'data portability,' 'consent management,' 'cookie consent,' 'data minimization,' 'DPIA,' 'data protection impact assessment,' 'breach notification,' 'BAA,' 'DPA,' 'data processing agreement,' 'sub-processor,' 'cross-border data transfer,' 'SCCs,' or needs to implement or review privacy controls."
allowed-tools: Read, Grep, Glob, Bash, Write, WebSearch

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.

| 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.

Com