Privacy Engineering
CDPSE Domain 4, Privacy Engineering, tests the technical controls and design choices that make privacy requirements real in systems.
Core rules and concepts
- Translate privacy requirements into architecture: data minimization in schemas, purpose binding, secure defaults, role- and attribute-based access control, encryption in transit and at rest, and key management.
- Select privacy-enhancing technologies (PETs) from a threat model: tokenization, masking, pseudonymization, differential privacy, secure multiparty computation, homomorphic encryption, and synthetic data. Each has utility and re-identification trade-offs.
- Build consent and preference management as a backend service so consent state is granular, revocable, and enforced downstream-not only a cookie banner.
- Instrument logging and monitoring: immutable audit logs, access reviews, DLP, and alerting on anomalous access.
- Integrate privacy into the secure SDLC: requirements, threat modeling such as LINDDUN, code review, privacy test cases, and decommissioning that deletes data from replicas and caches.
Worked example
An analytics team requests user-level event data. Engineering should collect only necessary events, pseudonymize user IDs with a rotating salt, restrict raw access, aggregate for dashboards, apply differential privacy where appropriate, and set a 90-day retention. The reasoning: the design reduces identifiability while preserving analytical utility, and controls are testable.
Traps
Treating encryption as a complete privacy solution; assuming hashed emails are anonymous; applying k-anonymity to high-dimensional data without testing; enforcing consent only in the UI; forgetting logs, caches, and backups in deletion; relying on a vendor certificate instead of configuration evidence.