Overview of Recent Developments
On July 8, 2026, the European Data Protection Board (EDPB) released new guidelines on anonymisation, reshaping how your team should determine if data falls outside the GDPR scope. These guidelines introduce a three-criteria framework, no record isolation, no linkage, no inference, and offer two assessment methods: a contextual approach that considers different actors' identification capabilities, and a simplified approach that ignores these differences for operational ease.
The EDPB also released guidelines on web scraping for generative AI and finalized its blockchain guidelines. These documents reflect the EDPB's interpretation of the Court of Justice ruling in C-413/23 P EDPS v SRB from September 2025.
Key Dates
- September 4, 2025: Court of Justice issues ruling in C-413/23 P EDPS v SRB, clarifying when data relates to an identifiable person.
- July 8, 2026: EDPB adopts anonymisation guidelines, web scraping guidelines, and final blockchain guidelines during a plenary session.
- July 8, 2026: Public consultation opens for anonymisation and web scraping guidelines.
- October 30, 2026: Consultation period closes.
The gap between the CJEU ruling and the EDPB's response is significant. If your organization implemented anonymisation controls based on your interpretation of C-413/23 P, you might now face compliance issues if your approach differs from the Board's.
Common Anonymisation Control Failures
Many organizations lack a robust anonymisation assessment process. They've often treated anonymisation as a technical task, applying k-anonymity and removing direct identifiers. The EDPB's framework highlights three common control failures:
Missing Capability Mapping: The contextual approach requires identifying every entity that might access your dataset and assessing their identification capabilities. If you're sharing anonymised data with research partners, you need documentation showing what linkage capabilities each partner has. Most data-sharing agreements don't specify this, making it hard to prove your data is anonymous from a specific entity's perspective.
No Inference Testing: The third criterion, no inference, requires testing whether someone could derive identifying information about individuals even without linking records. For example, a dataset of hospital admissions might allow someone to infer that "the only person over 90 in postal code 12345 with that rare diagnosis is probably Mrs. Anderson." Many organizations skip this inference analysis.
Undocumented Simplified Approach Election: The simplified approach lets you treat all potential recipients as having maximum identification means. It's more conservative but operationally simpler. However, if you're using this approach, you need to document that choice and apply it consistently. Many organizations use a hybrid approach without documenting the rationale.
What the Guidelines Require
Article 4(1) GDPR defines personal data as information relating to an identified or identifiable natural person. The EDPB guidelines clarify that "identifiable" means someone can be distinguished in a way that allows different treatment. This isn't about theoretical re-identification, it's about whether someone with reasonably likely means could single out that individual.
The three-criteria framework operationalizes this standard:
- No Record Isolation: Can someone single out records about an individual within the dataset?
- No Linkage: Can someone link records about an individual across datasets?
- No Inference: Can someone infer information about an individual even without isolation or linkage?
If any criterion fails, further analysis is needed. The data might still be anonymous if, for example, isolation is possible but the entity attempting it lacks the means reasonably likely to be used.
The guidelines also address the relationship test: data relates to an individual if it's about them by content, purpose, or effect. A dataset of building energy consumption might not seem to relate to individuals by content, but if its purpose is to infer occupancy patterns, it relates to the building's residents.
Action Items for Your Team
Document Your Approach Election: Decide whether you're using the contextual or simplified approach for each anonymisation use case. The simplified approach is defensible if you document why operational consistency justifies treating all data as potentially accessible to actors with maximum means. Avoid switching between approaches based on convenience.
Build Capability Profiles for Data Recipients: If you're using the contextual approach, create a capability matrix for every entity that might access your anonymised data. Document what linkage datasets they control, what inference tools they have access to, and what contractual restrictions limit their use. Update this matrix when you add new data-sharing partners.
Test All Three Criteria, Not Just Linkage: Most anonymisation testing focuses on re-identification attacks, can someone link your dataset to publicly available data? That's the linkage criterion. You also need isolation testing (can someone filter the dataset to records about a specific person?) and inference testing (can someone derive facts about an individual without isolating their record?). If you're only testing linkage, you're missing two-thirds of the framework.
Review AI Training Datasets Immediately: The web scraping guidelines clarify that legitimate interest can support scraping for AI training, but only with specific safeguards. If you're training models on scraped data, verify you have timestamp documentation for when data was collected, validation procedures to ensure accuracy, and technical measures to prevent collection of special category data. The EDPB's reference to GC & Others (C-136/17) suggests incidental collection of special category data might be permissible if you implement measures to prevent its use, but "incidental" requires proof you took steps to avoid it.
Audit Your Blockchain Implementations: If you're processing personal data through blockchain, the final guidelines provide the compliance framework. Review the EDPB's track changes version to understand which controls are now considered mandatory versus recommended.
The simplified approach isn't a shortcut, it's a compliance strategy that trades granular risk assessment for operational certainty. If you choose it, you'll anonymise more conservatively than legally required in some cases. That's acceptable. What's not acceptable is inconsistent application or undocumented methodology. The EDPB has given you two defensible paths. Pick one and document why.
