Privacy engineering
Privacy engineering in practice
Privacy engineering turns principles into testable requirements: purpose limitation, minimization, retention limits, access control, transparency, and rights fulfillment. Start with data mapping: what is collected, why, where it flows, who accesses it, how long it is kept, and how it is deleted. Use privacy patterns-data avoidance, separate storage of identifiers, tokenization, purpose-based access control, consent and preference management, automated retention, and rights request workflows. Build privacy into design reviews and acceptance criteria; test that deletion propagates to caches, logs, backups, and derived datasets. Select PETs based on the actual threat model, not fashion. Privacy engineering is iterative and must account for changes in data flows.
Traps
The biggest trap is bolt-on compliance-adding a notice after the system is built. Another is testing only the primary database when copies exist in analytics warehouses, queues, backups, and logs. Consent withdrawal must propagate to downstream systems; a checkbox that only updates a profile is insufficient. Also, "we minimized fields" can be false if identifiers remain in metadata or free-text notes.
Rule of thumb / worked example
Rule: Every data element needs a purpose, an access rule, and a deletion path. Example: a feature wants to personalize content. Design it to use a pseudonymous user key, separate the identity mapping, enforce purpose-based access control, define retention, and build a deletion job that removes the key and derived features. Acceptance test: after deletion, the system cannot re-link activity to the person.