$npx -y skills add briiirussell/cybersecurity-skills --skill privacy-engineeringImplement 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 n
| 1 | # Privacy Engineering — GDPR / CCPA Technical Implementation |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | 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. |
| 6 | |
| 7 | 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. |
| 8 | |
| 9 | ## Regulatory landscape (engineering-relevant subset) |
| 10 | |
| 11 | The skill produces compliant technical implementations. Final compliance determinations stay with counsel; this skill is the technical execution layer. |
| 12 | |
| 13 | | Regulation | Scope | Key engineering hooks | |
| 14 | |---|---|---| |
| 15 | | **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) | |
| 16 | | **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 | |
| 17 | | **LGPD** (Brazil) | Brazilian residents | Similar shape to GDPR with local twists | |
| 18 | | **PIPEDA** (Canada) | Federal commercial | Consent-based with reasonable expectation, breach notification | |
| 19 | | **State laws (US)** | Varies — VA, CO, CT, UT, etc. | Roughly CCPA-shaped; engineering practices that meet GDPR + CCPA usually cover state laws | |
| 20 | |
| 21 | 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. |
| 22 | |
| 23 | ## Privacy by design — the engineering practices |
| 24 | |
| 25 | ### Practice 1: Data classification |
| 26 | |
| 27 | You cannot enforce privacy on data you have not classified. Every data store needs a classification. |
| 28 | |
| 29 | A minimal classification (more is fine, less is not): |
| 30 | |
| 31 | | Class | Definition | Engineering treatment | |
| 32 | |---|---|---| |
| 33 | | **Public** | Information published or freely sharable | No special handling | |
| 34 | | **Internal** | Internal business data, no PI | Standard access controls | |
| 35 | | **Personal** | Data identifying a natural person (email, name, IP, device ID, account ID) | Access logging, retention limits, deletion path | |
| 36 | | **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 | |
| 37 | | **Regulated** | PHI under HIPAA, PCI cardholder data, NPI under GLBA | Regulation-specific controls; out of scope here, see `hipaa-audit` and `pci-audit` | |
| 38 | |
| 39 | **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. |
| 40 | |
| 41 | ### Practice 2: Data minimization |
| 42 | |
| 43 | Collect the minimum to deliver the service; retain the minimum to deliver value; share the minimum with vendors. |
| 44 | |
| 45 | **Common minimization findings:** |
| 46 | - IP address logged in every request when it is only needed for rate limiting (truncate to /24 after rate-limit decision) |
| 47 | - Full user-agen |