Privacy-enhancing technology selection often begins in the wrong place: a team hears that homomorphic encryption, a clean room or federated learning can unlock sensitive data, then searches for a project that fits. A defensible decision runs in the other direction. Start with the collaboration: who holds which inputs, which party may run the computation, what result is genuinely needed, and who must not learn anything else. Only then compare PETs. The same business request can require private set intersection, secure multiparty computation, differential privacy, or a composition of several controls.
PET is an umbrella, not a single security property. The ICO's PET guidance covers differential privacy, synthetic data, homomorphic encryption, zero-knowledge proofs, trusted execution environments, secure multiparty computation, private set intersection and federated learning. Each changes a different disclosure path. None removes the need for lawful purpose, data minimization, access control, retention, incident response or an assessment of the complete system.
Frame the collaboration before comparing products
Write the intended outcome as a function, not a platform requirement. For example: two retailers want to count shared loyalty members by region without revealing nonmatching customer records; hospitals want to train a risk model while keeping patient records inside each institution; an analyst wants to publish monthly counts with a bounded contribution from any person. These are different functions, outputs and adversaries. The first naturally suggests PSI, the second federated learning with additional protections, and the third differential privacy.
Create a data-flow record for each input, intermediate value, model update and output. Mark where plaintext exists, which identities can link records, whether values are stored or streamed, and how long artifacts survive. Include metadata such as set size, message timing, query frequency and model participation because a protocol can conceal values while still leaking useful context. Treat collusion explicitly: a design secure when one party is honest may fail if two operators share their views.
| Collaboration pattern | Likely starting PET | What it protects | Question that can disqualify it |
|---|---|---|---|
| Find common identifiers | Private set intersection | Nonmatching set members | Is even the intersection too revealing? |
| Compute a joint statistic | SMPC | Each party's private input | Can the protocol tolerate expected collusion and dropout? |
| Outsource a bounded computation | Homomorphic encryption | Plaintext from the compute operator | Are function, latency and ciphertext growth practical? |
| Train without centralizing records | Federated learning | Raw training examples at participants | Can updates leak examples or be poisoned? |
| Release aggregates repeatedly | Differential privacy | Contribution of an individual to outputs | Who owns and enforces the cumulative privacy budget? |
Separate input privacy from output privacy
Cryptographic PETs primarily restrict what participants or compute operators learn while a function is evaluated. NIST describes MPC as joint computation over distributed inputs, FHE as computation over encrypted data, and PSI as revealing an intersection without exposing nonintersecting elements in its Privacy-Enhancing Cryptography project. That protection does not automatically make the final result safe. A perfectly private protocol that returns a person's diagnosis has protected computation but failed the disclosure objective.
Differential privacy addresses a different boundary: how much the distribution of released results changes because one entity's data was included. NIST SP 800-226 emphasizes that a mathematical claim depends on the realized software, parameters, data contribution rules and privacy-loss accounting. It is therefore common to combine controls. SMPC can compute a noisy aggregate without exposing inputs to one aggregator; differential privacy can then limit inference from the published aggregate.
Compare PET families against the actual topology
Use PSI, SMPC or HE for bounded cryptographic functions
PSI is attractive when the business function is genuinely set membership or intersection. Do not stretch it into an analytics platform. Decide whether parties learn the matched identifiers, only a count, or an aggregate over matches. Rate-limit repeated runs, normalize identifiers consistently, and consider dictionary attacks when the input domain is guessable. SMPC is broader: parties jointly evaluate a function, often with communication and coordination costs. Record the security model, number of parties, corruption threshold, abort behavior and treatment of malicious inputs.
Homomorphic encryption fits a model in which a key holder encrypts data and an operator evaluates supported functions without plaintext. It can reduce trust in the compute operator, but the decryptor, key lifecycle and result release remain important. Benchmark the exact circuit, data volume, precision and parameter set; a toy arithmetic example says little about production latency or cost. Prefer a narrow, stable function over an open-ended query service when operational maturity is limited.
Treat federated learning and differential privacy as system designs
Federated learning moves model training to data holders and exchanges updates rather than raw examples. That minimizes central collection, but updates may leak information and participants may submit malicious or low-quality contributions. Define participant authentication, secure aggregation, clipping, poisoning detection, dropout handling and model-release review. Differential privacy can protect updates or outputs, but its noise and budget affect utility. Neither label is enough without measured attack resistance and model quality.
Score utility, maturity and governance together
A shortlist should pass four gates. Privacy asks whether the stated adversary can infer prohibited facts. Utility asks whether the output remains accurate enough for the decision. Engineering asks whether latency, throughput, failure recovery and integration fit production. Governance asks whether owners can control keys, budgets, participants, versions and deletion obligations. The UK government's PETs Adoption Guide uses contextual questions to explore suitable techniques and cautions that a PET needs sound overall privacy design and governance.
| Evaluation dimension | Evidence before pilot | Evidence before production | Stop condition |
|---|---|---|---|
| Threat model | Parties, assets, attackers and collusion assumptions | Adversarial test mapped to each assumption | Unowned or untestable critical trust |
| Utility | Baseline decision metric and acceptable error | Representative accuracy with privacy controls | Privacy setting makes outcome unusable |
| Performance | Benchmark of exact function and scale | Capacity, timeout and recovery test | Cost or latency misses the service objective |
| Operations | Named key, budget and participant owners | Runbooks, telemetry and controlled upgrade | No safe revocation or rollback path |
| Compliance | Purpose, minimization and output review | Assessment, contracts and retention evidence | Technology is used as a substitute for lawful basis |
Pilot with falsifiable privacy and utility tests
Use representative distributions, including rare categories and dominant contributors, rather than sanitized demonstration data. Build a baseline without the PET so reviewers can see the protection and utility delta. Attempt membership inference, reconstruction, input guessing, malicious participant behavior and metadata analysis that match the threat model. Verify negative behavior: an unauthorized party cannot join, an obsolete client cannot negotiate weak parameters, and a privacy-budget limit actually blocks another release.
A pilot report should state what was proven and what was not. Record protocol and library versions, cryptographic parameters, hardware assumptions, dataset characteristics, error bars, privacy parameters, key custody, output recipients and unresolved leakage. Make approval conditional on these values. This prevents a successful narrow experiment from becoming a blanket authorization for different data, functions or parties.
Govern the PET as a changing production system
Reapprove changes that alter the privacy claim
A PET approval should bind a concrete protocol, implementation, parameter set, dataset class, function and output audience. A library upgrade can change supported curves or serialization; a model update can change the information encoded in gradients; a new query dimension can turn safe aggregates into singling-out opportunities. Put these values in a machine-readable deployment manifest and compare them with the approved record at release time. Require privacy and data-owner review when the manifest changes a trust assumption, permitted disclosure or cumulative privacy loss, while ordinary reliability fixes can follow the normal engineering path.
Observe reliability without creating a second disclosure channel
Production telemetry must prove that the collaboration works without copying sensitive protocol material into logs. Measure session completion, participant dropout, computation latency, rejected requests, budget consumption and output-review decisions. Avoid recording raw identifiers, secret shares, ciphertexts that have no diagnostic purpose, model updates or small-group results. Use synthetic canaries to exercise the full path and keep an access-controlled evidence package for each release. Incident procedures should identify who can suspend queries, revoke participant credentials, rotate keys, invalidate an attestation policy and account for outputs already delivered.
Review residual risk on a calendar and event basis. Calendar reviews catch dependency drift, expiring cryptographic recommendations and growing query volume. Event reviews respond to a new party, dataset linkage, breach, attack technique or business use. The result may be a tighter output, lower query rate, fresh privacy budget, different protocol or a decision to stop the collaboration. That ability to withdraw safely is part of PET maturity; a technically impressive system with no revocation, deletion or evidence-retention plan is not production ready.
Use the six-stage Edilec PET selection path
The path begins with purpose because unnecessary output cannot be repaired by stronger cryptography. It then maps holders, trust and permitted disclosure before naming a technology. The final assurance stage tests privacy, utility, performance and governability as one system. Re-enter the path whenever a party, dataset, function, output audience or attacker assumption changes; those are architecture changes, not routine configuration.
Key takeaways for PET selection
- Choose from a precise collaboration function and prohibited disclosures, not a fashionable technique.
- Distinguish confidentiality during computation from privacy of the released output.
- Model plaintext, metadata, keys, participants, collusion and repeated queries end to end.
- Combine PETs only when each addresses a named risk and the composition is testable.
- Approve a bounded use case with parameters, evidence, owners and change triggers.
Frequently asked questions about privacy-enhancing technology selection
Is there one strongest PET?
No. Strength is relative to an adversary, function and disclosure goal. HE can hide plaintext from an operator but still reveal a sensitive decrypted result. Differential privacy can bound output inference but does not encrypt inputs in transit or use. SMPC can distribute trust but depends on its corruption model and implementation.
Is a data clean room itself a PET?
A clean room is an architecture and governance environment that may use access controls, TEEs, PSI, aggregation or differential privacy. Evaluate the concrete controls and outputs. The product category alone does not state who can see plaintext or how repeated queries are constrained.
When should teams combine PETs?
Combine them when the risks are distinct, such as SMPC for input confidentiality and differential privacy for released statistics. Document composition costs and avoid adding techniques merely to improve the appearance of assurance.
Conclusion
Good privacy-enhancing technology selection is disciplined architecture work. Define the collaboration, locate disclosure, state trust assumptions and limit the output. Then let measured privacy, utility and operating evidence choose the PET or composition. That method may produce a less exotic answer, but it produces one that data owners, engineers and reviewers can understand, test and govern.