The European Data Protection Board's draft Guidelines 02/2026 on Anonymisation, adopted on July 7, 2026, reveal that many organizations have built their anonymization practices on shaky ground. These aren't minor compliance gaps. They're structural flaws that persist even after legal review, because teams misunderstand what the GDPR actually requires when you claim data is anonymous.
Here's what keeps going wrong, and how to fix it.
Why These Mistakes Keep Happening
Most anonymization failures stem from treating anonymity as a technical checkbox rather than a risk assessment. Your team applies k-anonymity or differential privacy, documents the technique, and assumes you're done. But GDPR Article 4(1) defines personal data relationally: information is anonymous only if it doesn't relate to an identified or identifiable individual. The EDPB's new Guidelines make clear that "identifiable" depends on who's looking at the data and what means they have available. This perspective-based approach requires both legal and technical judgment, not just cryptographic proof.
Mistake 1: Assessing Anonymity from Your Own Perspective Only
Why it happens: Your data science team runs the anonymization process, tests re-identification internally, confirms nobody on your team can reverse it, and declares victory. You've assessed whether you can re-identify individuals, not whether relevant external entities can.
Real consequence: You share the dataset with a research partner who has access to auxiliary data you don't control. They link your "anonymous" records to their own customer database using shared timestamps and geographic fields. The SRB case demonstrated this exact problem: anonymity depends on the means available to each entity that processes the data, not just the entity that performed the anonymization.
The fix: Map every entity that will access, control, or process the dataset. For each one, document: what auxiliary data they control, what specialist services they could access, what legal avenues they have to obtain additional information, and whether they're subject to legal prohibitions against re-identification. The EDPB's Guidelines specify that where an entity processes data on behalf of another, you assess from the controller's perspective. If the data are personal for the controller, they're personal for the processor too.
Mistake 2: Treating Contractual Restrictions as Technical Controls
Why it happens: You add a clause to your data sharing agreement: "Recipient agrees not to attempt re-identification." Your legal team approves it. You treat the dataset as anonymous because re-identification is now contractually prohibited.
Real consequence: The EDPB warns that contractual restrictions don't equal legal prohibitions. A contract creates civil liability, not a technical barrier. If your recipient suffers a breach, the attacker isn't bound by your contract. If the recipient's business model changes or they're acquired, the new owner may interpret the restriction differently. You've created compliance theater, not anonymity.
The fix: Distinguish between legal prohibitions (laws that make re-identification a criminal or administrative offense) and contractual commitments (agreements you hope the other party honors). Under Recital 26 GDPR, assess whether re-identification remains "reasonably likely" using means the entity could legally and practically employ. If your only protection is a contract clause, you're still processing personal data and need a GDPR legal basis.
Mistake 3: Ignoring Readily Available Specialist Services
Why it happens: Your team evaluates re-identification risk based on what a typical data analyst could do with standard tools. You don't consider that commercial re-identification services, data brokers, and cloud-based linkage platforms exist and are easily accessible.
Real consequence: The EDPB's Guidelines note that re-identification may remain reasonably likely where specialist third-party services are readily available. Consider a team that anonymizes location data by reducing GPS precision to the census tract level. They test internally and confirm they can't re-identify individuals. But commercial services can cross-reference census tract patterns with publicly available property records, vehicle registrations, and social media check-ins. What seemed anonymous to your internal team is identifiable to anyone willing to spend $500 on a data enrichment API.
The fix: During your anonymization assessment, research what commercial services exist in your domain. If you're working with health data, check what patient re-identification tools academic researchers discuss. If you're anonymizing location data, test whether data broker APIs can reverse your technique. Document this research as part of your "reasonably likely means" analysis. If readily available services can re-identify your dataset, it's not anonymous under GDPR.
Mistake 4: Failing the Inference Criterion Without Realizing It
Why it happens: Your team focuses on record isolation and linkage (the first two EDPB criteria) but overlooks inference. You've ensured no unique records exist and prevented linking across datasets. But the anonymized data still supports specific, meaningful conclusions about individuals.
Real consequence: You publish a research dataset with k-anonymized health records. No single record is unique, and you've removed direct identifiers. But the dataset includes rare disease diagnoses combined with age ranges and postal codes. For individuals with rare conditions in small geographic areas, the data supports highly specific inferences even without re-identification. Under the EDPB's three-criteria test, this fails the inference criterion.
The fix: After applying anonymization techniques, ask: "What specific and meaningful conclusions can we draw about an individual from this data?" Test edge cases: rare values, small subgroups, outliers. If someone can infer sensitive attributes about a specific person (even without knowing their name), you haven't met all three criteria. You'll need additional suppression, generalization, or noise injection to pass the inference test.
Mistake 5: Choosing the Simplified Approach by Default
Why it happens: The EDPB describes two methodologies: a contextual approach (assessing means available to relevant entities) and a simplified approach (assuming anyone could attempt re-identification). The simplified approach sounds safer, so you default to it without considering the trade-off.
Real consequence: The simplified approach sets a higher bar, which sounds good for compliance. But it may be so restrictive that you can't share data for legitimate purposes. You end up suppressing so much information that the dataset loses analytical value, or you abandon anonymization entirely and keep everything as personal data under GDPR. The Guidelines note that simplified assessments "may be overly restrictive." You've sacrificed practical utility for theoretical safety.
The fix: Choose your methodology deliberately based on your use case. If you're sharing data with a narrow set of known entities under controlled conditions, a contextual approach may be appropriate. Document the relevant entities, their means, and the likelihood of re-identification. If you're publishing data openly or can't predict who will access it, the simplified approach makes sense. The EDPB allows you to combine both approaches: start contextual, then validate with simplified testing. Don't pick simplified by default just because it sounds more conservative.
Prevention Checklist
Before claiming data is anonymous under GDPR:
- Identify every entity that will access, control, or process the dataset
- For each entity, document: auxiliary data they control, specialist services they could access, legal avenues to obtain more data
- Distinguish legal prohibitions from contractual restrictions in your risk assessment
- Research readily available commercial re-identification services in your domain
- Test all three EDPB criteria: record isolation, linkage prevention, and inference protection
- Choose contextual or simplified approach based on your sharing model, not default conservatism
- If anonymization serves a different purpose than original collection, document your GDPR legal basis for the anonymization process itself
- Schedule reassessment when: new entities access the data, auxiliary datasets become available, or specialist services emerge
The EDPB's Guidelines are open for public consultation until October 30, 2026. If your organization processes data that you currently treat as anonymous, now is the time to test your assumptions against this framework.
