The EDPB's July 2026 draft Guidelines on Anonymisation aim to provide a structured framework for assessing whether data is truly anonymous. However, many teams misinterpret the guidance, treating anonymization as a simple switch rather than a complex risk assessment. They assume processors are treated differently, which the Guidelines explicitly reject, and base compliance strategies on incorrect assumptions.
These myths persist because anonymization is both technical and regulatory, creating challenges for legal and engineering teams. The Guidelines formalize this tension. Here's what the EDPB actually said, without the misconceptions.
Myth 1: "If we anonymize data, GDPR doesn't apply anymore"
Reality: Anonymization requires a legal basis under GDPR.
The EDPB clarifies that anonymizing data, transforming identifiable information into anonymous information, is a processing operation. If you're anonymizing data for a different purpose than originally collected, you need a separate legal basis under Article 6, and an Article 9 derogation if dealing with special categories of data.
Your anonymization process isn't an escape from GDPR. It's a processing activity you must document, justify, and potentially include in your Article 30 records. You can't decide to anonymize customer data for research without checking if consent, legitimate interests, or another legal basis covers that transformation.
Your data governance team should review anonymization projects like any new processing activity. What's the purpose? What's the legal basis? What's the retention period for identifiable data during the anonymization process?
Myth 2: "Anonymization is the same for controllers and processors"
Reality: Processors follow the controller's view on personal data.
The Guidelines clarify a key question: can data be personal for a controller but anonymous for a processor? The EDPB's answer is clear. If you process data on behalf of another entity, you assess anonymity from the controller's perspective. If it's personal data for the controller, it's personal data for you.
This closes a potential loophole. You can't accept a dataset from a client, declare it anonymous from your limited view, and process it outside GDPR. The controlling entity's means of identification, not just yours, determine if the data remains personal.
For processors, your data processing agreements need to reflect the controller's assessment of personal data. You can't independently declare a dataset anonymous just because you lack certain information the controller holds.
Myth 3: "Contractual restrictions on re-identification make data anonymous"
Reality: Contracts create obligations, not technical barriers to re-identification.
The Guidelines differentiate between legal prohibitions and contractual restrictions. A law criminalizing re-identification might factor into the "reasonably likely means" test under Recital 26 GDPR. A contract clause forbidding re-identification does not.
Contracts depend on compliance, and the EDPB notes that certain actors, like cybercriminals, won't honor contractual terms. Even legitimate parties might breach contracts, and breach doesn't make re-identification impossible.
When sharing data with third parties under agreements prohibiting linking data back to individuals, those agreements reduce legal risk and create enforcement options if violated. But they don't make the data anonymous. You still need technical controls to make re-identification difficult or impossible.
Myth 4: "The contextual approach is easier than the simplified approach"
Reality: The contextual approach trades rigor for risk.
The Guidelines describe two assessment methodologies. The simplified approach asks if anyone could re-identify individuals from the dataset using any reasonably available means. The contextual approach narrows the question: could the relevant entities, those with actual access or control, re-identify individuals, given their specific means and motivations?
Teams assume "contextual" is the practical option. But the EDPB warns that contextual assessments may falsely conclude a dataset is anonymous. You might overlook a re-identification path because you underestimated an entity's capabilities or didn't account for specialist third-party services.
The simplified approach sets a higher bar but offers more defensible outcomes. If you can demonstrate that no one could re-identify individuals, even with specialist tools and auxiliary datasets, you're on firmer ground.
Choose the contextual approach when you have genuine technical controls and limited data exposure. Don't choose it because it feels easier.
Myth 5: "Meeting the three criteria guarantees anonymity"
Reality: The three criteria are necessary but not always sufficient.
The Guidelines retain the familiar framework: record isolation (no unique attribute combinations), linkage (records can't be matched across datasets), and inference (no specific conclusions about individuals). If your dataset fails any of these tests, it's not anonymous.
But passing all three doesn't automatically make it anonymous. The EDPB notes that even if the three criteria are met, you may need additional analysis, particularly under the contextual approach. You're still assessing whether relevant entities could use reasonably likely means to re-identify individuals.
Consider a dataset that passes all three criteria in isolation but could be linked to publicly available information through quasi-identifiers. The three-criteria test might give you confidence, but the contextual analysis could reveal re-identification risks you hadn't considered.
Treat the three criteria as a structured starting point, not a checklist that guarantees compliance.
Myth 6: "The Guidelines clarify when data is anonymous"
Reality: The Guidelines clarify how to assess anonymity, and why it's harder than you think.
The EDPB didn't publish a safe harbor for anonymization techniques. They published a framework for evaluating whether your technique works in your specific context. That framework acknowledges that anonymization depends on who's assessing the data, what means they have available, and whether those means are reasonably likely to be used.
This is challenging for teams wanting clear rules. You can't point to k-anonymity with k=5 and declare victory. You need to ask: who are the relevant entities? What auxiliary data could they access? Are specialist re-identification services available? Would legal prohibitions deter re-identification in this context?
The Guidelines formalize what privacy engineers have known: anonymization is a risk management exercise, not a compliance checkbox.
What to do instead
Start by identifying the relevant entities for each dataset. Who has access? Who controls it? Who might receive it? Then assess the means available to each entity, including auxiliary datasets, specialist services, and legal avenues to access additional information.
Document your anonymization methodology and the reasoning behind your contextual or simplified assessment. If you're using the contextual approach, be explicit about why you've excluded certain re-identification scenarios. If you're using the simplified approach, show how you've accounted for worst-case re-identification attempts.
Participate in the consultation before it closes on October 30, 2026. The Guidelines are still in draft form. If your organization has encountered edge cases or practical challenges that the current framework doesn't address, now is the time to raise them.
The EDPB has given you a structured way to think about anonymization. Use it to challenge your assumptions, not to confirm them.
