The European Data Protection Board (EDPB) published draft Guidelines 02/2026 on Anonymisation on 7 July 2026, and they're not a gentle update. If you've been treating anonymisation as a one-time technical exercise, you're about to discover it's an ongoing compliance obligation with its own documentation trail, periodic reassessment schedule, and potential personal data breach exposure.
This checklist walks you through what changes when the EDPB finalizes these guidelines (consultation closes 30 October 2026). It's designed for teams that already anonymise data but need to confirm their approach meets the new relative identifiability standard.
What This Checklist Covers
These guidelines replace the Article 29 Working Party's Opinion 05/2014 on Anonymisation Techniques. The core shift: anonymity is no longer an intrinsic property of your dataset. It depends on who holds the data and what they can realistically do with it. That means the same dataset can be personal data for your organization and anonymous for your research partner, depending on each entity's means and context.
You'll need to reassess data you currently treat as anonymous, document your reasoning for each relevant entity that touches it, and build a reassessment cadence into your data governance program.
Prerequisites
Before you start this checklist, confirm you have:
- Current inventory of datasets you treat as anonymous. You can't reassess what you haven't catalogued.
- Access to the technical staff who performed the original anonymisation. You'll need their documentation of techniques applied.
- List of all entities that receive or could access each dataset. Controllers, processors, research collaborators, data buyers.
- Understanding of your Article 6 lawful basis for the anonymisation processing itself. The guidelines confirm anonymisation is processing under GDPR and requires a lawful basis.
Anonymisation Assessment Checklist
1. Identify Every Relevant Entity for Each Dataset
For each dataset you treat as anonymous, list every entity with realistic access: your organization, processors handling it on your behalf, recipients you share it with, potential third parties who could obtain it.
Where a processor handles data on your behalf, the controller's perspective governs the assessment. The data remains personal for the processor regardless of whether they could independently identify anyone.
Good looks like: A spreadsheet mapping each anonymised dataset to specific entities (by name and role), noting whether each is a controller, processor, or recipient, with documented reasoning for why you included or excluded borderline cases.
2. Choose Your Assessment Route
The guidelines offer two approaches:
- Contextual approach: Assess each entity's actual capabilities individually. More work, potentially more permissive outcome.
- Simplified approach: Treat all entities as equally capable of using any available re-identification technique. Conservative, easier to apply.
You can combine them: start simplified, then pivot to contextual for specific techniques where you believe the simplified approach is too conservative.
Good looks like: A documented decision (in your data protection impact assessment or anonymisation policy) stating which approach you're using for which datasets, with justification tied to data sensitivity, recipient sophistication, and available resources for the assessment.
3. Apply the Two-Question Test
For each entity identified in step 1, answer:
- Does the data relate to a natural person?
- If yes, is that natural person identified or identifiable by this specific entity?
If the answer to question 1 is no, or if the answer to question 2 is no, the data is anonymous from that entity's perspective.
Good looks like: A matrix showing each dataset-entity pair with clear yes/no answers to both questions, supported by technical analysis of what information and means that specific entity has available.
4. Evaluate Against the Three Criteria
For any dataset where question 2 required deeper analysis, test whether the relevant entity could:
- Isolate a record: Single out an individual record with sufficient precision to treat that person differently.
- Link records: Join the dataset to external data or available information (including probabilistic or inference-based linkage).
- Infer attributes: Deduce information about a specific individual with enough accuracy to identify or single them out.
Failing one criterion doesn't automatically make the data personal, but it triggers further analysis of whether that weakness enables singling out with sufficient accuracy.
Good looks like: Technical documentation for each criterion showing the specific techniques tested (k-anonymity, differential privacy, suppression), the auxiliary datasets considered, and quantified risk where measurable. If you can't quantify, document the qualitative reasoning.
5. Document Means Reasonably Likely to Be Used
For each entity, assess whether they would reasonably use the means required for re-identification. Consider:
- Properties of the data itself (granularity, quasi-identifiers present)
- Context of release and access restrictions you've imposed
- Availability and cost of auxiliary information
- Technical and financial resources of the entity
- Legal prohibitions on re-identification (only count these if enforcement is effective and the prohibition hasn't been breached in comparable situations)
Contractual restrictions don't count as legal prohibitions. They should complement technical measures, not replace them.
Good looks like: A risk assessment memo for each high-stakes dataset stating which re-identification means exist, which entities have the resources to use them, and why you conclude those means are or aren't reasonably likely to be used. Include cost estimates, technical barriers, and enforcement track record for any legal prohibitions you're relying on.
6. Handle Mixed Datasets Appropriately
If your dataset includes some genuinely anonymous records alongside records that remain personal, assess at the record level. The personal records trigger full GDPR obligations.
Your technical and organisational measures must be capable of treating the two categories differently.
Good looks like: Segmentation logic that flags personal records, separate retention schedules, and access controls that apply GDPR protections to the personal subset while allowing broader use of the truly anonymous records.
7. Establish a Lawful Basis for Anonymisation Processing
The act of anonymisation is processing under GDPR. You need a lawful basis under Article 6 (and an Article 9(2) condition if you're anonymising special category data).
Good looks like: Your records of processing activities explicitly list anonymisation as a processing operation, with the lawful basis documented (typically legitimate interests, with a legitimate interests assessment on file if you're relying on Article 6(1)(f)).
8. Build Periodic Reassessment Into Your Schedule
Anonymity isn't permanent. As re-identification techniques evolve and auxiliary datasets become available, yesterday's anonymous data may become tomorrow's personal data.
Calibrate reassessment frequency based on data sensitivity, how you use or disclose it, and the pace of technological development in relevant domains.
Good looks like: A reassessment schedule in your anonymisation policy (e.g., annually for low-risk datasets, quarterly for datasets shared with multiple entities, triggered reassessment if you become aware of new re-identification techniques or a security incident). Calendar reminders assigned to specific staff.
9. Prepare for Security Incident Scenarios
A security incident may trigger reassessment of whether data remains anonymous. If reassessment concludes the data has become personal, you may have personal data breach notification obligations under Articles 33 and 34.
Good looks like: Your incident response plan includes a decision tree: "If anonymised dataset X is exposed, who assesses whether it remains anonymous? What's the timeline? If it's now personal, who triggers breach notification?"
Common Mistakes
Treating contractual prohibitions as sufficient protection. Your data sharing agreement may forbid re-identification, but unless that prohibition is backed by effective enforcement and hasn't been breached in comparable situations, it doesn't reduce the likelihood that means will be used.
Assuming processor assessments are independent. If you're the controller, your perspective governs. The processor can't treat the data as anonymous just because they lack the auxiliary information you have.
Skipping record-level assessment in mixed datasets. Declaring an entire dataset anonymous because most records meet the criteria exposes you to GDPR violations on the personal records you failed to protect.
One-and-done anonymisation. If you anonymised data in 2020 and haven't reassessed since, you're operating on outdated assumptions about available re-identification techniques and auxiliary datasets.
Next Steps
The consultation period runs until 30 October 2026. If specific provisions in these guidelines create operational challenges for your use cases, the consultation is your opportunity to provide targeted input. The EDPB has historically refined positions based on stakeholder feedback, though substantial portions of draft text typically survive intact.
Start your reassessment now rather than waiting for final guidelines. The relative approach the EDPB adopted reflects the CJEU's position in EDPS v SRB, so the core framework is unlikely to change materially. What may shift are specific technical examples or the treatment of edge cases.
Your anonymisation program needs governance infrastructure: documented assessments, reassessment schedules, and incident response integration. That infrastructure takes time to build. Treat these guidelines as the forcing function to formalize what's likely been an ad hoc process.
