Privacy-Enhancing Technologies Guide: Anonymisation, Differential Privacy and Clean Rooms

Organisations want to analyse, share and train models on personal data without exposing the people in it, and most of the techniques sold as "anonymisation" do not achieve that on their own. Privacy-enhancing technologies (PETs) range from masking and tokenisation through differential privacy to cryptography that computes on data nobody can see. Each protects against a different threat, at a different cost, with a different legal effect under the GDPR and UK GDPR. This guide explains what each does, where it fails, how to choose and how to roll them out. It is for security architects, data engineers, privacy engineers and DPOs who must turn "share it safely" into a design.

Key takeaways

• Pseudonymised is not anonymous. The EDPB states that pseudonymised data "remains information related to an identifiable natural person, and thus is personal data", so security and breach rules still apply.
• Test against three attacks. Singling out, linkability and inference, as defined by the Article 29 Working Party, are the yardstick: removing names and hashing IDs leaves all three open.
• Differential privacy is a budget, not a switch. NIST SP 800-226 treats epsilon as an upper bound on privacy loss that adds up across queries, and the unit of privacy matters as much as the number.
• Cryptographic PETs move trust, they do not remove it. MPC, private set intersection, homomorphic encryption and trusted execution environments protect data in use, but depend on non-collusion, key custody and attestation.
• Keys and service credentials decide the outcome. The HMAC key, tokenisation vault and clean room service accounts are the re-identification path, so they need the same protection as the raw data.

The legal line: personal, pseudonymised and anonymous

GDPR Recital 26 says identifiability must be judged by "all the means reasonably likely to be used" and that data protection principles "should therefore not apply to anonymous information". Article 4(5) defines pseudonymisation as processing so that data "can no longer be attributed to a specific data subject without the use of additional information", provided that information is kept separately and protected. The consequence is a three-way split:

The ICO describes identifiability as "a spectrum" and asks whether data is personal "in the hands of a given person", applying a "motivated intruder" test: someone with ordinary resources such as the internet and public records trying to re-identify people. In EDPS v SRB (C-413/23 P, 4 September 2025) the Court of Justice took a similar contextual view: pseudonymised data is not automatically personal data for every recipient, though it remains so for the controller that created it. EDPB Guidelines 01/2025 add the "pseudonymisation domain": the parties for whom attribution is meant to be precluded, a useful way to scope who must never receive the key.

The PET landscape at a glance

Masking, tokenisation and generalisation

Data masking

Static data masking permanently replaces sensitive values in a copy of the data, typically when production data is cloned for testing. Dynamic data masking leaves stored values unchanged and masks them at query or display time based on the user's role. PCI DSS v4.0 is the clearest regulatory example: Requirement 3.4.1 says no more than the BIN and last four digits of the PAN may be displayed without a documented business need, while Requirement 3.5.1 requires stored PAN to be rendered unreadable by truncation (which "permanently removes the middle digits"), index tokens, strong cryptography or one-way hashes, with Requirement 3.5.1.1 requiring those hashes to be keyed. NIST SP 800-188 warns that simple masking tools may not be enough for real de-identification.

Tokenisation and keyed hashing

ENISA's pseudonymisation report lists five core techniques: counter, random number generator, cryptographic hash, message authentication code and encryption, applied under deterministic, document-randomised or fully-randomised policies. It calls a plain hash "generally considered weak as a pseudonymisation technique as it is prone to brute force and dictionary attacks", showing that a SHA-256 hashed IPv4 address can be recovered by exhaustive search in about two minutes on a laptop. MACs such as HMAC-SHA-256 are "generally considered as a robust pseudonymisation technique". Practical rules:

• Use a keyed function: HMAC with a key in a KMS or HSM, never an unsalted hash of an email, phone number or national ID.
• Choose the policy deliberately: deterministic pseudonyms allow joins across datasets (useful for analytics, bad for linkability); randomised pseudonyms prevent joins.
• Separate keys per domain: one key per recipient or project stops two recipients from linking their datasets.
• Vault-based tokenisation: random tokens have no mathematical link to the value, but the vault becomes a high-value target to lock down and log.

Generalisation models

k-anonymity ensures each record shares its quasi-identifier values (for example postcode district, age band, sex) with at least k-1 others. l-diversity adds that each such group has at least l distinct sensitive values, and t-closeness requires the distribution of sensitive values in each group to be close to the overall distribution. The ICO notes that k-anonymity is weak against background knowledge and degrades with many variables. The Article 29 Working Party's Opinion 05/2014 summarises what each family leaves open:

The Opinion states "pseudonymisation is not a method of anonymisation". No row reaches "No" on all three, so effective anonymisation combines techniques with release controls.

Differential privacy in practice

Differential privacy (DP) bounds how much any one person's data can change the output of an analysis. NIST SP 800-226 (March 2025) is the most practical reference, organised as a "differential privacy pyramid": the privacy parameter and unit of privacy at the top, algorithms and their correctness, utility and bias in the middle, and deployment concerns (query model, trust model, side channels, security and access control) at the base.

• Epsilon: "Smaller ε means stronger privacy but lower accuracy." NIST notes that 0.1 is generally strong, values below 1 are reasonable and many deployments use 1 to 20, warning that large values may not give meaningful privacy.
• Privacy budget and composition: epsilons add across analyses of the same data. Ten queries at 0.1 consume a budget of 1. Set a budget per dataset and stop answering when it is spent.
• Unit of privacy: "Event-level privacy can result in surprisingly weak privacy guarantees." Prefer user-level privacy, which protects everything a person contributes.
• Bounded vs unbounded DP: in bounded DP neighbouring datasets are the same size and differ by changing one record; in unbounded DP they differ by adding or removing a person. NIST treats unbounded as the safer default because bounded DP can reveal dataset size.
• Laplace vs Gaussian mechanism: the Laplace mechanism adds noise scaled to L1 sensitivity and gives pure ε-DP; the Gaussian mechanism uses L2 sensitivity and gives (ε, δ)-DP. Keep δ small: NIST recommends δ no larger than 1/n² for a dataset of n people.
• Central vs local model: central DP trusts a curator with raw data and adds noise to outputs; local DP adds noise on the device before collection, needs no trusted curator, but costs far more accuracy.
• DP-SGD for machine learning: differentially private stochastic gradient descent clips each example's gradient and adds Gaussian noise during training, with a privacy accountant tracking cumulative epsilon across steps. It limits memorisation of training records at some cost to accuracy.

NIST also warns to "avoid custom implementations" and use well-tested libraries, and that DP "does not mitigate privacy risks associated with other (non-differentially private) releases" of the same data. The ICO treats DP as a way of measuring disclosure, not an anonymisation technique by itself.

Synthetic data, federated learning and trusted research environments

• Synthetic data generation: a model learns the statistical patterns of real data and generates new records. The ICO warns that some generation methods are vulnerable to model inversion and that outliers are the records most likely to be reproduced. Generate with differential privacy, test outputs for near-copies of real records, and treat synthetic data as personal data until a re-identification test says otherwise.
• Federated learning: the model travels to the data and only updates are shared. The ICO states that "Using federated learning alone may not achieve appropriate protection of personal information", because updates can leak training data through model inversion or membership inference, and recommends combining it with DP, secure multi-party computation or homomorphic encryption.
• Trusted research environments (TREs): instead of releasing data, analysts work inside a controlled platform and only checked outputs leave. The Office for National Statistics' Five Safes (safe people, safe projects, safe settings, safe data, safe outputs) is the common design model, and NIST SP 800-188 lists enclaves among its data-sharing models, overseen by a Disclosure Review Board.

Clean rooms and privacy-enhancing cryptography

Data clean rooms

A data clean room lets organisations (an advertiser and a publisher, a bank and a retailer) analyse combined data without seeing each other's records. The IAB Tech Lab's 2023 clean room guidance and its Open Private Join and Activation specification describe matching through private set intersection or a trusted execution environment. Controls that matter more than the product:

• Query restrictions: approved query templates or an allow-list, not free SQL.
• Minimum aggregation thresholds: suppress any result covering fewer people than a set threshold, and add differential privacy noise where results are released repeatedly.
• Operator access: who at the provider or host partner can see raw inputs, and is it logged?
• Purpose and retention: joint controllership or processor terms that fix the purpose, prohibit re-identification and set deletion dates.

Cryptographic PETs

NIST's Privacy-Enhancing Cryptography (PEC) project tracks these tools, plus functional encryption, group and ring signatures, private information retrieval and structured encryption.

• Secure multi-party computation (MPC): parties compute a joint function, such as fraud scores across banks, without revealing inputs. The ICO notes it needs "appropriate trust mechanisms" against collusion and can be computationally expensive for real-time processing.
• Private set intersection (PSI): finds common customers or identifiers without exposing the rest. The ICO warns that a very small intersection may itself reveal who is in it.
• Multi-party threshold cryptography (MPTC): applies MPC so no single party holds a whole signing or decryption key. NIST published its First Call for Multi-Party Threshold Schemes (NIST IR 8214C) on 20 January 2026.
• Confidential computing: the Confidential Computing Consortium defines it as protecting data in use by computing in a hardware-based, attested trusted execution environment. Verify attestation before releasing keys to the enclave; the ICO lists side-channel and timing attacks as the main TEE risks.
• Zero-knowledge proofs: prove a statement (over 18, holder of a valid credential) without revealing the underlying data, the basis of selective disclosure in digital identity wallets. See the Digital Identity Wallets Guide.

Choosing the right PET

• Test and development data: static masking plus synthetic data for edge cases. Do not copy production personal data into lower environments unmasked.
• Internal analytics: keyed pseudonymisation with the key held outside the analytics team, plus dynamic masking for ad hoc users.
• Public statistics or open data: differential privacy or a documented disclosure-control process; k-anonymity alone is not enough for high-dimensional releases.
• Sharing with a partner: a clean room or PSI when only the overlap matters; MPC when both sides need a joint computation; a TRE when external researchers need record-level access.
• Training ML models on personal data: DP-SGD or federated learning with DP; test the model for memorisation before release.
• Third-party infrastructure: confidential computing with attestation-gated keys.

Small vs large organisations: a small team gets most of the benefit from HMAC pseudonymisation, masking non-production copies and aggregation thresholds, all of which existing databases and cloud services support. Differential privacy, MPC and homomorphic encryption need specialist skills; larger organisations should adopt them through tested libraries or managed services, judging maturity with technology readiness levels as the ICO suggests.

Implementing PETs

1. Define the release model and attacker: who receives the output, what they know and what a motivated intruder could link it to. Record it in the DPIA.
2. Classify fields: direct identifiers, quasi-identifiers, sensitive attributes and free text. Free text and timestamps leak most.
3. Pick techniques per field and per release, using the table above, and set parameters (k, epsilon, aggregation threshold, key domain) with written justification.
4. Pilot in parallel: run the PET pipeline beside the existing one on a subset and compare utility (accuracy, error rates, reconciliation) before switching.
5. Attack it: run a re-identification test against singling out, linkability and inference, using external datasets an intruder could obtain. For models, run membership inference tests.
6. Release with controls: contract terms prohibiting re-identification, access logging and a budget or threshold enforced by the platform rather than by policy alone.
7. Keep a rollback: retain the previous pipeline and the ability to withdraw a release or rotate a pseudonymisation key. If a release proves re-identifiable, pull it, rotate keys and treat it as a potential personal data breach.
8. Re-assess: new public datasets and attacks change what is "reasonably likely".

Where identity fits

Every PET has a small set of secrets and privileged identities that undo it. The pseudonymisation key, the token vault's service account, the clean room's integration credentials and the KMS role that releases keys to an enclave all deserve privileged-access treatment: separate ownership from the data consumers, short-lived credentials, logging of every use and alerting on bulk detokenisation. See the Cryptographic Key Management Guide and the Secrets Management Guide.

Detection and measurement

Log detokenisation and key use by identity and volume, clean room queries and result sizes, privacy budget use per dataset, and every external release with its parameters. Metrics:

• Non-production exposure: percentage of non-production databases containing unmasked personal data (target: zero).
• Keyed pseudonymisation coverage: percentage of analytics datasets where direct identifiers are replaced by keyed pseudonyms or tokens.
• Re-identification testing: percentage of external releases with a documented re-identification test before release.
• Privacy budget adherence: number of datasets where cumulative epsilon exceeded the approved budget.
• Detokenisation anomalies: detokenisation or key-use events outside approved services, and time to investigate them.
• Clean room suppression rate: share of queries blocked or suppressed by aggregation thresholds, watched for sudden drops that suggest a loosened control.

Framework mapping

Common failure patterns

• Unsalted hashes called anonymisation: hashing emails or phone numbers with SHA-256 is reversible by dictionary attack, as ENISA demonstrates; use a keyed function and treat the output as personal data.
• Sharing raw data when a derived dataset was intended: in the Microsoft SAS token exposure, researchers publishing AI training data used an over-broad storage token that exposed 38TB, including workstation backups and Teams messages. Publish derived data from an isolated location with a scoped, expiring credential.
• Ignoring linkage through relationships: data about one person can expose others. The 23andMe breach reached millions of people from about 18,000 compromised accounts because the relatives feature exposed matches' profile data.
• Unbounded queries against "aggregated" data: without thresholds or a privacy budget, users can difference two queries to isolate one person.
• Event-level or large-epsilon DP presented as strong privacy: publish epsilon, delta and the unit of privacy with every DP release so reviewers can judge the guarantee.
• Keys stored next to the data: a key or token vault readable by the dataset's own service account gives no protection when that account is compromised.

Practitioner checklist

• Inventory non-production copies of personal data and mask or replace them with synthetic data.
• Replace plain hashes of identifiers with HMAC or vault tokens, with keys in a KMS or HSM and one key per sharing domain.
• Classify every field as direct identifier, quasi-identifier, sensitive attribute or free text before any release.
• Run and document a singling out, linkability and inference test for each external release.
• Set and enforce a privacy budget, unit of privacy and delta for every DP deployment, using a tested library.
• Require query templates, minimum aggregation thresholds and operator access logging in clean rooms.
• Test ML models trained on personal data for memorisation and membership inference before release.
• Give keys, token vaults and clean room credentials named owners, short lifetimes and alerting on bulk use.
• Re-review high-risk releases annually.

Standards and references

• NIST: SP 800-226 Guidelines for Evaluating Differential Privacy Guarantees
• NIST: SP 800-188 De-Identifying Government Datasets: Techniques and Governance
• Article 29 Working Party: Opinion 05/2014 on Anonymisation Techniques
• EDPB: Guidelines 01/2025 on Pseudonymisation
• ICO: Privacy-enhancing technologies (PETs)
• ICO: How do we ensure anonymisation is effective?
• ENISA: Pseudonymisation techniques and best practices
• NIST: Privacy-Enhancing Cryptography project

Related NHI Mgmt Group resources: Identity Data Privacy and Consent Guide · Cryptographic Key Management Guide · Secrets Management Guide · Permission-Aware RAG Guide. This guide summarises regulator guidance on anonymisation, pseudonymisation and PETs and is not legal advice.