Your Privacy Policy says "anonymised". The EDPB just asked: for whom?

Somewhere in your Privacy Policy there is a sentence saying you anonymise something. Usage data, support logs, model evaluation sets, take your pick. I have written that sentence myself, and I never once wrote down who the data was supposed to be anonymous to. In July 2026 the European Data Protection Board adopted draft guidelines that make that omission the whole question.

What did the EDPB actually publish?

Guidelines 02/2026 on Anonymisation, version 1.0 1. The document dates its own adoption to 7 July 2026; the Board's plenary announcement is dated the following day, and the consultation window runs from 8 July 23, so pick your day accordingly. They are a draft, open until 30 October 2026 at 23:59 CET 2, and as I write this at the end of July none of it is settled. They update the Article 29 Working Party's Opinion 05/2014 on anonymisation techniques, which the Board says needs revisiting after "major changes in the legal, privacy, engineering and technological landscapes" 1. They arrived alongside a second draft, Guidelines 03/2026, covering the scraping of personal data in the context of generative AI, which is out for consultation on the same deadline 3.

Two things carry the weight.

The first is a test. Three criteria: No Record Isolation, No Linkage and No Inference. Pass all three and the data "can be safely considered anonymous" 1. Violate one and you are not automatically holding personal data, you just owe more analysis.

The second is the part most teams have no process for at all. Anonymity is assessed per entity. "Information may be anonymous for some entities, but not for others" 1. That idea is not new. The Board traces it through Breyer in 2016 and, most recently, the Court of Justice's judgment of 4 September 2025 in EDPS v SRB 14. What is new is that the Board has built an operating framework on top of it, and that framework asks a question your legal documents do not answer.

Anonymous for whom?

The guidelines put it flatly. "The basic question is: for whom is the data intended to be anonymous?" 1

You get two ways to answer it. The contextual approach assesses each relevant entity's actual capabilities separately. The simplified approach ignores the differences between entities and tests as though everyone were equally capable. The Board is careful that the simplified version "is not an alternative legal standard", it is a voluntary trade of false positives for false negatives: you may end up treating anonymous data as personal because you overestimated what someone could do 1. Both are legitimate. Most teams I know are doing a third thing, which is asserting the conclusion with no perspective attached to it at all.

The cast of entities is also wider than the recipient you had in mind when you built the pipeline. The Board's list is expressly non-exhaustive, and alongside the controller and any receiving entities it names rogue employees, the individual's partners, friends, colleagues and neighbours, investigative journalists, domestic law enforcement and intelligence agencies, foreign intelligence agencies, unethical companies, and cybercriminals 1. Nothing in the GDPR limits the analysis to well-behaved parties.

Can our vendor say the data is anonymous to them?

This is the claim I would go and check first, because a lot of vendor security pages lean on it.

If they process on your behalf, no. Paragraph 15 is explicit: where an entity processes information on behalf of a controller for whom the information is personal data, "that information should also be considered personal data for the processing entity", which makes them a processor carrying processor obligations 1. The reasoning is that the processor concept exists precisely to stop controllers outsourcing their way out of the GDPR's protections.

So "we only ever see hashed identifiers, so it is anonymous on our side" is not available to your analytics processor or your support tooling. Their perspective is not their own. It is yours.

The fork to watch is the one your vendor will reach for next. The applicable perspective "depends on whether they themselves determine the means and purposes of the processing" 1, so a vendor claiming to be an independent controller for that processing, which is the usual framing for product analytics, benchmarking and model improvement, gets its own perspective back: where data is anonymised for independent use by whoever receives it, anonymity is assessed from the recipient's side 1. That is a contract question before it is a technical one. Read what your DPA actually says about the purposes your vendor pursues with the data, because that clause, not the hashing, decides whose perspective applies.

Does anonymising downstream switch off the recipient disclosure?

Also no, and this one lands straight on the Privacy Policy.

The Board walks through EDPS v SRB as a worked example 1. The transferring body argued that because the data was anonymous from the receiving entity's perspective, sharing it was not a transfer of personal data, so the duty to tell people about recipients did not apply. The Court rejected that. The obligation has to be fulfilled at the time the data is collected, and identifiability is therefore assessed from the controller's perspective at that moment 4. If it was personal data to you when you collected it, the disclosure duty is engaged, whatever it looks like at the far end of the pipe.

Two caveats worth having straight, because both cut against overreading this. The case was decided under Article 15(1)(d) of Regulation (EU) 2018/1725, the regulation that binds the EU institutions rather than you; the GDPR's mirror provision is Article 13(1)(e), and it is the EDPB that reads the reasoning across 1. And that provision asks for "the recipients or categories of recipients of the personal data, if any" 5, so a category disclosure discharges it. Naming names is a choice, not an obligation.

What you do not get is the third option. A line reading "we share only aggregated and anonymised data with our analytics provider" is not a disclosure of that recipient, it is an argument for why you did not need to make one, and this is the argument the Court rejected.

What makes an anonymity claim expire?

Here is the part that matters if you ship continuously, because none of these are legal events. They are product events.

Time and technique. "The likelihood of re-identification typically increases over time due to advances in the technology and techniques used for re-identification, as well as the increased availability of additional information." If it rises to a level that is no longer insignificant, the previously anonymous data "should again be considered personal" and you are accountable for processing it 1. The factors you are meant to weigh explicitly include "reasonably foreseeable technological developments" 1.

A new join. The No Inference criterion is assessed against the given data "together with any external information that might be used in conjunction with the given data to infer information" 1, and the objective factors include "any additional information that would allow for the identification of individuals, and how likely it is that such information can be obtained" 1. Land a second dataset next to the first one and you have changed the input to a test you ran last year.

A partial pass. Where a technique only makes identification insignificant for some of the individuals in a set, the whole dataset "should be treated as containing personal data" in any situation where the parts are not handled separately 1.

A breach. "In some cases, a security incident may lead to a reassessment of anonymity", particularly where the assessment relied on something staying confidential. The entity then has to work out its role and whether Articles 33 and 34 apply 1. An incident can convert a dataset you had written off as out of scope back into personal data, and the reassessment is the moment you become aware, which is where the Article 33 clock starts.

Not one of those opens a ticket by itself. That is the problem.

Is our DPA clause not enough?

The standard move is a contractual ban on re-identification. Paragraph 34 is blunt about how much that carries: a prohibition set out in a contract, even one legally binding on its parties, "should not be treated as a prohibition by law". Contractual terms "should only be used to complement technical measures", and the contractual measures themselves need to be "reliable, verifiable and enforceable", bearing in mind that they can be revised, or disregarded entirely by the parties 1.

That distinction is doing real work, not being pedantic. The Court has accepted that a genuine legal prohibition can make identification unlikely enough to disregard 4, and the Board keeps that, while adding that the assumption people follow the law can be rebutted on evidence: a prohibition that is not monitored or enforced, gains that outweigh the risk of breaking it, comparable breaches in the past 1. A clause in your own DPA never had that standing to begin with.

The Board also cautions against leaning on lack of motivation, since motivation is hard to assess objectively, changes over time, and does not predict identification that happens by accident or negligence 1.

Do we have to go back and redo everything?

No, and I want to be exact about this, because I have already seen it overstated.

A footnote in the introduction says it directly: a controller that assessed a dataset as anonymous in accordance with Opinion 05/2014, before these guidelines were published, "is not expected to conduct a new assessment". Periodic reassessment is good practice, not a retroactive obligation 1.

So there is no audit of your back catalogue. What there is, is a new framework waiting for the next time you touch the thing. And the next time you touch the thing is a release, not a legal review.

So what would I actually do about it?

Three moves, none of which need a new process.

Write the perspective down. For every place your documents say anonymised, aggregated or de-identified, record who the data is anonymous to, the date you concluded that, and what side information you assumed was unavailable. Three lines. It converts an unfalsifiable sentence into a claim you can re-run.

Attach the re-run to product change, not to the calendar. A quarterly review will not catch the sprint that added the join. The events actually worth wiring are: a new recipient or subprocessor, a new dataset landing beside an existing one, a schema change that adds dimensions to a record, and any incident touching the confidential thing your assessment leaned on.

Keep the paperwork the guidelines assume you have. Anonymisation is itself processing of personal data, so it needs an Article 6 legal basis, plus an Article 9(2) exemption where special categories are involved 15. That is lighter than it sounds: where anonymisation is part of the same processing activity and pursues the same purposes, the Board says the basis "should be presumed to coincide" with the one you already had 1. The case that actually needs thinking about is the other one, where you spin anonymisation out as its own activity or point it at a new purpose. Then document the process and the testing of the result, and retain that documentation afterwards 1. And do not describe data as "anonymous", "de-identified" or "de-personalised" if individuals are actually still identifiable 1, which the Board frames as a transparency problem under Articles 5(1)(a) and 12 to 15, on top of whatever else it is.

If you would rather argue with the framework than live with it, the consultation is open until 30 October 2026 2. A draft is the one moment where the text is still moving, so if you are reading this after that date, check whether version 2 has landed before you quote any paragraph number above.