The EDPB recently released draft Guidelines 02/2026 on Anonymisation for public consultation. Since then, I've been hearing the same questions from DPOs and privacy leads trying to understand the impact on their current practices. These are not theoretical concerns; they're practical questions like, "Do we need to redo our entire research dataset release process?" that arise when regulatory guidance shifts.
The Guidelines introduce a "perspective-dependent" approach to anonymization, which has sparked many operational questions. Here's what teams are asking and what you need to know.
Q: "We share pseudonymized datasets with our processor for analytics. Are we supposed to treat those as personal data now?"
Yes, and you probably should have been doing so already.
The Guidelines clarify that if data is considered personal data from the controller's perspective, it remains personal data for the processor. You can't selectively anonymize data based on who's holding it. This means your processor contracts need to reflect Article 28 obligations for any dataset you consider personal. If you've been treating pseudonymized datasets as "anonymous enough" once they leave your environment, this practice won't hold under these Guidelines. The processor's limited view of the data doesn't change its classification.
This affects how you draft processing agreements. If you're sharing data that's pseudonymized but not truly anonymous by your assessment, you need a lawful basis for sharing, appropriate technical and organizational measures in the contract, and clarity about what the processor can and cannot do with it.
Q: "How do we figure out which 'relevant entities' to consider when we're doing an anonymization assessment?"
The EDPB provides five factors to consider: access, control, sharing arrangements, party relationships, and whether one party acts on behalf of another.
Start with a data flow map. Who can access this dataset now or in foreseeable circumstances? This includes not just direct access but also entities you might share it with under existing agreements or legal obligations. If you're publishing a dataset openly, "relevant entities" expands dramatically. If it's internal to a controlled research environment, the circle is tighter.
The Guidelines emphasize looking beyond your organization. If you're required by law to provide data to a supervisory authority or statistical office, those entities are relevant. If you're sharing data with academic researchers under agreements, they're relevant. If a third party could compel access through legal processes, consider that too.
Don't rely solely on contractual restrictions. The EDPB warns that contractual terms aren't equivalent to legal prohibitions. A clause saying "you may not attempt re-identification" doesn't make the data anonymous; it just creates a breach-of-contract risk if someone tries.
Q: "Should we use the contextual approach or the simplified approach? What's the actual difference in practice?"
The contextual approach asks if specific entities with access to the data can re-identify individuals using means reasonably available to them. The simplified approach asks if anyone, given sufficient motivation and resources, could re-identify individuals from the data.
The contextual approach considers real-world constraints. If you're sharing aggregate statistics with a marketing team that has no access to identifying data and no reasonable way to acquire it, you might conclude the data is anonymous from their perspective. The simplified approach ignores those constraints and assesses whether re-identification is theoretically possible.
Here's the trade-off: contextual assessments are more flexible but carry higher risk. The EDPB warns they may lead to false conclusions that data is anonymous. If your assessment is wrong because you underestimated someone's re-identification capabilities, you've been processing personal data without appropriate safeguards.
The simplified approach is more defensive. It pushes you toward stronger anonymization techniques but may also rule out legitimate uses of data that pose minimal privacy risk. For many organizations, a hybrid makes sense: use simplified analysis as your baseline, then apply contextual factors only where you can document specific, verifiable limitations on re-identification means.
Q: "What counts as 'means reasonably likely to be used' for re-identification?"
Recital 26 GDPR provides the framework: consider time, cost, technology available, and technological developments. The Guidelines add nuance.
Means that are illegal, impossible, or disproportionately expensive may fall outside "reasonably likely." But context matters. If you're assessing risk from a motivated attacker like a cybercriminal, legal prohibitions don't constrain their behavior. If you're assessing risk from a regulated research institution, legal prohibitions carry more weight.
The Guidelines highlight two scenarios that expand what's "reasonably likely": where specialist re-identification services are commercially available, and where an entity has legal rights to access additional data that would enable linkage. If someone can pay a data broker for supplemental information that breaks your anonymization, that's a reasonable means. If a government agency can compel disclosure of auxiliary data through legal process, that's reasonable too.
Document your reasoning. When you conclude that certain re-identification means aren't reasonably likely, record why: the legal barriers, the technical impossibility, the cost analysis. You'll need that documentation if a supervisory authority questions your assessment later.
Q: "We're using k-anonymity with k=5. Does that meet the three criteria the EDPB describes?"
Not automatically. The three criteria (record isolation, linkage, and inference) aren't satisfied by hitting a specific k-value.
K-anonymity addresses record isolation by ensuring each combination of quasi-identifiers appears at least k times. That's useful, but it doesn't prevent linkage to external datasets or inference attacks. If someone can link your k-anonymous dataset to another source using attributes you didn't suppress, your anonymization fails. If your generalization creates groups where 80% share a sensitive attribute, you've got an inference problem even if k=100.
The Guidelines push you to think beyond single-technique solutions. You need to assess whether your anonymization prevents all three risks: isolating a unique record, linking across datasets, and inferring sensitive information about individuals. That typically requires combining techniques (generalization plus noise addition, or aggregation plus suppression) and testing against realistic attack scenarios.
Also remember: you need a lawful basis under Article 6 (and an Article 9 derogation if applicable) to perform the anonymization itself if it serves a different purpose than your original processing. Don't skip that step.
Q: "If we get this wrong and data we thought was anonymous turns out to be personal, what's our exposure?"
You've been processing personal data without the safeguards required by the GDPR. That means potential violations of Articles 5 (principles), 6 (lawful basis), 13/14 (transparency obligations), 25 (data protection by design), and 32 (security).
The immediate operational impact: you need to bring that processing into compliance, which may mean stopping it entirely until you can establish a lawful basis and implement appropriate technical and organizational measures. If you've shared the data with third parties under the assumption it was anonymous, those become processor relationships or controller-to-controller transfers that require proper agreements and safeguards.
The regulatory risk depends on scope and harm. A supervisory authority will look at how much data you misclassified, how sensitive it is, how widely you shared it, and whether individuals suffered harm. They'll also assess whether your anonymization assessment was reasonable given the state of the art when you made it.
This is why documentation matters. If you can show you conducted a thorough, well-reasoned assessment using recognized techniques and expert input, you're in a better position than if you simply assumed pseudonymization was enough.
Where to Go From Here
The Guidelines are open for public consultation until October 30, 2026. If your organization has specific use cases that these Guidelines don't address clearly, submit comments. The EDPB will finalize the guidance based on stakeholder input, and this is your window to shape it.
In the meantime, audit your current anonymization practices against the perspective-dependent framework. Identify datasets you've classified as anonymous and work through the relevant entities analysis. Document your reasoning. And if you're sharing data with processors under the assumption that it's anonymous from their perspective, revisit those arrangements now.
