PET Selection Assessment Template (Privacy-Enhancing Technologies)
Problem, data flows, requirements, eight candidate PETs, knock-out screening, cost, residual risk, weighted decision matrix, validation plan
Cách dùng: Use it when a use case needs data from several parties or sensitive outputs and a privacy-enhancing technology might replace raw data sharing. Fill the problem, data flows and must-have requirements first, include a non-PET baseline, then score with weights fixed in advance. The main pitfall is protecting the inputs and forgetting that the outputs can still leak.
Xem trước
PET Selection Assessment: [Use case name]
Options analysis for choosing privacy-enhancing technologies (PETs) for one specific use case. It records the problem, the data flows and parties, the privacy and security requirements, the candidate PETs (differential privacy, synthetic data, homomorphic encryption, zero-knowledge proofs, trusted execution environments, secure multiparty computation, private set intersection and federated learning), their maturity, cost and residual risk, a weighted decision matrix, the decision and the validation plan. It draws on the ICO guidance on privacy-enhancing technologies (created 19 June 2023, last updated 28 September 2026, marked under review after the Data (Use and Access) Act 2025), the ENISA reports "Data Protection Engineering" (January 2022) and "Engineering Personal Data Sharing" (January 2023), and NIST SP 800-226 (March 2025) for differential privacy. Replace every
[bracketed]value and every row marked Example. This is a documentation format, not legal advice.
Document control
| Field | Value |
|---|---|
| Document ID | [PET-001] |
| Use case | [Short name and one-line description] |
| Parties | [Organisations involved and their roles] |
| Linked DPIA | [DPIA-ID] |
| Linked privacy threat model | [Reference] |
| Jurisdictions | [EU GDPR / UK GDPR / other, by name] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@privacy-engineer] |
| Approvers/reviewers | [@product-owner], [@dpo], [@security-architect], [@finance], [@legal] |
| Last updated | YYYY-MM-DD |
| Next review | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
Approvals
| Role | Name | Decision | Date |
|---|---|---|---|
| Product or business owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Privacy lead or DPO | [@name] | [Decision] | YYYY-MM-DD |
| Security architect | [@name] | [Decision] | YYYY-MM-DD |
| Finance | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved option O1 (private set intersection with differentially private outputs) for a pilot |
| 1.1 | YYYY-MM-DD | [@name] | Example: Updated after proof of concept; cost and accuracy figures replaced with measured values |
| 1.2 | 2026-10-24 | [@name] | Example: DP budget recomputed for 13 weekly reports (epsilon 0.15 per report), contribution bound and per-person budget tracking added, small-cell rule moved to noisy counts |
Contents
- Purpose, scope and basis
- Problem statement and objectives
- Data flows and parties
- Privacy and security requirements
- Candidate PETs
- Options and knock-out screening
- Maturity, cost and operational assessment
- Residual risk per option
- Decision matrix and sensitivity
- Decision and conditions
- Validation plan
- Monitoring and re-assessment
- Traceability matrix
- Glossary and references
1. Purpose, scope and basis
This assessment selects the privacy-enhancing technology, or combination of technologies, that lets [Organisation] achieve [use case outcome] while sharing or exposing the least personal data. It feeds the DPIA and the architecture decision record, and it sets the validation that must pass before production.
| Item | Value |
|---|---|
| Decision supported | [Which PET option to build or buy, and under which conditions] |
| In scope | [Data flows, parties, outputs] |
| Out of scope | [Other use cases, general platform choice] |
| Decision deadline | YYYY-MM-DD |
| Inputs | [DPIA draft, privacy threat model, data inventory, partner requirements] |
Legal position in brief: using a PET does not by itself change who is controller or processor, nor does it make data anonymous. Under GDPR Article 25 (data protection by design) and Article 32 (security of processing), the state of the art and the cost of implementation are factors in choosing measures; this document is the record of that weighing. Where data protection law applies, the DPIA (compliance/dpia) records the lawful basis and the necessity test. The ICO PETs guidance is marked "under review" after the Data (Use and Access) Act 2025: check the current status at ico.org.uk before relying on it.
2. Problem statement and objectives
2.1 Problem
[Describe the outcome the parties need and why the obvious approach (sharing raw or pseudonymised data) is not acceptable.]
Example: Corvid Commerce runs advertising campaigns with Heron Media, a retail-media partner. Heron Media wants to know how many people who saw a campaign later bought from Corvid, and their total spend, per campaign and audience segment. Today this would require one party to send its customer list to the other. Corvid's privacy lead does not accept transferring customer identifiers, and Heron Media does not want to disclose its audience lists either.
2.2 Objectives
| ID | Objective | Measure |
|---|---|---|
| OBJ-001 (Example) | Measure conversions per campaign without either party seeing the other's customer list | No identifier leaves its owner in readable form |
| OBJ-002 (Example) | Report conversions and revenue per campaign with useful accuracy | Relative error below 5% for campaigns with at least 1,000 conversions |
| OBJ-003 (Example) | Prevent singling out of individuals from the reports | Small-cell rule and formal output protection |
| OBJ-004 (Example) | Run weekly at acceptable cost | Year-one cost below USD 120,000 |
| OBJ-005 (Example) | Be operable by the existing data team | No more than 0.5 FTE ongoing |
3. Data flows and parties
3.1 Parties
| Party | Role | Data contributed | Should learn | Must not learn |
|---|---|---|---|---|
| Corvid Commerce (Example) | Controller of customer and order data | Hashed email of buyers, order date, order value | Aggregate conversions per campaign | Heron audience membership of any person |
| Heron Media (Example) | Controller of ad exposure data | Hashed email of exposed users, campaign, segment | Aggregate conversions per campaign | Which person bought, or what they bought |
| PET provider (Example) | Processor for both, if a service is used | None | Nothing in clear | Either party's identifiers or values |
3.2 Current and target flow
Show the target flow with the boundary where data stays protected. Mark which party runs each step.
3.3 Data inventory
| ID | Data element | Owner | Classification | Personal data? | Needed for objective |
|---|---|---|---|---|---|
| DAT-001 (Example) | Buyer email (normalised, hashed) | Corvid | Confidential | Yes | OBJ-001 |
| DAT-002 (Example) | Order value and date | Corvid | Confidential | Yes, when linked | OBJ-002 |
| DAT-003 (Example) | Exposed user email (normalised, hashed) | Heron | Confidential | Yes | OBJ-001 |
| DAT-004 (Example) | Campaign and segment | Heron | Internal | Yes, when linked | OBJ-002 |
4. Privacy and security requirements
| ID | Requirement | Type | Rationale |
|---|---|---|---|
| REQ-001 (Example) | Neither party receives the other's identifiers in a form it can read or reverse | Must | OBJ-001, data minimisation |
| REQ-002 (Example) | Outputs are aggregates only, and no cell is published whose noisy count is below 50 matched users | Must | OBJ-003 |
| REQ-003 (Example) | Outputs carry a formal protection against differencing across weekly reports | Should | OBJ-003, repeated releases |
| REQ-004 (Example) | Computation runs in the EU or the UK | Must | Transfer policy |
| REQ-005 (Example) | The design survives one party behaving dishonestly (trying to learn more than the output) | Should | Partner trust model |
| REQ-006 (Example) | Results available within 24 hours of the weekly cut-off | Must | OBJ-004 |
| REQ-007 (Example) | Implementation uses maintained, independently reviewed libraries or services | Must | Security assurance |
Name the adversary model for each requirement: honest-but-curious (follows the protocol but tries to learn from what it sees) or malicious (deviates from the protocol). Many PET implementations assume honest-but-curious parties, so a must-have against malicious parties narrows the field considerably.
5. Candidate PETs
The eight families below are those covered by the ICO PETs guidance. Each summary is original and focuses on what matters for selection.
| ID | PET | What it protects | What it does not protect | Typical fit |
|---|---|---|---|---|
| PET-001 | Differential privacy (DP) | Limits what outputs reveal about any one unit of privacy, with a measurable epsilon | Inputs during computation; accuracy for small groups | Published statistics, repeated reports, model training |
| PET-002 | Synthetic data | Replaces real records with generated ones that mimic statistical properties | Outliers memorised by the generator, unless combined with DP; joins with real data | Testing, exploration, sharing for early analysis |
| PET-003 | Homomorphic encryption (HE) | Lets a party compute on encrypted data without decrypting it | The decrypted result; heavy compute and limited operations | Outsourced computation on a small number of values |
| PET-004 | Zero-knowledge proofs (ZKP) | Proves a statement (age over 18, balance above a limit) without revealing the underlying value | Anything outside the proven statement; aggregate analytics | Selective disclosure, credentials, verification |
| PET-005 | Trusted execution environments (TEE) | Isolates code and data in hardware-protected memory, with attestation of the code that runs | Side-channel attacks, flaws in the enclave code, trust in the hardware vendor | Data clean rooms, confidential computing of joins |
| PET-006 | Secure multiparty computation (SMPC) | Lets several parties compute a joint function while each sees only its own input and the output | The output itself; performance and network cost at scale | Joint statistics among a few parties |
| PET-007 | Private set intersection (PSI) | Lets two parties find common items (and optionally aggregate over them) without revealing the rest of their sets | The size of the intersection and the outputs; dictionary attacks if inputs are guessable and the protocol allows it | Audience matching, contact discovery, fraud list matching |
| PET-008 | Federated learning (FL) | Trains a model where the data sits, sharing only model updates | Updates can leak training data unless combined with DP or secure aggregation | Model training across devices or organisations |
Combine PETs where one covers the other's gap. A frequent pattern is an input-protecting technique (PSI, SMPC, TEE, HE) plus an output-protecting technique (DP, small-cell rules).
6. Options and knock-out screening
6.1 Options
| ID | Option | PETs used |
|---|---|---|
| O1 (Example) | PSI with aggregate computation over the intersection, then DP noise on published totals, run as a managed service in the EU | PET-007, PET-001 |
| O2 (Example) | TEE-based data clean room operated by a cloud provider, with attestation and DP on outputs | PET-005, PET-001 |
| O3 (Example) | Two-party SMPC protocol run by both parties' engineering teams | PET-006 |
| O4 (Example) | Heron shares a synthetic exposure dataset; Corvid joins it to its own data | PET-002 |
| O5 (Example) | Baseline: Heron sends pseudonymised exposure data to Corvid under a contract | None |
| O6 (Example) | Homomorphic encryption of Corvid spend values, with Heron computing encrypted sums | PET-003 |
6.2 Knock-out screening
| Option | REQ-001 | REQ-002 | REQ-004 | REQ-006 | REQ-007 | Result |
|---|---|---|---|---|---|---|
| O1 (Example) | Pass | Pass | Pass | Pass | Pass | Continue |
| O2 (Example) | Pass | Pass | Pass | Pass | Pass | Continue |
| O3 (Example) | Pass | Pass | Pass | Pass | Pass, if a reviewed library is used | Continue |
| O4 (Example) | Pass | Fail: record-level synthetic data, joins to real buyers not meaningful | Pass | Pass | Pass | Excluded |
| O5 (Example) | Fail: Corvid receives Heron identifiers | Pass | Pass | Pass | Pass | Excluded, kept as reference |
| O6 (Example) | Fail: matching still requires identifier exchange | Pass | Pass | Fail: compute time at 2 million records | Pass | Excluded |
Options O4 and O5 are scored in section 9 for reference only, to show what the PET options gain over them; O6 is excluded without scoring because it fails two must-haves. None of them can be selected.
7. Maturity, cost and operational assessment
7.1 Maturity
| Option | Technology maturity | Implementation maturity | Evidence |
|---|---|---|---|
| O1 (Example) | Established protocols, used in production for audience matching | Managed services available | [Independent review, references] |
| O2 (Example) | Hardware and attestation services widely available | Clean-room products in production | [Provider attestation documentation, audit reports] |
| O3 (Example) | Mature protocols in research, fewer production deployments at this scale | Requires specialist skills | [Library audit, benchmark] |
| O4 (Example) | Generators widely available | Quality varies by method | [Utility and privacy test results] |
| O5 (Example) | Not applicable | Standard practice | [Contract templates] |
| O6 (Example) | Standardised schemes exist; performance limits for this workload | Few products for this pattern | [Benchmark] |
7.2 Cost (year one)
All figures are fictional and rounded for illustration.
| Option | Licence or service | Engineering | Assurance and legal | Total year one |
|---|---|---|---|---|
| O1 (Example) | USD 40,000 | USD 30,000 | USD 15,000 | USD 85,000 |
| O2 (Example) | USD 60,000 | USD 25,000 | USD 20,000 | USD 105,000 |
| O3 (Example) | USD 0 | USD 125,000 | USD 25,000 | USD 150,000 |
| O4 (Example, estimate for reference) | USD 15,000 | USD 20,000 | USD 10,000 | USD 45,000 |
| O5 (Example) | USD 0 | USD 10,000 | USD 10,000 | USD 20,000 |
O3 exceeds the OBJ-004 limit of USD 120,000; this is reflected in its cost score rather than as a knock-out, because OBJ-004 is a preference.
7.3 Operational considerations
- Skills: who can operate and troubleshoot the option, and what happens when that person leaves.
- Key and parameter management: who holds keys, salts and the DP budget, and who approves changes.
- Performance: measured run time on realistic volumes, not vendor benchmarks.
- Exit: whether results and configurations can move to another provider.
- Partner effort: what the other party must build or run.
8. Residual risk per option
| ID | Option | Residual risk | Likelihood | Impact | Mitigation |
|---|---|---|---|---|---|
| RSK-001 (Example) | O1 | Intersection size per campaign reveals approximate audience overlap | High | Low | Accept; overlap at campaign level is the agreed output |
| RSK-002 (Example) | O1 | Repeated weekly reports allow differencing to isolate a person | Medium | Medium | DP noise with a quarterly budget, small-cell rule |
| RSK-003 (Example) | O1 | Guessable inputs (emails) attacked by dictionary if the protocol leaks hashed values | Low | High | Use a PSI protocol that does not expose hashes; vendor review |
| RSK-004 (Example) | O2 | Side-channel or firmware flaw in the TEE | Low | High | Patch policy, attestation checks, provider assurance |
| RSK-005 (Example) | O2 | Clean-room operator misconfigures query controls | Medium | Medium | Query allow-list, independent configuration review |
| RSK-006 (Example) | O3 | Implementation flaw in in-house protocol code | Medium | High | Use only an independently reviewed library; external audit |
| RSK-007 (Example) | All | Purpose creep: partners request finer outputs over time | Medium | Medium | Change control through this assessment and the DSA |
8.1 Output protection parameters for O1
The output protection uses differential privacy as evaluated under NIST SP 800-226: define the unit of privacy, the privacy parameter, composition and trust model.
| Item | Value |
|---|---|
| Unit of privacy | Example: one person (matched email), across all reports in a quarter |
| Contribution bound | Example: each person contributes to at most one campaign per report (attribution to the last exposure, k = 1), with at most one conversion and clipped revenue. With k campaigns per person, multiply the per-report epsilon by k |
| Outputs per weekly report | Example: conversion count and clipped revenue sum per campaign |
| Reports per quarter | Example: 13 weekly reports |
| Epsilon per report | Example: 0.15 (0.075 for the count, 0.075 for the sum), covering all campaigns in the report, because each person sits in one campaign cell only |
| Quarterly budget | Example: epsilon 2.0 per person per quarter; 13 × 0.15 = 1.95 is used |
| Revenue clipping | Example: USD 300 per person per report |
| Small-cell rule | Example: suppress any cell whose noisy count is below 50. The decision uses only the noisy output, so it is post-processing and consumes no budget; deciding on the true count would leak information outside the epsilon accounting |
Noise for the count (Example): sensitivity 1, epsilon 0.075, Laplace scale b = 1 / 0.075 ≈ 13.3, standard deviation √2 × 13.3 ≈ 18.9. For a campaign with 3,000 conversions, the standard deviation is about 18.9 / 3,000 ≈ 0.63% of the count, within the 5% objective.
Noise for the revenue sum (Example): sensitivity USD 300, epsilon 0.075, Laplace scale b = 300 / 0.075 = 4,000, standard deviation √2 × 4,000 ≈ 5,657. For a campaign revenue of USD 180,000 the standard deviation is about 3.1% of the sum, still within 5%. Campaigns with much lower revenue get proportionally larger relative error; report the noise scale with every figure.
Budget check (Example): 13 weekly reports × 0.15 = 1.95, within the quarterly budget of 2.0. The remaining 0.05 is not enough for another report; a correction or extra report needs a new approved budget. The budget is tracked per person and quarter across all campaigns, not per campaign, because the same person can be exposed to several campaigns over the quarter.
Effect of the small-cell rule (Example): for a cell with 30 true matched users, the noisy count reaches 50 only when the noise exceeds +20, which happens with probability 0.5 × e^(−20 / 13.3) ≈ 0.11. About 89% of such cells are suppressed; the rest are published with the DP guarantee intact.
9. Decision matrix and sensitivity
9.1 Criteria and weights
| ID | Criterion | Weight | Scoring guide |
|---|---|---|---|
| CRT-001 | Privacy protection | 30 | 5 = inputs and outputs protected against the agreed adversary model; 1 = identifiers exchanged |
| CRT-002 | Utility and accuracy | 20 | 5 = meets OBJ-002 for all campaigns; 1 = unusable |
| CRT-003 | Maturity | 15 | 5 = production use at similar scale with independent review; 1 = research only |
| CRT-004 | Cost | 15 | 5 = well below budget; 1 = far above |
| CRT-005 | Integration effort | 10 | 5 = minimal change for both parties; 1 = major build |
| CRT-006 | Regulatory clarity | 10 | 5 = clear position in regulator guidance; 1 = untested |
| Total | 100 |
9.2 Scores
Weighted score = sum of (weight × score) / 100, on a 1 to 5 scale.
| Option | CRT-001 (30) | CRT-002 (20) | CRT-003 (15) | CRT-004 (15) | CRT-005 (10) | CRT-006 (10) | Weighted sum | Score |
|---|---|---|---|---|---|---|---|---|
| O1 (Example) | 4 | 4 | 4 | 4 | 3 | 4 | 390 | 3.90 |
| O2 (Example) | 4 | 5 | 4 | 3 | 3 | 3 | 385 | 3.85 |
| O3 (Example) | 5 | 4 | 3 | 2 | 2 | 3 | 355 | 3.55 |
| O4 (Example, reference only) | 3 | 2 | 4 | 4 | 4 | 2 | 310 | 3.10 |
| O5 (Example, reference only) | 1 | 5 | 5 | 5 | 5 | 1 | 340 | 3.40 |
Arithmetic for the Example rows:
- O1: 30×4 + 20×4 + 15×4 + 15×4 + 10×3 + 10×4 = 120 + 80 + 60 + 60 + 30 + 40 = 390.
- O2: 30×4 + 20×5 + 15×4 + 15×3 + 10×3 + 10×3 = 120 + 100 + 60 + 45 + 30 + 30 = 385.
- O3: 30×5 + 20×4 + 15×3 + 15×2 + 10×2 + 10×3 = 150 + 80 + 45 + 30 + 20 + 30 = 355.
- O4: 30×3 + 20×2 + 15×4 + 15×4 + 10×4 + 10×2 = 90 + 40 + 60 + 60 + 40 + 20 = 310.
- O5: 30×1 + 20×5 + 15×5 + 15×5 + 10×5 + 10×1 = 30 + 100 + 75 + 75 + 50 + 10 = 340.
The baseline O5 scores higher than O4 because it is cheap and accurate, but it fails REQ-001; the matrix alone would hide this, which is why knock-out screening comes first.
9.3 Sensitivity
Test whether the ranking holds when the weights change within a plausible range.
| Scenario | Weights (CRT-001 to CRT-006) | O1 | O2 | O3 | Leader |
|---|---|---|---|---|---|
| Base (Example) | 30, 20, 15, 15, 10, 10 | 3.90 | 3.85 | 3.55 | O1 |
| Privacy heavy (Example) | 40, 10, 15, 15, 10, 10 | 3.90 | 3.75 | 3.65 | O1 |
| Utility heavy (Example) | 25, 30, 15, 10, 10, 10 | 3.90 | 4.00 | 3.60 | O2 |
Arithmetic for the scenarios (Example):
- Privacy heavy, O1: 160 + 40 + 60 + 60 + 30 + 40 = 390; O2: 160 + 50 + 60 + 45 + 30 + 30 = 375; O3: 200 + 40 + 45 + 30 + 20 + 30 = 365.
- Utility heavy, O1: 100 + 120 + 60 + 40 + 30 + 40 = 390; O2: 100 + 150 + 60 + 30 + 30 + 30 = 400; O3: 125 + 120 + 45 + 20 + 20 + 30 = 360.
Note that the utility-heavy scenario changes the leader. Record why the base weights are the right ones for this use case (here, OBJ-001 and OBJ-003 drive the project), or treat O1 and O2 as tied and let the proof of concept decide.
10. Decision and conditions
| Item | Value |
|---|---|
| Decision | [Selected option, or "proof of concept between O1 and O2"] |
| Rationale | [Short summary of sections 6 to 9] |
| Conditions | [Validation results required, contract terms, budget limits] |
| Reversal triggers | [Validation failure, cost overrun, regulatory change] |
| Linked decision record | [ADR reference, e.g. architecture/adr-full] |
| Linked agreements | [DSA or DPA references, compliance/data-sharing-agreement, legal-lite/dpa] |
Example decision: Proceed with O1 as the preferred option and run a four-week proof of concept that also benchmarks O2 on the same data. Select the option that meets all validation criteria in section 11 at the lower year-one cost. Conditions: DP parameters as in section 8.1, small-cell threshold of 50, EU processing, independent review of the PSI protocol configuration, and a data sharing agreement that forbids re-identification and onward use.
11. Validation plan
| ID | Test | Requirement | Method | Pass criterion |
|---|---|---|---|---|
| VAL-001 (Example) | Identifier exposure | REQ-001 | Inspect all messages and logs at both parties and the provider | No readable or reversible identifiers of the other party |
| VAL-002 (Example) | Small-cell enforcement | REQ-002 | Run 1,000 times with a seeded campaign of 30 matched users; check that suppression reads only the noisy count | No cell published with a noisy count below 50; suppression rate close to the predicted 89% |
| VAL-003 (Example) | Differencing attack | REQ-003 | Two reports differing by one known person; attempt to infer membership | Inference no better than the DP bound predicts |
| VAL-004 (Example) | Accuracy | OBJ-002 | Compare with ground truth on synthetic test data | Relative error below 5% for campaigns with 1,000 or more conversions |
| VAL-005 (Example) | Run time | REQ-006 | Full weekly volume, 2 million records per side | Completes within 6 hours |
| VAL-006 (Example) | Data location | REQ-004 | Provider attestation and configuration review | All processing in EU regions |
| VAL-007 (Example) | Malicious input | REQ-005 | One party submits a crafted list to probe membership | Detected or bounded by output protection |
Use fictional or synthetic test data for validation wherever possible. When real data is needed, run validation under the DPIA and with the same controls as production. A Proof of Concept (architecture/proof-of-concept) record can hold the detailed results.
12. Monitoring and re-assessment
| ID | Monitor | Owner | Frequency | Threshold or trigger |
|---|---|---|---|---|
| MON-001 (Example) | DP budget consumed per person and quarter, across all campaigns | [@privacy-engineer] | Each report | Stop at 2.0; 13 weekly reports use 1.95 |
| MON-002 (Example) | Small-cell suppressions | [@data-analyst] | Each report | More than 20% of cells suppressed triggers review of segment design |
| MON-003 (Example) | Provider security advisories and attestation status | [@security-architect] | Monthly | Any advisory affecting the PET |
| MON-004 (Example) | Partner change requests for finer outputs | [@product-owner] | On request | Any request triggers re-assessment |
Re-assess this document when the parties, data scope or outputs change, when the provider or library changes major version, when a relevant attack is published, when the ICO PETs guidance or other regulator guidance is updated, and at least every [12] months.
13. Traceability matrix
| Objective | Requirement | Selected option element | Residual risk | Validation | Monitor |
|---|---|---|---|---|---|
| OBJ-001 (Example) | REQ-001, REQ-005 | O1 PSI protocol | RSK-003 | VAL-001, VAL-007 | MON-003 |
| OBJ-002 (Example) | None (accuracy objective; noise parameters in section 8.1) | O1 aggregate computation and noise calibration | RSK-001 | VAL-004 | MON-002 |
| OBJ-003 (Example) | REQ-002, REQ-003 | O1 DP and small-cell rule on noisy counts | RSK-002 | VAL-002, VAL-003 | MON-001 |
| OBJ-004 (Example) | REQ-006 | O1 weekly run within budget (13 reports per quarter), year-one cost USD 85,000 | RSK-002 | VAL-005 | MON-001 |
| OBJ-005 (Example) | REQ-007 | O1 managed service | RSK-007 | Section 7.3 review | MON-004 |
| Transfer policy and assurance (Example) | REQ-004, REQ-007 | O1 managed EU service | RSK-007 | VAL-006 | MON-003 |
14. Glossary and references
14.1 Glossary
| Term | Meaning in this document |
|---|---|
| PET | Privacy-enhancing technology: a technique or system that reduces the personal data exposed while still achieving a purpose |
| Input privacy | Protection of data while it is being computed on |
| Output privacy | Protection against what the results reveal about individuals |
| Honest-but-curious | Adversary model where a party follows the protocol but tries to learn from what it sees |
| Malicious adversary | Adversary model where a party may deviate from the protocol |
| Epsilon | Privacy loss parameter in differential privacy; lower means stronger protection |
| Privacy budget | Total epsilon allowed across releases for the same unit of privacy in a period |
| Attestation | Evidence that a trusted execution environment runs specific, unmodified code |
| Small-cell rule | Suppression of results based on fewer than a set number of people |
| Data clean room | Environment where several parties combine data under controls that restrict outputs |
14.2 References
- ICO, Privacy-enhancing technologies (PETs) guidance (created 19 June 2023; updated 28 September 2026; marked under review after the Data (Use and Access) Act 2025), ico.org.uk.
- ENISA, Data Protection Engineering: From Theory to Practice (January 2022, CC BY 4.0, DOI 10.2824/09079), enisa.europa.eu.
- ENISA, Engineering Personal Data Sharing: Emerging Use Cases and Technologies (January 2023, CC BY 4.0, DOI 10.2824/36813), enisa.europa.eu.
- NIST SP 800-226, Guidelines for Evaluating Differential Privacy Guarantees (final, March 2025), csrc.nist.gov/pubs/sp/800/226/final.
- Regulation (EU) 2016/679 (GDPR), Articles 5, 25, 32 and 35, on EUR-Lex.
- Related templates: DPIA (
compliance/dpia), De-identification Assessment (compliance/de-identification-assessment), Privacy Threat Model (security/privacy-threat-model), Privacy by Design Review (compliance/privacy-by-design-review), Build vs Buy Analysis (architecture/build-vs-buy-analysis), Technology Selection (architecture/technology-selection).
Standard and licence note
Based on the ICO guidance on privacy-enhancing technologies (contains public sector information licensed under the Open Government Licence v3.0, where ICO material informed the wording), the ENISA reports "Data Protection Engineering" (January 2022, CC BY 4.0, DOI 10.2824/09079) and "Engineering Personal Data Sharing" (January 2023, CC BY 4.0, DOI 10.2824/36813), both attributed to ENISA, NIST SP 800-226 (March 2025, a US Government work in the public domain) and GDPR Articles 25 and 32. All text in this template is original; no passages are reproduced. The ICO PETs guidance is under review after the Data (Use and Access) Act 2025: check the current official versions of all sources before use. This is a documentation format, not legal advice. Template licence: MIT.
Template liên quan
Data Residency and Sovereignty Assessment Template (GDPR Chapter V)
Data tiers, flow map, jurisdiction matrix, Chapter V mechanisms, TIAs, PIPL and DPDP examples, Data Act Art. 32, key custody, sovereign cloud scoring, decision
ISO & Tuân thủDe-identification Assessment Template (Re-identification Risk)
Release model, identifiers and quasi-identifiers, motivated intruder test, techniques, k-anonymity and DP budget results, utility, release decision
ISO & Tuân thủSupplier Security Assessment Template
Vendor vetting + ongoing monitoring