Selecting Privacy-Enhancing Technologies

Overview

Privacy-Enhancing Technologies (PETs) are technical measures that protect personal data during collection, processing, storage, and sharing. The GDPR does not prescribe specific technologies but requires "appropriate technical measures" (Article 25(1), Article 32(1)) to implement data protection principles. The European Commission's February 2025 communication on PETs and the ENISA 2023 report on engineering privacy by design with PETs provide regulatory context for PET adoption.

Selecting the right PET depends on the processing scenario, data sensitivity, computational requirements, and the specific privacy property needed (confidentiality, anonymity, unlinkability, or transparency).

PET Taxonomy

1. Differential Privacy (DP)

Privacy property: Statistical indistinguishability — the output of an analysis is approximately the same whether or not any individual's data is included.

Characteristic	Detail
Approach	Add calibrated noise to query results or model gradients
Privacy guarantee	Mathematically provable (epsilon, delta) bounds
Data utility	Configurable via epsilon; lower epsilon = more privacy, less utility
Performance overhead	Minimal for query-time noise; moderate for DP-SGD training
Maturity	Production-ready (Apple, Google, US Census Bureau)
GDPR relevance	Supports Recital 26 anonymization when epsilon is sufficiently small; Art. 25(1) by design measure

Best for: Statistical analytics, aggregate reporting, ML model training on sensitive data.

Libraries: Google DP Library, OpenDP, IBM diffprivlib, PyDP.

2. Homomorphic Encryption (HE)

Privacy property: Computation on encrypted data — results are decrypted only by the data owner.

Characteristic	Detail
Approach	Encrypt data such that mathematical operations on ciphertext produce valid results when decrypted
Privacy guarantee	Cryptographic (lattice-based hardness assumptions)
Data utility	Exact results (no noise added)
Performance overhead	High: 1,000x-1,000,000x slower than plaintext, depending on scheme and operation
Maturity	Emerging for production; active research on performance optimization
GDPR relevance	Art. 32(1)(a) encryption as security measure; enables processing without exposing plaintext to processor

Schemes:

• BFV (Brakerski/Fan-Vercauteren): Integer arithmetic, exact. Suitable for counting, matching.
• BGV (Brakerski-Gentry-Vaikuntanathan): Integer arithmetic with modulus switching. Efficient for deep circuits.
• CKKS (Cheon-Kim-Kim-Song): Approximate arithmetic on real/complex numbers. Suitable for ML inference.
• TFHE (Torus FHE): Fast bootstrapping, gate-by-gate evaluation. Suitable for boolean circuits.

Libraries: Microsoft SEAL, IBM HELib, Google FHE (Fully Homomorphic Encryption transpiler), TFHE-rs, OpenFHE.

3. Secure Multi-Party Computation (SMPC)

Privacy property: Joint computation without revealing individual inputs — each party learns only the final result.

Characteristic	Detail
Approach	Secret sharing, garbled circuits, or oblivious transfer protocols
Privacy guarantee	Information-theoretic (for secret sharing) or computational (for garbled circuits)
Data utility	Exact results
Performance overhead	Moderate to high; depends on circuit complexity and number of parties
Maturity	Production deployments in financial services, healthcare consortia
GDPR relevance	Enables joint controllership (Art. 26) analytics without data sharing; supports data minimization (Art. 5(1)(c))

Frameworks: MP-SPDZ, CrypTen (Meta), MOTION, ABY/ABY3, Sharemind.

4. Federated Learning (FL)

Privacy property: Model training without centralizing data — raw data never leaves the data owner's environment.

Characteristic	Detail
Approach	Distribute model training to data owners; aggregate only model updates (gradients)
Privacy guarantee	Data locality (raw data stays on device); strengthened with secure aggregation and DP
Data utility	Depends on data distribution across participants (IID vs non-IID)
Performance overhead	Communication overhead for gradient exchange; multiple training rounds
Maturity	Production at Google (Gboard), Apple (Siri), hospitals (NVIDIA FLARE)
GDPR relevance	Supports Art. 5(1)(c) minimization; reduces cross-border transfer requirements (Chapter V)

Frameworks: TensorFlow Federated, PySyft (OpenMined), NVIDIA FLARE, Flower, FedML.

5. Zero-Knowledge Proofs (ZKP)

Privacy property: Prove a statement is true without revealing the underlying data.

Characteristic	Detail
Approach	Prover demonstrates knowledge of a secret (e.g., age ≥ 18) without revealing the secret (date of birth)
Privacy guarantee	Soundness (false statements cannot be proven) and zero-knowledge (verifier learns nothing beyond the statement's truth)
Data utility	Binary verification (proof valid/invalid); no data disclosed
Performance overhead	Proof generation: moderate to high; proof verification: fast
Maturity	Production in blockchain identity; emerging in enterprise identity verification
GDPR relevance	Ultimate data minimization — prove compliance without disclosing data; supports Art. 5(1)(c), Art. 25

Systems: zk-SNARKs (Groth16, PLONK), zk-STARKs, Bulletproofs.

6. Trusted Execution Environments (TEE)

Privacy property: Isolated computation — data is processed inside a hardware-protected enclave that even the system administrator cannot access.

Characteristic	Detail
Approach	Hardware-enforced isolation using secure enclaves (Intel SGX, AMD SEV, ARM TrustZone, AWS Nitro)
Privacy guarantee	Hardware-based attestation and memory encryption
Data utility	Full computation capability inside enclave
Performance overhead	Low to moderate; limited enclave memory may require data streaming
Maturity	Production: Azure Confidential Computing, AWS Nitro Enclaves, Google Confidential VMs
GDPR relevance	Art. 32(1)(a) encryption in processing; Art. 28 processor guarantees; protects against insider threats

Use-Case Matching Matrix

Use Case	DP	HE	SMPC	FL	ZKP	TEE	Recommended Primary
Aggregate analytics on customer data	5	2	3	2	1	3	Differential Privacy
ML model training on distributed hospital data	3	1	2	5	1	3	Federated Learning
Credit scoring without sharing financial records	2	3	5	2	2	3	Secure MPC
Age verification without revealing date of birth	1	1	1	1	5	2	Zero-Knowledge Proofs
Processing encrypted customer data in third-party cloud	2	5	2	1	1	4	Homomorphic Encryption
Anti-money laundering across banks	2	2	5	3	2	3	Secure MPC
Private genomic analysis	3	4	3	3	1	4	HE + TEE combination
Confidential inference on cloud-hosted ML models	2	4	2	1	1	5	Trusted Execution Environment
Privacy-preserving surveys and polls	5	1	3	1	2	1	Differential Privacy
Secure keyword search on encrypted database	1	4	1	1	1	4	Homomorphic Encryption

Scores: 1 = poor fit, 5 = excellent fit

PET Selection Decision Framework

Step 1: Define Privacy Requirements

• What data protection principle is primary? (minimization, confidentiality, anonymization, unlinkability)
• Is the goal to protect data in transit, at rest, or during processing?
• Is the adversary model honest-but-curious or malicious?
• Are there cross-organizational boundaries (multiple controllers/processors)?

Step 2: Assess Constraints

• What is the acceptable performance overhead? (real-time vs batch)
• What is the computational budget? (HE requires significantly more resources)
• How many parties are involved? (SMPC scales with party count)
• Is there a hardware trust anchor available? (TEE requires specific hardware)
• What is the team's cryptographic engineering expertise?

Step 3: Evaluate Combinations

Many production deployments combine PETs for defense in depth:

Combination	Benefit
FL + DP	Federated learning with differentially private gradient updates prevents gradient inversion attacks
FL + Secure Aggregation	Aggregation server never sees individual gradients
HE + TEE	Process encrypted data inside an enclave for double protection
SMPC + DP	Add noise to SMPC outputs for formal anonymization guarantee
ZKP + TEE	Prove computation was performed correctly inside an enclave without revealing inputs

Step 4: GDPR Alignment Verification

• Does the selected PET satisfy Article 25(1) data protection by design?
• Does it implement a specific Article 32(1) security measure?
• Does it support the data minimization principle under Article 5(1)(c)?
• If anonymization is claimed, does it meet Recital 26 standards against singling out, linkability, and inference?
• Is the PET's privacy guarantee documented sufficiently for DPIA (Article 35)?

Key Regulatory References

• GDPR Article 25(1) — Data protection by design
• GDPR Article 32(1)(a) — Encryption and pseudonymisation as security measures
• GDPR Article 5(1)(c) — Data minimization principle
• GDPR Recital 26 — Anonymous information
• GDPR Recital 78 — Technical measures for data protection
• ENISA Report: Data Protection Engineering (2022)
• European Commission Communication on PETs (February 2025)
• EDPB Guidelines 4/2019 on Article 25 Data Protection by Design and by Default