Most data governance teams treat anonymisation like a technical checkbox. You strip the names, hash the IDs, and move on. Then the EDPB releases draft guidelines that make one thing clear: you've been thinking about this wrong.
The draft Guidelines 02/2026, adopted on 7 July 2026, don't just update the 2014 Opinion. They expose how organisations keep making the same foundational errors, now amplified by AI capabilities and cross-border data flows. Here's what keeps going wrong.
Why These Mistakes Keep Happening
Anonymisation sits at an uncomfortable intersection. It's partly legal analysis, partly technical implementation, and partly risk forecasting. Most teams assign it to one function, usually engineering or legal, when it requires all three working together.
The guidelines emphasise that anonymity is contextual, not absolute. Data anonymous to one recipient might be personal data to another. But your governance framework probably doesn't account for this variability. You're applying a binary standard to a spectrum problem.
Mistake 1: Treating Anonymisation as a One-Time Event
Why it happens: You anonymise a dataset for a specific project. The technical work is done, the documentation is filed, and everyone moves on. The dataset gets reused, shared with new partners, or sits in storage for years.
The real consequence: The EDPB explicitly states that anonymisation isn't a one-time exercise. Data that's effectively anonymised today may become vulnerable as new datasets become publicly available, AI techniques advance, or your organisation acquires additional information that enables linkage. You're holding datasets you believe are anonymous, but you haven't reassessed them against current re-identification risks.
The specific fix: Build periodic reassessment into your data governance calendar. For datasets shared externally or used in ongoing analytics, schedule reviews every 12-18 months. For each review, document:
- New publicly available datasets that could enable linkage
- Changes in the recipient's technical capabilities or data holdings
- Advances in re-identification techniques relevant to your data type
- Whether the original anonymisation techniques still satisfy the three-part test (no isolation, no linkage, no inference)
This isn't about re-anonymising everything. It's about confirming your original assessment remains valid or identifying when it doesn't.
Mistake 2: Ignoring the Processor Perspective Rule
Why it happens: You send pseudonymised data to a processor who can't re-identify individuals. The processor has no access to your master identifier table. You assume that because they can't identify anyone, the data is anonymous in their hands.
The real consequence: The guidelines clarify that if an entity processes information on behalf of another, you assess whether the data is personal by reference to the controlling entity's perspective. If you're the controller and can re-identify individuals, the data remains personal data when your processor handles it, even if the processor itself cannot perform re-identification.
This matters for your processing agreements. You can't draft a processor arrangement as if they're handling anonymous data just because they lack re-identification means. Article 28 obligations still apply. Your processor still needs appropriate technical and organisational measures. You still need a written contract covering the Article 28(3) requirements.
The specific fix: When you share data with processors, apply this test: Can you, as the controller, re-identify individuals from the dataset using information available to you? If yes, treat it as personal data in the processor's hands regardless of their capabilities. Draft your Article 28 agreements accordingly. Only claim anonymity when you've genuinely severed your own ability to re-identify, not just the processor's.
Mistake 3: Underestimating Inference Risks in Aggregate Data
Why it happens: Your team focuses on record-level anonymisation. You ensure individual records can't be singled out or linked. But you're publishing statistical outputs, training AI models on the data, or releasing aggregate reports. These feel safe because they don't expose individual records.
The real consequence: The EDPB's third criterion, no inference, covers exactly this scenario. Inference risks arise from both record-level and aggregated data, including statistical outputs, AI models, and synthetic datasets. An inference becomes problematic when it relates to a specific individual and could affect their rights or interests.
Consider a scenario where your team releases aggregated salary data broken down by department, role, and tenure band. If one employee is the only senior engineer in the R&D department with 8-10 years of tenure, that aggregate cell reveals their approximate salary. You've created an inference risk without exposing a single identified record.
The specific fix: Before releasing any aggregate data or model outputs, conduct an inference risk assessment:
- Identify cells or combinations with small populations (typically fewer than 5-10 individuals)
- Assess whether attributes in combination could point to specific individuals
- Consider what someone familiar with your organisation structure could deduce
- Apply suppression rules or add noise to outputs where inference risks exist
For AI models, document what information the model could reveal about training data subjects, particularly in cases of model inversion or membership inference attacks.
Mistake 4: Using Only the Simplified Approach
Why it happens: The guidelines introduce two assessment methodologies: contextual and simplified. The simplified approach is easier. It assumes broader re-identification capabilities and disregards differences between entities. Your team adopts it because it's conservative and seemingly safer.
The real consequence: You're treating genuinely anonymous data as if it's still personal data. This creates unnecessary compliance burden. You're applying transparency obligations, maintaining lawful bases, and implementing Article 32 measures for datasets that don't actually fall under the GDPR.
More importantly, you're limiting legitimate uses of data that could support research, product development, or public interest projects. The simplified approach, used exclusively, becomes a barrier rather than a tool.
The specific fix: Use the simplified approach as your starting point, not your endpoint. When it indicates data might still be personal, conduct a contextual assessment for high-value datasets:
- Identify the specific entities who will access the data
- Document the means reasonably likely to be available to them for re-identification
- Consider their existing data holdings, technical capabilities, and legal powers
- Assess whether they could satisfy any of the three criteria (isolation, linkage, inference) using those specific means
The EDPB suggests combining both approaches. Start simplified, then go contextual where the business case justifies the additional analysis.
Mistake 5: Forgetting That Anonymisation Itself Is Processing
Why it happens: Your team views anonymisation as the exit from GDPR obligations. You're moving data out of scope, so you focus on the technical outcome rather than the process.
The real consequence: The EDPB reminds organisations that the process of anonymisation itself remains subject to the GDPR. You need a lawful basis for the anonymisation processing. You must comply with transparency obligations, data subjects should generally know you're anonymising their data and for what purpose. You need appropriate technical and organisational measures during the anonymisation process.
If you're anonymising data without a lawful basis, or without informing data subjects in your privacy notice, you're in breach before you even achieve anonymity.
The specific fix: Treat anonymisation as a processing activity in your Article 30 records:
- Document your lawful basis (typically the same basis as the original processing, or legitimate interests for archiving/research purposes)
- Update privacy notices to explain that data may be anonymised for specific purposes
- Apply appropriate security measures during the anonymisation process
- Record the anonymisation in your processing register, including purpose, categories of data, and recipients of the anonymised output
Don't wait until after anonymisation to think about compliance. The journey matters as much as the destination.
Prevention Checklist
Before you classify any dataset as anonymous:
□ Conduct the three-part test: confirm no isolation, no linkage, no inference from the relevant entity's perspective
□ Document which perspective you're using (controller's, processor's, recipient's) and why
□ If using the simplified approach, note whether a contextual assessment might yield a different conclusion for high-value use cases
□ Schedule the next reassessment date (12-18 months for externally shared or long-term datasets)
□ Verify you have a lawful basis for the anonymisation processing itself
□ Confirm your privacy notice covers anonymisation activities
□ For aggregate outputs or AI models, assess inference risks separately from record-level risks
□ If sharing with a processor, apply the controller's perspective, not the processor's capabilities
□ Maintain evidence supporting your anonymisation conclusion, including the state of the art at assessment time
The draft guidelines are open for consultation until 30 October 2026. Your current anonymisation practices probably need adjustment before they're finalised.
