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
Anleitung: Use it when a dataset leaves its original context as anonymous or pseudonymised data. Fill the release model and the attribute register first, then measure residual risk on the transformed output against thresholds set in advance. The main pitfall is calling hashed or generalised data anonymous without testing it against the recipient's environment and earlier releases.
Vorschau
De-identification Assessment: [Dataset or release name]
Re-identification risk assessment and release decision for one dataset or one recurring data release. It records the release model (public, controlled or enclave), the direct identifiers and quasi-identifiers, the threat model and motivated intruder test, the techniques chosen, the residual risk measured after transformation, the utility that remains and the governance that keeps the decision valid over time. The structure follows the assessment stages of ISO/IEC 27559:2022 (context, data, identifiability, governance) and the technique families of ISO/IEC 20889:2018 (structure only), with method guidance from NIST SP 800-188 (September 2023) and NIST SP 800-226 (March 2025) for differential privacy. For the legal test it uses GDPR Recital 26 and Article 4(5), the ICO guidance on anonymisation and pseudonymisation (published 28 March 2025) and, as a consultation version only, EDPB Guidelines 01/2025 on pseudonymisation. Replace every
[bracketed]value and every row marked Example. This is a documentation format, not legal advice.
Document control
| Field | Value |
|---|---|
| Document ID | [DEID-001] |
| Dataset or release | [Name, source system, schema version] |
| Release model | [Public / Controlled / Enclave] |
| Recipient(s) | [Organisation or audience, or "general public"] |
| Data owner | [@data-owner] |
| Privacy lead or DPO | [@dpo] |
| Linked DPIA | [DPIA-ID or "not required, reason"] |
| Jurisdictions | [EU GDPR / UK GDPR / other, by name] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Approved with conditions / Rejected / Superseded] |
| Owner | [@privacy-engineer] |
| Approvers/reviewers | [@data-owner], [@dpo], [@security-lead], [@legal] |
| Last updated | YYYY-MM-DD |
| Next re-assessment due | YYYY-MM-DD |
| Classification | [Confidential] |
Approvals
| Role | Name | Decision | Date |
|---|---|---|---|
| Data owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Privacy lead or DPO | [@name] | [Decision] | YYYY-MM-DD |
| Security lead | [@name] | [Decision] | YYYY-MM-DD |
| Legal counsel | [@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 for controlled release to the research partner with k of at least 10 |
| 1.1 | YYYY-MM-DD | [@name] | Example: Re-assessed after adding the delivery-method column; generalised to two values |
| 1.2 | 2026-10-24 | [@name] | Example: Customer-level extract figures reconciled, l-diversity checked on a real sensitive attribute, DP contribution bound fixed, CJEU C-413/23 P added |
Contents
- Purpose, scope and legal test
- Release context and release model
- Data assessment and attribute classification
- Threat model and motivated intruder test
- Technique selection
- Transformation specification
- Residual-risk measurement
- Utility assessment
- Release decision
- Governance, controls and re-assessment
- Traceability matrix
- Glossary and references
- Standard and licence note
1. Purpose, scope and legal test
1.1 Purpose and scope
This assessment decides whether [Dataset] can be released to [Recipient] in the form described in section 6, and under which conditions. It records the evidence for that decision so that a reviewer, a regulator or the data owner can reproduce it.
| Item | Value |
|---|---|
| Business purpose of the release | [Purpose, e.g. Example: academic study of delivery-time effects on repeat purchase] |
| Source dataset | [Table or extract, record count, time span] |
| Unit of observation | [Customer / order / event / household] |
| Release frequency | [One-off / monthly / continuous] |
| Out of scope | [Other datasets, derived models, internal analytics] |
1.2 Anonymisation versus pseudonymisation
The legal status of the output decides which obligations follow it. Record the position taken and the reasoning.
- Pseudonymised data (GDPR Article 4(5)): data that can no longer be attributed to a person without additional information that is kept separately under technical and organisational measures. It remains personal data for the organisation that holds the additional information, and the full set of data protection obligations continues to apply.
- Anonymous information (GDPR Recital 26): data where a person is not identifiable by any means reasonably likely to be used, taking into account cost, time, available technology and foreseeable developments. Data protection law does not apply to truly anonymous information, but the act of anonymising is itself processing of personal data and needs a lawful basis.
- Whose perspective: the ICO guidance and the EDPB consultation version both stress that identifiability depends on who holds the data and what else they can access. Assess the recipient's environment, not only your own. Check the current status of EDPB Guidelines 01/2025, which was published for consultation and may be replaced by a final version.
- Case law: the Court of Justice confirmed this relative approach in Case C-413/23 P, EDPS v SRB (judgment of 4 September 2025, ECLI:EU:C:2025:645). Pseudonymised data is not personal data in every case and for every person: depending on the circumstances, pseudonymisation can prevent a recipient that cannot reasonably re-identify from identifying the person, while the data stays personal data for the controller that holds the additional information. The controller's information duties are assessed at collection, from the controller's point of view, so recipients must still be named in the notice even if the data is non-personal in their hands. The case was decided under Regulation (EU) 2018/1725, which the Court reads in line with the GDPR; it was referred back to the General Court. Check later case law and the final EDPB guidelines.
| Question | Answer |
|---|---|
| Intended status for the recipient | [Anonymous / Pseudonymised personal data] |
| Status for [Organisation] after release | [Personal data, because the source and keys are retained] |
| Lawful basis for the anonymisation processing | [Basis and ROPA reference] |
| Special category or criminal offence data in source | [Yes, which / No] |
| Jurisdiction-specific tests considered | [EU GDPR, UK GDPR, others named] |
2. Release context and release model
2.1 Release model
Choose the least open model that still serves the purpose. The model drives the acceptable residual risk in section 7.
| Model | Description | Typical controls | Selected |
|---|---|---|---|
| Public | Anyone can download or query the output. No contract with recipients. | Strongest transformation, aggregate or differentially private outputs, no record-level data in most cases | [ ] |
| Controlled | Named recipients under a data sharing agreement, with use restrictions and a ban on re-identification. | Contract, access logging, recipient security assessment, moderate transformation | [ ] |
| Enclave | Recipients analyse inside a secure environment you operate; only vetted outputs leave. | Output checking, no download, session logging, lighter transformation of the analysis copy | [ ] |
2.2 Recipient environment
| Factor | Assessment |
|---|---|
| Recipient organisation and role | [Name, controller or independent party] |
| Number of people with access | [Count or "unbounded" for public] |
| Security controls at the recipient | [Assessment reference, e.g. compliance/supplier-security-assessment] |
| Other data the recipient holds or can obtain | [Customer lists, public registers, social media, previous releases] |
| Contractual controls | [DSA reference, no-re-identification clause, audit right, onward-sharing ban] |
| Retention at the recipient | [Period and deletion evidence] |
| Linkage with earlier or future releases | [Same population released before? Overlapping time windows?] |
Example: Corvid Commerce releases, each month, a rolling 12-month extract covering 120,000 customers (one row per customer, orders in the window summarised) from the "Orders" data product to a university research group under a data sharing agreement. The group has 6 named analysts, holds no Corvid customer data, and works on a managed university platform. Release model: controlled.
3. Data assessment and attribute classification
3.1 Attribute classes
| Class | Meaning | Default handling |
|---|---|---|
| Direct identifier (DI) | Identifies a person on its own: name, email, phone, account number, full address, device ID | Remove or replace with a pseudonym; never released in clear |
| Quasi-identifier (QI) | Identifies in combination and is plausibly known to an attacker: age, postcode, dates, gender, job | Generalise, suppress, perturb or aggregate; drives the risk metrics |
| Sensitive attribute (SA) | Value the release must not reveal about a known person: health, finances, purchases of a sensitive kind | Protect against attribute disclosure (diversity checks, noise, removal) |
| Non-identifying (NI) | Unlikely to be known to an attacker and not sensitive | Keep, but check for rare values and outliers |
3.2 Attribute register
| ID | Column | Class | Known to attacker? | Distinct values | Handling (section 6) |
|---|---|---|---|---|---|
| ATT-001 (Example) | customer_email | DI | Yes | 120,000 | Drop |
| ATT-002 (Example) | customer_id | DI | Yes (in breaches, receipts) | 120,000 | Replace with keyed pseudonym held only by Corvid |
| ATT-003 (Example) | birth_date | QI | Yes | 18,210 | Generalise to 10-year age band |
| ATT-004 (Example) | postcode | QI | Yes | 41,300 | Generalise to region (12 values) |
| ATT-005 (Example) | gender | QI | Yes | 3 | Keep |
| ATT-006 (Example) | last_order_timestamp | QI | Partly (own orders) | continuous | Generalise to month |
| ATT-007 (Example) | total_order_value (12 months) | SA and QI for outliers | Partly | continuous | Top-code at the 99th percentile |
| ATT-008 (Example) | main_product_category | SA (includes pharmacy, sexual wellness and baby categories, which reveal health or family circumstances) | Rarely | 24 | Keep; merge categories with fewer than 10 buyers; l-diversity check in section 7.3 |
| ATT-009 (Example) | delivery_note | DI risk (free text) | Yes | free text | Drop |
| ATT-010 (Example) | delivery_days | NI | Rarely | 1 to 21 | Keep |
3.3 Data characteristics that raise risk
Record the features that make re-identification easier, so that the technique choice in section 5 addresses them.
- Longitudinal records: the same person appears in many rows or many releases. Measure risk at the person level, not the row level.
- Small populations: a region, store or segment with few people.
- Outliers and rare combinations: unusual values in any column.
- Free text, images, geolocation traces and precise timestamps.
- Previous releases of the same population, which can be combined.
4. Threat model and motivated intruder test
4.1 Attack types considered
| ID | Attack | Description | Relevant to this release? |
|---|---|---|---|
| THR-001 | Prosecutor (targeted) | Attacker knows a specific person is in the data and looks for their record | [Yes / No, reason] |
| THR-002 | Journalist (any match) | Attacker tries to re-identify anyone, to show the release is unsafe | [Yes / No] |
| THR-003 | Marketer (bulk) | Attacker links many records to an external dataset for profit | [Yes / No] |
| THR-004 | Attribute disclosure | Attacker learns a sensitive value without singling out a record | [Yes / No] |
| THR-005 | Linkage across releases | Attacker combines this release with earlier ones | [Yes / No] |
| THR-006 | Membership inference | Attacker learns that a person is in the dataset at all | [Yes / No] |
| THR-007 | Insider at recipient | Authorised analyst misuses access | [Yes / No] |
4.2 Attacker profiles
| Profile | Knowledge assumed | Resources | Motivation | Likelihood (controlled release) |
|---|---|---|---|---|
| Motivated intruder (Example) | Public registers, social media, search engines, own knowledge of acquaintances | Moderate skill, no specialist tools, several days | Curiosity, publicity | Medium |
| Acquaintance (Example) | Age, region, gender and approximate purchase dates of a friend or relative | Low | Curiosity | Medium |
| Data broker (Example) | Large commercial profiles with demographics and postcodes | High | Commercial | Low (contract and no download) |
| Insider at recipient (Example) | Full access to the released data | Moderate | Misuse | Low (6 named analysts, logged) |
4.3 Motivated intruder test
The motivated intruder test asks whether a reasonably competent person, without specialist skills or prior knowledge of the data, but willing to use public sources and to invest effort, could identify someone. Run it on the transformed output, not the source, and record every attempt, including failed ones.
| ID | Date | Tester | Method | Target | Result |
|---|---|---|---|---|---|
| MIT-001 (Example) | YYYY-MM-DD | [@red-team] | Searched for rare region and age band combinations, then social media posts mentioning large orders | Records in classes below k = 10 before suppression | 2 plausible matches before suppression; none after |
| MIT-002 (Example) | YYYY-MM-DD | [@red-team] | Linked month, region and top-coded order value to a public product-review site | 50 sampled records | No unique match |
| MIT-003 (Example) | YYYY-MM-DD | [@red-team] | Compared with the previous monthly release to isolate new customers | Customers appearing for the first time | 1 class of size 3 isolated; fixed by measuring k across the 12-month window |
5. Technique selection
5.1 Technique families
The families below follow the grouping used in ISO/IEC 20889 and NIST SP 800-188. Descriptions are original summaries.
| Family | What it does | Strengths | Limits |
|---|---|---|---|
| Suppression | Removes values, columns or whole records | Simple, removes the riskiest records | Loses data; can bias results if suppressed records are not random |
| Generalisation | Replaces precise values with ranges or broader categories | Keeps records usable, easy to explain | Each extra QI multiplies the number of classes; hard for high-dimensional data |
| Pseudonymisation | Replaces identifiers with tokens, keyed hashes or encrypted values | Allows linkage across releases by the holder of the key | Output stays personal data; unkeyed hashes of guessable values are reversible |
| Aggregation | Publishes counts, sums or statistics instead of records | Strong protection with small-cell rules | Differencing attacks across tables; limited analysis |
| Noise addition and perturbation | Adds random noise, swaps or rounds values | Protects against exact matching | Without a formal model, protection is hard to quantify |
| Synthetic data | Generates artificial records that mimic statistical properties | Record-level analysis without real records | Models can memorise outliers; utility for rare subgroups is weak |
| Differential privacy | Adds calibrated noise so that any one person's contribution has a bounded effect, measured by epsilon | Formal, composable guarantee, robust to auxiliary data | Needs a privacy budget, careful implementation and a clear unit of privacy |
5.2 Selected techniques
| ID | Technique | Applied to | Reason | Threats addressed |
|---|---|---|---|---|
| TEC-001 (Example) | Removal | ATT-001, ATT-009 | No analytical need for email or free text | THR-001, THR-003 |
| TEC-002 (Example) | Keyed pseudonym (HMAC with a key held only by Corvid) | ATT-002 | Researchers need to follow one customer across orders | THR-003 |
| TEC-003 (Example) | Generalisation | ATT-003, ATT-004, ATT-006 | Reduce QI granularity to reach k of at least 10 | THR-001, THR-002 |
| TEC-004 (Example) | Top-coding | ATT-007 | Very high order values single people out | THR-001, THR-004 |
| TEC-005 (Example) | Record suppression | Records in classes below k | Remove residual small classes | THR-001, THR-002 |
| TEC-006 (Example) | Differential privacy (public dashboard only) | Weekly regional customer counts | Public release needs a guarantee that holds against any auxiliary data | THR-004, THR-005, THR-006 |
5.3 Pseudonymisation design
When pseudonyms are used, record how they are produced and who can reverse them.
| Item | Value |
|---|---|
| Method | [Keyed hash (HMAC-SHA-256) / tokenisation vault / format-preserving encryption] |
| Key or vault owner | [Team, separate from recipients] |
| Key storage | [KMS or HSM, reference to security/secrets-management-standard] |
| Key rotation and linkage impact | [Rotation breaks linkage with earlier releases; state the policy] |
| Domain separation | [Different key per recipient so that two recipients cannot join their copies] |
6. Transformation specification
6.1 Transformation rules
| ID | Column | Rule | Parameter | Order |
|---|---|---|---|---|
| TRF-001 (Example) | customer_email, delivery_note | Drop column | None | 1 |
| TRF-002 (Example) | customer_id | HMAC-SHA-256 with recipient-specific key, truncated to 16 hex characters | Key ID [key-ref] | 2 |
| TRF-003 (Example) | birth_date | Age at order date, then 10-year band; ages 80 and over in one band | Bands 18-29, 30-39 up to 80+ | 3 |
| TRF-004 (Example) | postcode | Map to region | 12 regions | 4 |
| TRF-005 (Example) | last_order_timestamp | Truncate to calendar month | None | 5 |
| TRF-006 (Example) | total_order_value | Top-code at the 99th percentile of the extract | Example: USD 640 | 6 |
| TRF-007 (Example) | All QI | Suppress records in equivalence classes smaller than k across the trailing 12 months | k = 10 | 7 |
| TRF-008 (Example) | birth_date band | Where a class fails the l-diversity rule, merge it with the class of the adjacent age band in the same region, gender and month (local generalisation), then re-measure | l = 3 distinct main product categories | 8 |
6.2 Pipeline
Run the steps in this order on every release, and loop back to generalisation whenever the measured thresholds are missed.
6.3 Implementation record
| Item | Value |
|---|---|
| Code location | [Repository and path] |
| Commit or release tag | [Hash or tag] |
| Run date and operator | YYYY-MM-DD, [@name] |
| Seed handling for random steps | [Seed stored securely, not released] |
| Output checksum | [SHA-256 of the release package] |
7. Residual-risk measurement
7.1 Thresholds
Set thresholds before measurement and record who approved them. The values below are examples for illustration and are not normative. The standard's annex gives example benchmarks (check the current text); your threshold must reflect your own context, release model and legal advice.
| Metric | Public | Controlled | Enclave |
|---|---|---|---|
| Minimum equivalence class size k (Example) | Not applicable (aggregates or DP only) | 10 | 5 |
| Maximum record-level risk (1/k) (Example) | Not applicable | 0.10 | 0.20 |
| Average risk (Example) | Not applicable | 0.05 | 0.10 |
| Epsilon per release period (Example) | 1.0 per quarter | Not used | Not used |
| Maximum suppression rate (Example) | Not applicable | 1% of records | 2% of records |
7.2 Equivalence class results (record-level release)
Measured on the 12-month window of the Example release, using the quasi-identifiers age band, region, gender and last-order month at the customer level (one row per customer).
| Measure | Before transformation | After generalisation | After suppression |
|---|---|---|---|
| Records | 120,000 | 120,000 | 119,786 |
| Equivalence classes | 18,640 | 2,480 | 2,443 |
| Unique records (k = 1) | 6,212 (5.18%) | 9 | 0 |
| Classes below k = 10 | Not measured | 37 (214 records) | 0 |
| Smallest class (k minimum) | 1 | 1 | 10 |
| Maximum record-level risk (1/k) | 1.00 | 1.00 | 0.10 |
| Average risk (classes / records) | 0.155 | 0.021 | 0.020 |
| Records suppressed | 0 | 0 | 214 (0.18%) |
How the Example numbers are derived:
- Suppressed records: 214 of 120,000 = 0.178%, rounded to 0.18%, below the 1% limit.
- Remaining records: 120,000 minus 214 = 119,786. Remaining classes: 2,480 minus 37 = 2,443.
- Average risk after suppression: 2,443 / 119,786 = 0.0204, rounded to 0.020, below the 0.05 Example threshold.
- Maximum record-level risk: 1 / 10 = 0.10, at the Example threshold.
7.3 Attribute disclosure checks
k-anonymity alone does not stop an attacker learning a sensitive value when everyone in a class shares it. Check the sensitive attributes per class.
| Check | Rule | Result |
|---|---|---|
| Distinct sensitive values per class (l-diversity) (Example) | At least 3 distinct main product categories (ATT-008) in every class | 2,431 of 2,443 classes pass. The other 12 are merged by TRF-008 with 12 distinct passing neighbours, then re-measured: all classes pass |
| Distribution closeness (t-closeness) (Example) | Optional for this release | Not applied, reason recorded |
| Top-coded value share (Example) | No class where all values are top-coded | Pass |
Coarsening the sensitive attribute itself would reduce the number of distinct values per class and make l-diversity harder to meet, so the remedy acts on the quasi-identifiers. Final release (Example): 12 merges remove 12 classes, so 2,443 minus 12 = 2,431 classes over the same 119,786 records; average risk 2,431 / 119,786 = 0.0203, still reported as 0.020; the smallest class is still at least 10 records, because merging only enlarges classes; no further records are suppressed.
7.4 Differential privacy budget (public outputs)
For outputs released under differential privacy, follow NIST SP 800-226 when evaluating the guarantee: name the unit of privacy, the privacy parameters, the composition across releases and the implementation's trust model.
| Item | Value |
|---|---|
| Unit of privacy | Example: one customer, all their orders in the period |
| Contribution bound | Example: each customer is counted once per week, in one assigned region (the region of the last order), so one customer changes the vector of regional counts by at most 1 |
| Privacy definition | Example: pure epsilon-differential privacy, Laplace mechanism |
| Trust model | Example: central model, noise added by Corvid before publication |
| Budget per quarter | Example: epsilon 1.0 |
| ID | Output | Releases per quarter | Epsilon each | Epsilon total |
|---|---|---|---|---|
| DPB-001 (Example) | Weekly distinct customers by region | 13 | 0.05 | 0.65 |
| DPB-002 (Example) | Monthly spend by category (clipped sum) | 3 | 0.10 | 0.30 |
| DPB-003 (Example) | Reserve for corrections | 1 | 0.05 | 0.05 |
| Total | 1.00 |
Noise calibration for DPB-001 (Example): sensitivity 1 (one customer changes a count by at most 1), epsilon 0.05, Laplace scale b = 1 / 0.05 = 20, standard deviation √2 × 20 ≈ 28.3. For a region with about 4,000 weekly customers, the standard deviation is about 28.3 / 4,000 ≈ 0.7% of the count (mean absolute error b = 20, about 0.5%).
For DPB-002 (Example): monthly spend clipped at USD 500 per customer, so the sensitivity of the sum is 500; epsilon 0.10 split evenly between the clipped sum (0.05) and the count (0.05); Laplace scale for the sum = 500 / 0.05 = 10,000, standard deviation about 14,142. On a category sum of about USD 2,000,000 the standard deviation is about 0.7% of the sum (mean absolute error 10,000, 0.5%). The USD 500 clip applies to each customer's total monthly spend across all categories, so the L1 sensitivity of the vector of category sums is 500; for the count, each customer is counted in one category only (their main category), so its sensitivity is 1.
Sequential composition means the epsilons of all releases about the same people add up. When the quarterly budget is spent, stop releasing or move to a new period under an approved budget policy. Never refresh the budget silently.
8. Utility assessment
Compare key analyses on the source and on the release. Agree the acceptance criteria with the recipient before measurement.
| ID | Analysis | Source result | Release result | Acceptance criterion | Pass |
|---|---|---|---|---|---|
| UTL-001 (Example) | Repeat purchase rate by delivery-days band | 41.2% overall | 41.1% overall | Within 1 percentage point | Yes |
| UTL-002 (Example) | Regression coefficient of delivery days on repeat purchase | -0.031 | -0.030 | Same sign, within 10% relative | Yes |
| UTL-003 (Example) | Share of customers aged 80+ by region | Varies 1% to 4% | Suppression removed 3 regions | All regions present | No: accepted limitation, documented |
| UTL-004 (Example) | Weekly regional customer counts (DP) | Exact | Noise standard deviation about 0.7% of the count | Below 2% | Yes |
Record known distortions so that recipients interpret results correctly: suppressed subgroups, top-coding, generalised dates and the noise scale of any differentially private output.
9. Release decision
9.1 Decision
| Item | Value |
|---|---|
| Decision | [Release / Release with conditions / Do not release / Release in enclave only] |
| Legal status of the output for the recipient | [Anonymous / Pseudonymised personal data] |
| Basis for the status | [Sections 4 and 7 evidence; residual risk against thresholds] |
| Conditions | [Contract clauses, access limits, output checking, deletion date] |
| Valid until | YYYY-MM-DD or [trigger in section 10.3] |
| DPIA required | [Yes, reference / No, reason] |
Example decision: Release with conditions. The output is pseudonymised personal data for Corvid Commerce and, in the recipient's environment and under the data sharing agreement, the privacy lead judges identification not reasonably likely. Conditions: no attempt to re-identify, no linkage with other datasets about Corvid customers, no onward sharing, deletion at study end, annual audit right.
9.2 Decision flow
Use this flow to explain to the data owner why the chosen release model is the least open one that serves the purpose.
9.3 Residual risks accepted
| ID | Residual risk | Likelihood | Impact | Owner | Treatment |
|---|---|---|---|---|---|
| RR-001 (Example) | Insider at recipient combines release with personal knowledge of a colleague | Low | Medium | [@dpo] | Contract, training, access logging |
| RR-002 (Example) | Future public data increases linkage power | Low | Medium | [@privacy-engineer] | Annual re-assessment |
10. Governance, controls and re-assessment
10.1 Roles
| Role | Responsibility | Name |
|---|---|---|
| Data owner | Accepts residual risk, approves release | [@name] |
| Privacy engineer | Runs transformation and measurement | [@name] |
| Privacy lead or DPO | Independent review of the legal status | [@name] |
| Recipient lead | Ensures recipient complies with conditions | [@name] |
| Security lead | Key management, access control, incident handling | [@name] |
10.2 Controls
| ID | Control | Evidence |
|---|---|---|
| CTL-001 (Example) | Data sharing agreement with no-re-identification and no-onward-sharing clauses | Signed DSA reference |
| CTL-002 (Example) | Pseudonymisation key held by a team without access to the release | Key policy, access review |
| CTL-003 (Example) | Release log listing every version, recipient and checksum | Release register |
| CTL-004 (Example) | Re-identification incident procedure: report within 24 hours to Corvid, stop use, delete copies | Incident procedure reference, compliance/incident-response-plan |
| CTL-005 (Example) | Deletion confirmation at end of retention | Deletion certificate per data/data-retention-deletion-standard |
10.3 Re-assessment triggers
Re-run sections 3 to 9 when any of these occurs:
- New column, new data source or schema change in the release.
- New recipient, new release model or change in recipient environment.
- Publication of new auxiliary data about the same population.
- A suspected or confirmed re-identification, here or in a similar release elsewhere.
- Cumulative privacy budget reaches its limit.
- Scheduled review date reached (Example: every 12 months).
- Change in guidance, such as a final version of EDPB Guidelines 01/2025 or an update of the ICO guidance after the Data (Use and Access) Act 2025.
11. Traceability matrix
| Threat | Attributes | Technique | Measurement | Control | Residual risk |
|---|---|---|---|---|---|
| THR-001 (Example) | ATT-003, ATT-004, ATT-005, ATT-006 | TEC-003, TEC-005 | k minimum 10, section 7.2 | CTL-001 | RR-001 |
| THR-002 (Example) | All QI | TEC-003, TEC-005 | MIT-001, MIT-002 | CTL-001, CTL-003 | RR-002 |
| THR-003 (Example) | ATT-001, ATT-002 | TEC-001, TEC-002 | No DI in output | CTL-002 | Low |
| THR-004 (Example) | ATT-007, ATT-008 | TEC-004, TEC-006 | Section 7.3, DPB-002 | CTL-001 | Low |
| THR-005 (Example) | All QI across months | TEC-005 (12-month window) | MIT-003 | CTL-003 | Low |
| THR-006 (Example) | Public counts | TEC-006 | DPB-001, budget 1.0 | Budget policy | Low |
12. Glossary and references
12.1 Glossary
| Term | Meaning in this document |
|---|---|
| Anonymous information | Data where no person is identifiable by means reasonably likely to be used (GDPR Recital 26 test) |
| Pseudonymisation | Processing so that data cannot be attributed to a person without separately held additional information (GDPR Article 4(5)) |
| Direct identifier | Attribute that identifies a person on its own |
| Quasi-identifier | Attribute that identifies a person in combination with others and is plausibly known to an attacker |
| Equivalence class | Set of records sharing the same quasi-identifier values |
| k-anonymity | Property that every equivalence class has at least k records |
| l-diversity | Property that each class has at least l distinct sensitive values |
| Motivated intruder | Reasonably competent person without specialist knowledge who tries to identify someone using available sources |
| Differential privacy | Formal guarantee that the output changes only slightly whether or not one unit of privacy is included |
| Epsilon | Privacy loss parameter in differential privacy; lower means stronger protection |
| Unit of privacy | The entity (person, household, record) whose contribution differential privacy protects |
| Release model | Public, controlled or enclave access to the output |
12.2 References
- Regulation (EU) 2016/679 (GDPR), Recital 26 and Articles 4(5), 5, 6, 25, 32 and 89, on EUR-Lex.
- ISO/IEC 27559:2022, Privacy enhancing data de-identification framework (first edition, November 2022), iso.org/standard/71677.html.
- ISO/IEC 20889:2018, Privacy enhancing data de-identification terminology and classification of techniques (first edition, 2018-11-06).
- NIST SP 800-188, De-Identifying Government Datasets: Techniques and Governance (final, September 2023), csrc.nist.gov/pubs/sp/800/188/final.
- NIST SP 800-226, Guidelines for Evaluating Differential Privacy Guarantees (final, March 2025), csrc.nist.gov/pubs/sp/800/226/final.
- ICO, Anonymisation and pseudonymisation guidance (published 28 March 2025; marked under review after the Data (Use and Access) Act 2025), ico.org.uk.
- EDPB Guidelines 01/2025 on Pseudonymisation, version 1 for public consultation (adopted 16 January 2025), edpb.europa.eu.
- Court of Justice of the European Union, judgment of 4 September 2025, Case C-413/23 P, EDPS v SRB (Concept of personal data), ECLI:EU:C:2025:645, curia.europa.eu (press release No 107/25).
- Related templates: DPIA (
compliance/dpia), Privacy Threat Model (security/privacy-threat-model), PET Selection Assessment (compliance/pet-selection-assessment), Privacy by Design Review (compliance/privacy-by-design-review), Data Sharing Agreement (compliance/data-sharing-agreement).
Standard and licence note
Based on GDPR Recital 26 and Article 4(5), NIST SP 800-188 (September 2023) and NIST SP 800-226 (March 2025), which are US Government works in the public domain, and the ICO guidance on anonymisation and pseudonymisation; where ICO material informed the wording, it contains public sector information licensed under the Open Government Licence v3.0. EDPB Guidelines 01/2025 are cited as the consultation version only. Structure aligned with ISO/IEC 27559:2022 and ISO/IEC 20889:2018, which are copyrighted: only titles and the names of assessment stages are referenced and no text, tables or definitions are reproduced. All text in this template is original. Check the current official versions before use, in particular the final EDPB guidelines and any ICO update after the Data (Use and Access) Act 2025. This is a documentation format, not legal advice. Template licence: MIT.
Ähnliche Vorlagen
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 & KonformitätPET Selection Assessment Template (Privacy-Enhancing Technologies)
Problem, data flows, requirements, eight candidate PETs, knock-out screening, cost, residual risk, weighted decision matrix, validation plan
ISO & KonformitätSupplier Security Assessment Template
Vendor vetting + ongoing monitoring