EDPB's New Anonymisation Guidelines: The Three-Criteria Test Your 'Anonymised' Dataset Has to Pass

On 7 July 2026, the European Data Protection Board adopted Guidelines 02/2026 on Anonymisation, Version 1.0, open for public consultation until 30 October 2026, 23:59 CET. This is the first update to the EU's guidance on anonymisation in twelve years — the previous word on the subject was the Article 29 Working Party's Opinion 05/2014 on Anonymisation Techniques (WP216), adopted 10 April 2014, back when "big data" was still the scary buzzword and nobody was training language models on scraped web text.

If your product strips names and emails out of a dataset, generalises birthdates into age brackets, or hashes user IDs before shipping data to an analytics vendor or an AI training pipeline — and then calls the result "anonymised" — this document is what a supervisory authority will actually check your reasoning against. The guidelines matter because they don't just restate the old singling-out/linkability/inference triad from 2014; they rebuild the whole legal framework around a Court of Justice ruling from last year that changes whose perspective counts when you ask "is this still personal data?"

This post walks through the framework paragraph by paragraph, with a practical checklist at the end for anyone running an anonymisation pipeline today.

Why the 2014 Opinion Needed Replacing

WP29's 2014 opinion already gave the field its three canonical criteria — singling out, linkability, inference — and warned, correctly, that most "anonymisation" techniques in practice only pseudonymise. But the guidelines explain why an update was overdue (paragraph 2): "there have been major changes in the legal, privacy, engineering and technological landscapes. The development of case law from the Court of Justice of the European Union (CJEU), the establishment of EU-wide data spaces, and developments in both AI and technology in general, amongst many other things, have raised a need to update that Opinion and refine the criteria presented there."

The trigger case is C-413/23 P, EDPS v SRB, decided by the CJEU on 4 September 2025. The case arose out of the 2017 resolution of Banco Popular Español: the Single Resolution Board (SRB) collected comments from affected shareholders and creditors, replaced their names with alphanumeric codes before sending the comments to Deloitte for review, and kept the key to re-link codes to identities itself. The European Data Protection Supervisor said the pseudonymised comments were still personal data. The General Court disagreed, reasoning that Deloitte itself could not re-identify anyone. The CJEU overturned that — and in doing so endorsed what the new guidelines call the "relative approach" to identifiability: the same dataset can be personal data for one entity and anonymous for another, depending on what that specific entity can realistically do with it (guidelines paragraph 4, citing EDPS v SRB as the reason perspective-dependent terminology is needed throughout the document).

That single holding is why these guidelines exist. If anonymity depends on who's holding the data, you can no longer assess a dataset once and call it done — you have to define whose perspective you're testing.

Good news if you're worried this creates twelve years of new grey area for you specifically: paragraph 2, footnote 3 explicitly says a controller that already assessed a dataset as anonymous under the 2014 opinion is not expected to redo that assessment now. It is only "good practice" to periodically reassess — not a retroactive compliance obligation.

The Core Test: Two Questions, Asked From Somebody's Perspective

The whole framework reduces to two questions (paragraph 6):

1. Does the information "relate" to a natural person?
2. If so, is that natural person "identified or identifiable"?

If the answer to either is "no," the data is anonymous — but, per the relative approach above, the answer can differ by who's asking. Paragraph 7 gives the concrete example: information might unambiguously relate to an individual, but only one organisation can actually identify them. For that organisation it's personal data. For everyone else, it's anonymous — "outside of particular circumstances."

This is why the guidelines spend section 2.2 on identifying the applicable perspective(s) before anything else. You don't ask "is this dataset anonymous" in the abstract — you ask "is this dataset anonymous for the parties who will actually touch it." If you're anonymising data purely for internal use by a single team with no onward sharing, there's one perspective to test. If you're anonymising data to hand to a partner, a research institute, or the public, you need to test the perspective of whoever receives it (paragraph 12).

Two worked examples from the guidelines are worth internalising for anyone building a data-sharing pipeline:

• Processor perspective inherits from the controller (paragraph 15, Example 3). An e-commerce retailer sends customer record excerpts to a third-party analytics agency. The retailer can re-identify the customers, so the data is personal for the agency too — even though the agency itself might not be able to re-identify anyone — because the agency is processing on the retailer's behalf and instructions. You don't get to outsource re-identification capability to a processor and call the transferred copy anonymous.
• An independent recipient gets its own perspective (paragraph 15, Example 4). A hospital sends de-identified patient record excerpts to an independent research institute that will never return the data and sets its own means and purposes. Since the institute acts independently rather than as a processor, whether the data is personal for the institute is assessed from the institute's own perspective, separately from the hospital's.

"Means Reasonably Likely to Be Used" — The Test for "Identifiable"

Once you've fixed the relevant perspective(s), the actual identifiability test hinges on Recital 26 GDPR's phrase "means reasonably likely to be used" — a phrase the guidelines spend section 2.4.2 unpacking because it does almost all the work. Recital 26 states plainly that anonymous information is "information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable," and Article 4(1) GDPR defines an identifiable person as one who "can be identified, directly or indirectly, by reference to an identifier."

Rather than listing a closed set of acceptable "means," the CJEU (and now the EDPB) defines the concept negatively — by what stops a means from being "reasonably likely": the guidelines note (paragraph 26, citing C-413/23 P EDPS v SRB, paras 82–83) that means are not reasonably likely to be used if identification would in reality be insignificant because it's impossible, because it would involve disproportionate effort in time, cost and labour, or because of a legal prohibition. Notably, the guidelines caution against one popular developer shortcut: "lack of motivation" of a hypothetical attacker is not an acceptable factor (paragraph 31) — you can't argue re-identification is unlikely just because nobody would bother; motivation is too hard to assess objectively and can change.

The objective factors that do count, per paragraph 29, are:

• properties of the data itself (aggregation level, uniqueness, accuracy, precision),
• the context of release/processing, including whether access is restricted,
• what additional information exists and how likely it is to be obtainable,
• the cost and time an entity would need to get that additional information, and
• available technology at the time, plus reasonably foreseeable technological developments.

Two practical points from this section matter directly for SaaS teams:

Contractual promises are not a substitute for technical controls (paragraph 34). A prohibition set out in a contract — even a legally binding one — "should not be treated as a prohibition by law." It can complement technical measures, but contracts "can be subject to revision, or may even be disregarded entirely by the parties." If your anonymisation strategy for a data-sharing deal relies on a DPA clause saying "the recipient shall not attempt to re-identify," that clause helps, but it does not make the underlying data anonymous on its own.

A legal prohibition on re-identification only excludes a "means" if it's actually enforced (paragraphs 32–33). The guidelines allow you to discount illegal re-identification methods from your risk assessment — but only where the rule of law effectively restrains the relevant actors. If there's evidence the prohibition "is not effectively monitored, enforced and sufficiently dissuasive," or that gains from breaking it outweigh the costs, or that it's been circumvented before in comparable situations, you cannot simply wave the risk away by pointing at a statute.

The Three Criteria: No Record Isolation, No Linkage, No Inference

Section 3 is the operational core — a technical test applicable regardless of anonymisation method, structured as three criteria that a dataset must pass all of to be safely considered anonymous (paragraph 46). Fail any one, and further analysis is required rather than an automatic "personal data" verdict.

1. No Record Isolation

Met if the data does not contain a unique combination of attribute values that relate to a single individual (paragraph 55). The larger a record and the more attributes it carries, the higher the chance it's unique. The guidelines' worked example (paragraph 57, Example 10) is a five-row patient table with sex, date of birth, postcode, and disease — every row turns out unique, so the criterion fails immediately. Aggregate data will usually satisfy this criterion by construction, since it describes groups rather than individual rows (paragraph 58).

2. No Linkage

Met if no record in the given data could be linked, with certainty or high likelihood, to a record in a different dataset that relates to the same individual (paragraph 60). This is the criterion that catches the classic "we removed direct identifiers but kept quasi-identifiers" mistake. Example 12 (paragraph 63) generalises date of birth to birth year and postcode to its first two digits — the No Record Isolation criterion now passes, since no row is unique on its own. But two rows for people born in 1946 in postcode-prefix 54 both list "sclerosis." If any other dataset (a public registry, a data broker's product, information a colleague happens to know) can be matched on sex + birth year + generalised postcode, the health condition leaks anyway — the No Linkage criterion is violated even though no single record was ever isolated. In practice, data that passes No Record Isolation will often also pass No Linkage, but the guidelines are explicit that the two must still be assessed separately, since generalisation and noise can still leave a dataset linkable (paragraphs 63–64).

3. No Inference

Met if no specific and meaningful inference can be drawn from the given data, whether from record-level or aggregate data, including inferences about individuals who were never even in the original dataset (paragraph 67). An inference is specific if it relates to one identified/identifiable person; it's meaningful if it could actually affect that person's rights and interests, relies on the given data, and — crucially — "could not be obtained from general knowledge or from data about the population at large." Paragraph 71 offers three ways to demonstrate whether an inference is meaningful, the most practical being to re-run the inference against a modified version of the dataset with the individual's own record removed: if the inference still comes out the same, it was drawn from population-level patterns, not from that person's own data, and the criterion survives.

The distinction between a merely "specific" inference and a "meaningful" one is illustrated cleanly by Example 13 (paragraph 71–72): the statement "green is a popular colour" is anonymous. Combined with a fact about who likes what, you might infer "Connor likes green" — that's specific (it names Connor) but not meaningful, because it was drawn from general population data, not from Connor's own record. Compare that to a bank's historical loan dataset (Example 14) showing a combination of attributes predicts default risk, then applying that model to score a brand-new applicant who was never in the training data. Even though the applicant's record is new, this is a membership-inference-adjacent case worth flagging for any team fine-tuning models on customer data: if a trained model can reproduce a specific, meaningful fact about someone whose data went into training — including someone who can be shown to have been "in the room" via a membership-inference attack (Example 18, paragraph 79) — that data may still fail the No Inference criterion even after aggregation, and the guidelines explicitly reference this dynamic in the context of "advanced de-aggregation techniques, including attacks which can extract data from supposedly-anonymous AI models" (paragraph 77, footnote 45, citing EDPB Opinion 28/2024 on AI models).

Contextual vs. Simplified Approach — Pick One Deliberately

The guidelines offer two ways to apply these three criteria (paragraph 45, section 3.2):

• Contextual approach — assess each relevant entity's actual, differentiated means and access. More accurate to the legal standard, but complex, and risks false positives if you're unaware of some entity's real capabilities (paragraph 47).
• Simplified approach — ignore differences between entities and assume the strongest plausible means apply to everyone. Not an alternative legal standard, but a deliberate way to shift risk from false positives toward false negatives — in the EDPB's words, it "provides a more cautious level of protection than is strictly necessary" while guaranteeing the legal minimum is always met (paragraph 48).

For most small teams without a dedicated privacy engineering function, the pragmatic sequencing the guidelines themselves recommend (paragraph 49) is: start with the simplified approach as a cheap first pass — if a dataset is clearly anonymous under the harshest assumptions, you're done. If the simplified approach flags a problem, only then invest in the more expensive contextual analysis to see whether the specific entities who'll actually hold the data really have the means in question. This order minimises wasted effort while defaulting to the safer answer whenever you don't have budget to go deeper.

One access-control point that changes the calculus either way: encryption alone does not equal anonymisation (paragraph 91). It can restrict access to an intelligible form of the data and support anonymisation, but you still have to ask whether entities with access to the encrypted data could decrypt it through means reasonably likely to be used — including future cryptanalysis — even without holding today's key.

The Legal-Basis Trap Almost Everyone Misses

This is the part of the guidelines that catches SaaS teams off guard: the act of anonymising personal data is itself processing of personal data, and needs its own GDPR legal basis (paragraph 38). If your dataset contains special-category data under Article 9 GDPR, the anonymisation step needs an Article 9(2) exemption too — and the guidelines specify that the legal basis and exemption for the anonymisation step "should be presumed to coincide with the legal basis and exemption of the preceding processing activity" as long as they share the same purpose. You cannot treat "we're just deleting/generalising fields before we ship this to the AI team" as a compliance no-op that needs no legal basis of its own.

There's a silver lining buried in the same section: immediate anonymisation combined with immediate deletion of the original data can actually strengthen your position if you're relying on legitimate interest under Article 6(1)(f) for the preceding processing — the guidelines note this limits the overall impact on data subjects and can be "a positive factor in the legitimate interest balancing test" (paragraph 39).

Two more obligations worth building into your pipeline documentation now, before an authority asks for it:

• Transparency (paragraph 40): don't describe data as "anonymous," "de-identified," or "de-personalised" under Articles 5(1)(a) and 12–15 GDPR if individuals could still, in reality, be identified. The guidelines call out exactly this kind of ambiguous or misleading labelling as a compliance risk in itself.
• Documentation (paragraph 41): controllers should keep records of the anonymisation process — including how the anonymity claim was tested — and retain that documentation after the process completes. This is what demonstrates both GDPR compliance of the anonymisation activity itself and the actual effectiveness of the result, and it is exactly what a supervisory authority will ask to see first if a re-identification incident ever surfaces.

Finally, anonymisation is not a one-time stamp. Paragraph 35 is blunt about this: "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," and if that likelihood stops being insignificant, previously anonymous data becomes personal data again, with full accountability attaching from that point. A security incident affecting confidentiality assumptions your anonymity claim relied on can trigger the same reassessment — and potentially an Article 33/34 breach-notification analysis (paragraph 42).

A Practical Checklist for Your Anonymisation Pipeline

1. Name the perspective(s) you're testing. Internal-only use, a named processor, or an independent third party each require a different analysis — write down which one applies before you run any test.
2. Map the data first (paragraph 50–51). Catch the obvious cases — direct identifiers, easily-reversed pseudonyms — before running the full three-criteria framework. Don't skip straight to statistics on a dataset that still has an email column.
3. Run No Record Isolation. Check every record/row for a unique combination of attributes. If everything is unique, you likely need more generalisation or suppression before proceeding.
4. Run No Linkage against every dataset your recipients could plausibly access — including public registries, data-broker products, and anything colleagues or partners might already hold. Generalisation that defeats No Record Isolation frequently still fails here.
5. Run No Inference, including a membership-inference check for anything feeding a trained model. Re-test the inference against a version of the data with the individual's record excluded — if the result doesn't change, the inference is population-level, not personal.
6. Choose simplified-first, contextual-if-flagged, unless you already have a dedicated privacy engineering budget that makes contextual-from-the-start worthwhile.
7. Confirm the anonymisation step itself has a legal basis (and an Article 9(2) exemption if special-category data is involved) before you run the pipeline, not after.
8. Write it down. Keep documentation of the test results and methodology, and don't label the output "anonymous" anywhere in your product or docs unless it actually passed all three criteria for every relevant perspective.
9. Put a reassessment trigger on the calendar — new re-identification techniques, new datasets your recipients could access, or a security incident should all trigger a re-run, not just a one-time sign-off.

What Happens Next

Guidelines 02/2026 are Version 1.0, open for public consultation until 30 October 2026, 23:59 CET — comments go through the EDPB's online form and are published, though commenters can request their personal details be withheld. The core three-criteria structure and the relative-approach framing are both direct consequences of a final CJEU judgment (EDPS v SRB), so unlike some EDPB drafts, this reasoning is very unlikely to reverse before finalisation — treat it as the operative reading today rather than something to shelve until the consultation closes.

If your product anonymises or pseudonymises data anywhere in its pipeline — training-data preparation, analytics exports, data-sharing agreements with partners — this is worth a real read against your own data flows before an EU supervisory authority asks you to defend the word "anonymous" on your own terms.