Privacy-Enhancing Technologies Buyer's Guide

Organisations buying privacy-enhancing technologies (PETs) often pay for a cryptographic or statistical guarantee they cannot verify, applied to a use case the product was never designed for, and then discover the output is still personal data. The PET market now spans differential privacy platforms, synthetic data generators, federated learning frameworks, confidential computing services, data clean rooms, and libraries or services for homomorphic encryption, secure multi-party computation (SMPC), private set intersection and zero-knowledge proofs. This vendor-neutral buyer's guide explains how to define requirements, which capabilities separate a real privacy control from a marketing label, what to ask vendors, which red flags to walk away from, and how to run a proof of concept on your own data. It is for privacy engineers, data protection officers, security architects and procurement leads. Masking and tokenisation products are covered separately in the Data Masking and Tokenisation Buyer's Guide, and the techniques themselves in the Privacy-Enhancing Technologies Guide.

Key takeaways

Start from the data flow, not the technique. Write down who holds the data, who must not see it, what output is needed and who receives it. That decides whether you need output privacy (differential privacy, synthetic data), input privacy (SMPC, homomorphic encryption, TEEs) or both.
Most PETs do not make data anonymous. Under GDPR, pseudonymised data remains personal data (Recital 26). Buy a PET to reduce risk and support data protection by design (Article 25), not to take processing out of scope, unless your own anonymisation assessment shows otherwise.
Demand parameters, not adjectives. A differential privacy product must state its privacy unit, epsilon and delta per release and in total; a confidential computing service must show remote attestation evidence; a cryptographic product must name its schemes and parameter sets.
Prefer well-tested libraries and published designs. NIST SP 800-226 strongly recommends tested library implementations of differential privacy over custom code, and the same logic applies to cryptographic PETs.
Test utility and leakage together. A proof of concept must measure whether outputs are still useful and whether they leak, using your own data, your own analysts and a basic attack test.

Define requirements

PET purchases fail most often because the requirement was written as a product name ("we need a clean room") rather than as a protection goal. Use the questions below before you look at any vendor.

Question	Why it matters	Points towards
Who must not see the raw input?	An external partner, the cloud operator, your own analysts or the vendor each need a different protection	Partner: SMPC, PSI, clean room. Cloud operator: TEE or homomorphic encryption. Analysts: differential privacy or synthetic data
What is released, and to whom?	Aggregate statistics, a trained model, a row-level dataset and a yes or no answer carry very different leakage risk	Aggregates: differential privacy. Row-level: synthetic data with privacy evaluation. Yes or no: PSI or zero-knowledge proof
Is the query set fixed or open-ended?	Open-ended querying consumes privacy budget and invites reconstruction attacks	Fixed: precomputed DP releases. Open-ended: query gateway with budget accounting
What latency and scale are acceptable?	Homomorphic encryption and SMPC carry large compute and network overheads; TEEs run near native speed	Real-time: TEE. Batch overnight: SMPC or homomorphic encryption may be viable
What is the legal basis and controller model?	Joint controllership, processor terms and international transfers do not disappear because data is encrypted	DPIA first; see the DPIA Guide
Who must trust whom?	Every PET has a trust model: a curator, a hardware maker, a non-colluding party or a key holder	Pick the model your risk owner and partners will accept in writing

Small organisations sharing data with one partner usually get more from a well-governed clean room or a single differential privacy library than from a platform. Large organisations with many data products should treat PETs as a platform capability with a central privacy budget, policy engine and evidence store, and should expect to combine more than one technique. The ICO notes that federated learning alone may not achieve appropriate protection and may need to be combined with other PETs, a point that holds across the category.

Capability areas

The categories below follow the PET types described by the ICO and the NIST Privacy-Enhancing Cryptography project. Products increasingly combine several.

Product category	What it protects	What it does not protect	Typical buyer
Differential privacy platforms and libraries	Individuals in released statistics or models, by adding calibrated noise to outputs	Raw data at rest or in processing; NIST SP 800-226 stresses that DP protects released outputs only	Statistics, analytics and data product teams
Synthetic data generators	Direct sharing of real records, by releasing artificial records with similar properties	Memorised outliers and rare records unless the generator is trained with formal privacy guarantees	Test data, research and ML teams
Federated learning frameworks	Central pooling of raw training data	Leakage through model updates; needs secure aggregation and often DP on updates	Multi-site ML in health, finance, devices
Confidential computing (TEEs)	Data in use from the host OS, hypervisor and cloud operator, with remote attestation of the code	Bugs in the code you run inside the enclave, and side-channel weaknesses of the hardware	Cloud processing of sensitive data, multi-party analytics
Data clean rooms	Raw record exchange between parties, by allowing only approved queries and aggregate outputs	Inference attacks through repeated or narrow queries unless thresholds, noise or budgets are enforced	Marketing measurement, retail and media partnerships
Homomorphic encryption	Data during computation by an untrusted party	The result once decrypted; key management is entirely your problem	Outsourced scoring, encrypted search, specialist analytics
SMPC and private set intersection	Each party's inputs from the others during joint computation	Output leakage; collusion beyond the threshold the protocol assumes	Fraud consortia, cross-bank analytics, matching customer lists
Zero-knowledge proofs	The underlying data when proving a statement about it	Whether the underlying claim was true at issue; that depends on the issuer	Age and attribute proofs, verifiable credentials

For depth on individual techniques see the Differential Privacy Guide, Confidential Computing Guide, Data Clean Rooms Guide and Secure Multi-Party Computation.

Must-have capabilities across categories

Stated guarantee: a written description of what is protected, against whom, under which assumptions, in terms an auditor can check.
Parameter transparency: for DP, the unit of privacy (user-level by default, as NIST SP 800-226 recommends), epsilon, delta and composition method; for cryptography, the scheme, library and security level; for TEEs, the hardware generation and attestation format.
Budget or policy enforcement: a central control that tracks cumulative privacy loss or query policy per dataset and blocks releases that exceed it.
Key and secret handling: customer-managed keys in your KMS or HSM, with attestation-gated key release for TEEs (NIST SP 800-53 SC-12).
Audit evidence: immutable logs of every query, release, key release and policy change, exportable to your SIEM (AU-2, AU-6).
Utility reporting: error bounds or utility metrics published with each release, so analysts know how much to trust a number.

Evaluation criteria

Criterion	Weight (suggested)	What good looks like	How to test
Guarantee clarity	High	Threat model and trust assumptions documented; no claim of "anonymous" without an assessment method	Ask your DPO to restate the guarantee from the documentation alone
Implementation provenance	High	Built on a published, peer-reviewed or open source library; independent review or audit available	Request the library name and version and any third-party assessment
Privacy accounting (DP, clean rooms)	High	Per-dataset budget with composition across all releases, user-level unit, delta at or below 1/n squared	Run the same query repeatedly and watch the budget fall and then block
Attestation (TEE)	High	Remote attestation verified by your own verifier or policy before keys or data are released	Change the workload image and confirm key release fails
Utility on your data	High	Error within the tolerance your analysts set in advance	Compare 20 benchmark queries or model metrics against the raw baseline
Leakage resistance	Medium to high	Small-cell suppression, query thresholds, protection of outliers, membership inference resistance for synthetic data	Run a differencing query pair and a nearest-neighbour check on synthetic output
Performance and cost	Medium	Throughput and latency measured on realistic volumes, compute cost predictable	Time a full production-sized job in the POC
Integration and identity	Medium	SSO, role separation, workload identity for pipelines, API keys scoped and rotated	Map every credential the product needs and who owns it
Governance and exit	Context dependent	DPA, sub-processors, residency, export of policies, logs and keys	Review contract terms and run an export

Use the Buyer's Guide Methodology and Scoring Template to turn the weights into a score.

Questions to ask vendors

State the privacy guarantee in one paragraph: what is protected, from whom, and what assumptions must hold. Which parties must be trusted, and which must not collude?
For differential privacy: what is the unit of privacy, what epsilon and delta do you default to, how is composition tracked across releases and users, and can we set a hard total budget per dataset?
Which open source or published library implements the mechanism, which version, and has it been independently reviewed? Have you addressed floating-point and timing side channels?
For synthetic data: is the generator trained with formal differential privacy, and what membership inference and attribute inference tests do you run before release?
For confidential computing: which hardware TEE and attestation service do you use, can we verify attestation evidence ourselves, and is key release bound to a measured workload?
For homomorphic encryption or SMPC: which schemes and parameter sets, what security level, what are the measured overheads on a job like ours, and where are keys generated and held?
For clean rooms: what controls stop row-level extraction (minimum aggregation thresholds, query review, noise, budgets), and who can approve a new query template?
Do you, your sub-processors or any model you use ever see our raw data, decrypted results or query text? Is any customer data used to train your models?
What logs do you produce for each query, release and key operation, and can they be streamed to our SIEM in a documented format?
How do service accounts, API keys and pipeline identities authenticate to your platform, and can they use short-lived workload identity instead of static keys?
What support do you provide for our DPIA: threat model, residual risk statement, and evidence for GDPR Article 25 and Article 32?

Red flags

"Anonymous" or "GDPR-exempt" as a product claim: anonymisation is a context-specific legal conclusion, and pseudonymised or encrypted data remains personal data. See the Anonymisation and Re-identification Risk Guide.
Undisclosed or very large epsilon: NIST SP 800-226 notes that values below 1 are generally considered reasonable, that many deployments use values between 1 and 20, and that at 10 or more outliers may be exposed. A vendor that will not state the value is not offering a measurable guarantee.
Event-level privacy presented as user privacy: event-level protection can reveal habits over time; NIST recommends user-level as the default.
Proprietary, unreviewed cryptography or custom DP mechanisms: custom implementations are a named privacy hazard in NIST SP 800-226.
Attestation you cannot verify: a TEE service where only the vendor checks attestation reduces the trust model to "trust the vendor".
No budget enforcement in clean rooms: unlimited query templates allow differencing attacks that reconstruct individuals.
Static, shared API keys for data pipelines: one long-lived key moving data into a PET platform undoes much of the protection.

Where identity fits

PET platforms are run by machines: ETL jobs push data in, notebooks and service accounts run queries, partner systems call clean room APIs, and TEEs request keys from a KMS. Each is a non-human identity with access to the most sensitive data you hold. Require workload identity federation or short-lived tokens for pipelines, attestation-bound key release for enclaves, separate roles for policy authors and query runners, and an owner and rotation schedule for every credential. See the Securing the tokenisation and data masking platform itself guide for the equivalent controls on a neighbouring platform.

Proof of concept

Write the protection goal and success thresholds first: the guarantee you need, the maximum acceptable error for 20 benchmark queries or model metrics, and the latency budget. Get the DPO and data owner to sign them.
Use a realistic but approved dataset: a copy covered by your DPIA, including rare records and outliers, because those are where PETs fail.
Integrate with your identity and key services: SSO for people, workload identity for pipelines, customer-managed keys. Record every credential the product needed.
Measure utility: run the benchmark set and compare against the raw baseline; record error, bias across subgroups and run time.
Run basic leakage tests: a differencing pair of queries in the clean room or DP gateway, a nearest-neighbour and membership check on synthetic output, a tampered workload image against TEE key release. Confirm the product blocks or degrades as documented.
Check budget and policy behaviour: repeat queries until the budget is exhausted and confirm releases stop; change a policy and confirm the change is logged.
Export evidence: stream logs to your SIEM, export policies and parameters, and confirm you could reproduce the DPIA evidence if the vendor disappeared.
Roll back cleanly: delete POC data and keys, confirm deletion in writing, and record gaps as contract conditions before scoring.

Detection and measurement

Privacy budget consumed per dataset: track against the cap; a sudden jump is a misuse signal.
Blocked or rejected queries: rising counts in a clean room point to probing for small cells.
Attestation failures and key release denials: should be rare and investigated each time.
Utility error against benchmarks: tracked per release so drift is visible to analysts.
Static credentials in use: number of long-lived keys accessing the platform, trending to zero.

Framework mapping

Framework	Reference	Relevance to the purchase
GDPR	Article 25, Article 32(1)(a), Recital 26	Data protection by design; pseudonymisation and encryption as security measures; pseudonymised data remains personal data
NIST CSF 2.0	PR.DS-01, PR.DS-10	Protection of data at rest and data in use
NIST CSF 2.0	GV.OC-03, GV.SC-07	Privacy obligations; assessing the PET vendor as a supplier
NIST SP 800-53 Rev. 5	PT-2, PT-3, AC-21	Authority and purpose for processing PII; controlled information sharing
NIST SP 800-53 Rev. 5	SC-12, SC-28, SC-39	Key management, protection at rest, process isolation for TEEs
NIST SP 800-226	Differential privacy pyramid and privacy hazards	How to evaluate a vendor's differential privacy claims
ISO/IEC 20889:2018	De-identification terminology and techniques	Common vocabulary for de-identification claims in contracts

Standards and references

How NHI Mgmt Group can help

We provide independent advice on data protection architecture and the machine identities that run it. Browse vendors in our products directory or contact us.

Privacy-Enhancing Technologies Buyer’s Guide: Choosing Differential Privacy, Confidential Computing, Clean Room and Encrypted Computation Tools