Start with the privacy model. The model is a formal statement of what the system does and does not do with personal data. The model is the input to the data flow mapping, the controls, and the audit. The model is reviewed by the privacy office, the security team, the engineering team, and the legal team. The model is the document that the system is built to satisfy.
Privacy Engineering
Privacy is a design constraint with measurable properties. The consent orchestration is a stateful workflow, not a banner. The privacy-enhancing technologies are the toolkit. The operating model is what keeps the privacy claims auditable.
On this page
§ 01 ·
What privacy engineering is
Privacy engineering is the discipline of designing, building, and operating systems such that the privacy properties the system is supposed to have: minimal data collection, purpose limitation, data minimisation, consent enforcement, the right to be forgotten, the right to portability, the right to explanation, are properties of the implementation, not properties of a privacy policy document.
The discipline covers the privacy model (the formal statement of what the system does and does not do with personal data), the controls (the translation of the model into specific technical mechanisms), the privacy- enhancing technologies (the cryptographic, statistical, and architectural patterns that implement the controls), and the operating model (the people, the processes, the tooling that keeps the privacy claims auditable).
The most important property of a privacy engineering practice is that the privacy is a property of the system, not a property of the documentation. A privacy policy that says "we minimise data" is not the same as a system that minimises data. A privacy policy that says "we honour deletion requests" is not the same as a system that can actually delete the data the user thinks the system has.
§ 02 ·
The privacy-enhancing technologies
The privacy-enhancing technologies (PETs) that have moved from research into production use over the last decade:
Differential privacy
A statistical framework for releasing aggregate information about a dataset while limiting what can be inferred about any individual record.
- Mechanism. Calibrated noise addition.
- Parameter. The privacy budget (epsilon).
- Use case. Aggregate analytics on personal data.
- Production users. Apple, Google, US Census Bureau.
Federated learning and federated analytics
The model (or the query) moves to the data, not the data to the model. The training (or the query) runs locally on the device or in the data custodian's environment; only the model update (or the aggregate result) crosses the trust boundary.
- Use case. Cross-organisational ML on data that cannot be pooled.
- Trust model. Data custodian retains the raw data.
- Returned signal. Model update or aggregate result.
Secure enclaves (TEEs)
The computation runs inside a hardware-protected environment that the operator cannot inspect. The data is decrypted inside the enclave; the result is encrypted before it leaves.
- Use case. Computation on sensitive data with strong confidentiality requirements.
- Implementations. Intel SGX, AWS Nitro Enclaves, Azure Confidential Computing.
- Trust boundary. Operator cannot inspect the enclave.
Homomorphic encryption
The computation runs on encrypted data; the result is the encryption of the computation's result.
- Use case. Computation on data that must remain encrypted end-to-end.
- Trade-off. Strong theoretical confidentiality; significant performance cost.
Secure multi-party computation (MPC)
The computation runs across multiple parties, each holding part of the input; no party learns the other parties' input.
- Use case. Joint computation where the parties do not trust each other with the raw data.
- Trust model. Distributed across parties.
- Returned signal. The agreed output.
Zero-knowledge proofs
The prover demonstrates a property of a secret without revealing the secret.
- Use case. Selective disclosure ("I am over 18 without revealing my date of birth").
- Use case. Credential verification without revealing the underlying data.
- Trade-off. Computationally expensive; growing production tooling.
The PET is the tool; the privacy model is the architecture
Pick the PET that fits the threat model, the performance budget, and the regulatory context.
§ 03 ·
State of the practice
7
GDPR principles (lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity & confidentiality, accountability)
GDPR Article 5(1) — 7 principles (with integrity/confidentiality and accountability counted as one)
~3-7
Common PET categories in production use (differential privacy, federated learning, TEEs, homomorphic encryption, MPC, ZKPs, synthetic data)
Industry observation; varies by use case
1
Right answer to 'which PET' — the one that fits the threat model, the performance budget, and the regulatory context
§ 04 ·
Questions we get asked
When the system publishes aggregate statistics about a population, and the population includes individuals whose privacy must be protected. Differential privacy is not the right answer for individual-level decisions (a credit decision, a hiring decision); it is the right answer for population-level statistics (a census, a usage report, a recommendation model). The privacy budget (epsilon) is the parameter; the right answer is the smallest epsilon that gives the desired utility.
When the system must compute on sensitive data, the operator must not be able to inspect the data, and the operator must not be able to tamper with the computation. The enclave is the right answer for confidential computing: multi-party computation where one party is the cloud provider, and the customer does not want the cloud provider to see the data. The enclave is not the right answer when the threat model is "the cloud provider steals the data"). The enclave is not designed to protect against the cloud provider's own hardware; it is designed to protect against the cloud provider's operators and software.
As a workflow, not a database query. The workflow identifies all the systems that hold the data subject's data (the data inventory is the input), submits the deletion request to each system, tracks the completion of each deletion, and produces an audit trail. The workflow handles the exceptions: backups (the deletion propagates to backups on the next retention cycle, with a documented timeline), derived data (the deletion propagates to derived data, with a documented propagation rule), legal hold (the deletion is suspended if the data is under legal hold, with a documented exception). The workflow is auditable.
As a stateful workflow, not a banner. The consent is recorded as a structured artefact: the user identifier, the purpose, the legal basis, the timestamp, the source (the URL, the form, the interaction), the version of the privacy policy. The consent artefact is the input to the data processing: every processing action is gated on the consent artefact; the consent artefact is the audit trail. The consent artefact is portable (the user can download it, the regulator can request it). The consent is revocable (the user can withdraw, the withdrawal propagates to the systems that depended on the consent).
The one the user has consented to, in the context they have consented to, with the controls they have consented to. The balance is not a technical parameter; it is a user choice, documented in the consent artefact, enforced by the system, auditable by the regulator. The right answer is not the maximum privacy; the right answer is the privacy the user chose, in the context the user chose.
§ 05 ·
Patterns we design our practice to avoid
A privacy policy that says "we minimise data" is not the same as a system that minimises data. A privacy policy that says "we honour deletion requests" is not the same as a system that can actually delete the data. The privacy policy is a document; the privacy practice is the system. The system is the thing that gets audited.
A consent banner is a UI element. The consent is a structured artefact that the system records, the system enforces, and the system audits. A banner is the visible part; the artefact is the part that does the work.
A privacy review at the end of the SDLC produces a finding list, not a privacy-respecting system. By the time the review runs, the architecture is set, the data flows are baked in, and the changes the review recommends are expensive. Privacy is a design activity, not an audit activity.
A database query that deletes the user's record is not the right to be forgotten. The right to be forgotten is a workflow that identifies all the systems that hold the data, propagates the deletion to each system, handles the exceptions (backups, derived data, legal hold), and produces an audit trail. The workflow is auditable; the database query is not.
Differential privacy is one PET in a broader toolkit. The right answer for aggregate analytics; not the right answer for individual-level decisions. The right answer for cross-organisational analytics; not the right answer for cross-organisational ML. The right answer is the PET that fits the threat model, the performance budget, and the regulatory context.
A data inventory that lives in a spreadsheet is a data inventory that is out of date. The inventory has to be generated from the system: the data flows, the schema, the data lineage, not maintained by hand. The inventory is the input to the consent orchestration, the right to be forgotten, the breach notification, and the privacy review.
A privacy team that reviews systems after they are built is a privacy team that produces finding lists, not privacy-respecting systems. The right answer is to embed the privacy team in the engineering team, the way the security team should be embedded. The privacy review is part of the design review; the privacy controls are part of the paved roads.
§ 06 ·
Evidence & references
Public frameworks, standards, and writing that inform our practice.
European Union, 2016 (in force 2018)
The regulatory framework that has driven most of the global privacy practice. The 7 principles (Article 5), the data subject rights (Articles 12-22), the privacy by design obligation (Article 25), the data breach notification obligation (Article 33) are the canonical references. The text is the legal requirement; the practice is the implementation.
NIST SP 800-188 — Trusted Geolocation in the Cloud
NIST, 2020 (withdrawn 2025)
Withdrawn but still useful as a reference. The deprecation pattern (NIST withdraws standards that are no longer fit for purpose) is a useful signal that the privacy practice needs to be re-evaluated regularly. The practice is the architecture; the standard is the vocabulary.
ISO, 2019 (current)
The international standard for privacy information management. The right framework for organisations that operate globally and want a single privacy management system across jurisdictions. The certification is the attestation; the practice is the implementation.
The Algorithmic Foundations of Differential Privacy
Dwork and Roth, Foundations and Trends in Theoretical Computer Science, 2014
The canonical academic reference. The book is the rigorous treatment of the privacy budget, the composition theorems, and the tradeoffs between privacy and utility. The right answer for anyone implementing differential privacy in production.
NIST, 2025 (draft)
The recent NIST guidance on differential privacy in production. The guideline is the bridge between the academic theory and the production practice: the right answer for choosing the privacy budget, validating the mechanism, and auditing the implementation.
ISO/IEC 27400 — IoT security and privacy guidelines
ISO, 2022 (current)
The IoT-specific privacy guidance. The right framework for systems that collect data at the edge, where the consent orchestration is constrained by the device capabilities. The framework is the bridge between the GDPR-style consent model and the device-constrained reality.
CIPL, current
The industry-association framing. The CIPL's accountability-based privacy framework is the most useful of the industry references for organisations that operate across multiple jurisdictions. The framework is the vocabulary; the implementation is the practice.
Building a privacy engineering practice?
If you are weighing a privacy engineering initiative, evaluating a PET, or trying to make an existing privacy practice more than a documentation exercise, we are useful at the boundary between the privacy model and the implementation. A short conversation is the right next step.
Learn more