Privacy Engineering

Definition

Privacy engineering makes privacy obligations — minimisation, purpose limitation, consent, access, deletion, residency — properties the architecture enforces, rather than commitments the organisation makes on its behalf.

The principles that have architectural consequences

Data minimisation. Do not collect what you do not need. This is the single most effective control available: data never collected cannot be breached, cannot be requested, cannot be mis-shared, and costs nothing to store. In a breach, the data you did not need is the part that hurts most.

Purpose limitation. Data collected for one purpose should not silently be used for another. In practice this means recording purpose alongside data and enforcing it at access, which most systems do not do and which is what makes "we will only use it for X" a real statement rather than a promise.

Deletion as a design requirement. A right to erasure must propagate to replicas, caches, search indexes, warehouses, backups, logs, third-party processors, and machine learning training sets. That is a deletion propagation mechanism, not a runbook, and it must exist before the first request arrives.

Pseudonymisation and separation. Keep identifiers separate from behaviour, joined only where necessary. This reduces the impact of a breach of either store, and it is cheap if designed in.

Field-level thinking. A retention obligation and an erasure right both apply to the same customer record. The resolution is per-field — delete or anonymise identity attributes, retain the financial record with a pseudonymous reference. Record-level thinking makes this look unresolvable.

What must exist as infrastructure

• A data inventory and classification that is maintained. If you cannot list where personal data lives, you cannot delete, export or protect it, and this artefact is the difference between a one-day response and a two-week archaeology exercise.
• A subject access export that is automated. Manual assembly does not scale past a handful of requests.
• Consent state as a queryable service, consulted at the point of use rather than checked at collection and then forgotten.
• Residency as a placement rule the system cannot violate, not a policy.

Failure scenarios

• Personal data in logs, which is the most common finding and the least controlled datastore.
• Deletion that only removes the primary row, leaving copies everywhere.
• Backups outside the policy, so a restore resurrects deleted people — unless a suppression list is re-applied.
• Consent recorded and never enforced at the point of processing.
• Free-text fields containing personal data that no classification scheme catches.

Interview question

"Design the mechanism by which a deletion request propagates through a system with a warehouse, a search index, backups and three third-party processors."