Key Takeaways
- The EDPB adopted Guidelines 02/2026 on Anonymisation on 7 July 2026, open for public consultation until 30 October 2026 — replacing the standard first set in 2014 and raising the bar for what counts as "anonymous."
- Anonymity is relative, not absolute: under the CJEU's EDPS v SRB ruling of 4 September 2025, the same dataset can be personal data in your hands and anonymous in someone else's — so "is this anonymous?" has no single answer.
- Data is only anonymous if it passes three criteria — No Record Isolation, No Linkage, No Inference. Fail any one and it stays personal data, fully inside the GDPR.
- Deleting the customer's name is not anonymisation: in 2019 the Danish DPA proposed a DKK 1.2 million (about €160,700) fine against taxi firm Taxa 4×35 for data that was still linkable by phone number.
- Anonymisation is itself processing that needs an Article 6 legal basis — and you may not label data "anonymous", "de-identified" or "de-personalised" if individuals are still identifiable.
Introduction
Somewhere in your analytics stack is a dataset labelled "anonymised customer data." Maybe it feeds a recommendation model, maybe it powers a loyalty dashboard, maybe it is the export you hand an agency each quarter. You treat it as outside the GDPR: no consent, no retention clock, no access requests.
On 7 July 2026, the European Data Protection Board (EDPB) published new guidance that may quietly move that dataset back inside the regulation. Guidelines 02/2026 on Anonymisation replace a standard first set in 2014 with a sharper, three-part test — and a good deal of eCommerce data that gets called "anonymous" does not pass it. This guide walks through the new test and shows where your storefront data actually stands.
Is anonymised data personal data under GDPR?
Truly anonymous data falls outside the GDPR entirely. But the EDPB's Guidelines 02/2026, adopted 7 July 2026, set a high bar: data is anonymous only if an individual cannot be singled out, linked, or inferred from it using means reasonably likely to be used. Most "anonymised" eCommerce data fails that test and stays personal data.
The statutory anchor is GDPR Recital 26, which puts data outside the regulation only when it is "rendered anonymous in such a manner that the data subject is not or no longer identifiable." Article 4(1) defines personal data as the mirror image — any information relating to an identified or identifiable person. The moment data is genuinely anonymous, Article 2(1) takes it out of scope, and you gain real freedom: no lawful basis to maintain, no storage limit, no subject access request to answer. That freedom is exactly why the EDPB insists the bar be met properly.
The EDPB's new 2026 guidelines: what changed
The guidelines update the Article 29 Working Party's Opinion 05/2014, which the EDPB says was overtaken by CJEU case law, EU-wide data spaces, and advances in AI. The core change: anonymity is now assessed per entity and per context, using a three-criteria framework, rather than treated as a fixed property of a dataset.
Two practical notes on status. First, this is a v1.0 draft open for public consultation until 30 October 2026 — it interprets the GDPR rather than adding new law, and the wording can still move. Second, the EDPB is not asking anyone to redo old homework: a controller that already assessed a dataset as anonymous under the 2014 Opinion "is not expected to conduct a new assessment," though periodic reassessment of re-identification risk is "good practice."
Our read: treat the draft as the direction of travel, not a footnote. The three-criteria structure refines the 2014 test rather than reversing it — the EDPB is tightening, not loosening. Building your data map around it now is cheaper than retrofitting after the final text lands; the only real cost is revisiting datasets you would rather leave alone.
Anonymity is relative, not absolute
The EDPB grounds its per-entity approach in the CJEU's ruling in EDPS v SRB (Case C-413/23 P, judgment of 4 September 2025). The Court held that the same pseudonymised data can be personal data for the party that can re-identify it, yet anonymous for a recipient who genuinely cannot. Identifiability is judged from each holder's perspective — a concept commentators have called "relative personal data."
For an online store, the useful question is therefore never "is this dataset anonymous?" but "anonymous for whom?" A file of aggregated purchase trends may be anonymous for the marketing agency that receives only the aggregates, while remaining fully personal for you, because you still hold the keys that tie it back to accounts. The guidelines are blunt about the consequence: where you anonymise data for a recipient but keep the identifiable original, "that controller will still have to treat the given data as personal data and comply with all of their GDPR obligations in regard to it." Anonymising an outbound copy does nothing for the copy you kept.
The three criteria: No Record Isolation, No Linkage, No Inference
The EDPB's framework tests anonymity against three criteria. Pass all three and the data can be treated as anonymous; fail even one and it remains personal data unless further analysis shows otherwise. The table maps each criterion to where eCommerce data typically breaks it.
| Criterion | Met when… | Breaks in eCommerce when… |
|---|---|---|
| No Record Isolation | no unique combination of attributes singles out one person | one row of order value + postcode + timestamp is unique to a single buyer |
| No Linkage | the data cannot be correlated to the same person recorded elsewhere | a hashed email or device fingerprint still joins to your CRM or an ad platform |
| No Inference | no specific, meaningful inference about an individual can be drawn | an aggregate segment quietly reveals one customer (a cohort of "1 buyer in the SW1A postcode") |
No Record Isolation
The No Record Isolation criterion "is met if the data does not contain a unique combination of attribute values that relate to a single individual." The EDPB warns that "the larger a record is, and the more attributes that it contains, the higher the likelihood that the record will be unique." Order records are attribute-rich by nature — basket contents, value, timestamp, delivery area, device — so a stripped-of-name export is often still a fingerprint. High-dimensional, high-resolution data is precisely what singles people out.
No Linkage
The No Linkage criterion "is likely to be met if the information has not been recorded elsewhere and is not correlated to similar information about the same individual recorded in other contexts." This is the one online stores fail most often, because the same customer is recorded everywhere — the shop database, the email platform, the analytics tool, the ad pixel.
The classic cautionary tale predates the guidelines but illustrates them cleanly. In 2019 the Danish DPA (Datatilsynet) proposed Denmark's first GDPR fine — DKK 1.2 million, about €160,700 — against taxi company Taxa 4×35. The firm deleted customer names after two years but kept phone numbers for five, and because ride records stayed attached to those numbers, the trips could still be traced to individuals. The regulator rejected the excuse that a longer deletion window was acceptable because compliance was difficult. The lesson is not "taxi companies are careless"; it is that removing the obvious identifier does nothing if the record still links to a person by another field.
No Inference
The No Inference criterion "is met if no specific and meaningful inference can be drawn from the given data." An inference is specific if it points to one identifiable person and meaningful if it could affect their rights and "could not be obtained from general knowledge or from data about the population at large." Crucially, the EDPB says inferences can be drawn from aggregate data, not just row-level data — which is why a dashboard that reports a segment of one or two customers can leak an individual as surely as a raw table.
How the test plays out across your eCommerce data
Three everyday datasets fail more often than teams expect. Analytics segments built from purchase history are usually high-dimensional enough to isolate records. Loyalty and "aggregate" reports can breach No Inference whenever a slice narrows to a handful of members. And AI or recommendation training sets drawn from order history are the riskiest of all, because the model is built precisely to exploit the fine-grained patterns that single people out.
The guidelines even include a worked eCommerce example. When "an e-commerce retailer transmits excerpts from its customer records to a third-party agency for analysis," and the retailer determines why and how, the data "should therefore be treated as personal data for both the retailer (as the controller) and the agency (as the processor)." Handing records to a vendor does not anonymise them — it just adds a processor. If you are weighing whether an anonymised dataset is a lawful route to model training, the anonymisation has to genuinely hold, not merely be asserted; our [guide to AI and GDPR challenges](/resources/blog/ai-gdpr-compliance-challenges) covers the wider governance picture.
One more trap worth naming: the EDPB "cautions against using 'lack of motivation' as a factor" in the analysis. "No one would bother re-identifying our loyalty export" is not a defence — motivation is hard to prove, changes over time, and identification can happen by accident. The test looks at whether the means exist and are reasonably likely to be used, not at whether anyone currently intends to use them.
Anonymisation vs pseudonymisation: why it matters for retention
Pseudonymised data — where names are swapped for tokens you can reverse — is still personal data under the GDPR; Recital 26 expressly treats data that can be attributed to a person "by the use of additional information" as personal. Anonymisation is a one-way door: if you, or anyone with means reasonably likely to be used, can reverse it, you have pseudonymised rather than anonymised. That single distinction decides whether retention limits, security duties, and access rights still apply.
The difference is not academic once a data subject request arrives. Pseudonymised order data still counts toward your retention schedule and still has to be produced or erased on request; genuinely anonymised data does not. Getting the label wrong in either direction is costly — treat anonymous data as personal and you carry needless obligations; treat personal data as anonymous and you are non-compliant while believing you are safe. If you are setting deletion windows, our [data retention guide](/resources/blog/gdpr-data-retention-how-long-keep-customer-data) pairs directly with this classification step.
How to anonymise customer data the right way
Anonymisation is a process to run and document, not a checkbox. The EDPB expects controllers to be able to demonstrate both that the process happened and that it worked. A defensible workflow:
- Decide "anonymous for whom." Identify every entity that will hold the data and from whose perspective it must be anonymous. Use the simplified approach (ignore differences between recipients — more conservative, safer) as a first pass, then the contextual approach to refine if needed.
- Run the three criteria. Test the dataset for record isolation, linkage, and inference against any external data reasonably likely to be combined with it — including your own CRM and analytics.
- Give the anonymisation a legal basis. Producing anonymous data is itself processing, so it needs an Article 6 basis (and an Article 9(2) exemption if special-category data is involved).
- Document it. Record the technique, the testing, and the result, and retain that documentation after the process — it is how you demonstrate compliance later.
- Lock down or delete the original, and reassess after incidents. Anonymity that relied on keeping a key confidential can be broken by a breach, which may re-trigger Articles 33 and 34. Reassess when circumstances change.
Common mistakes to avoid
Ranked by how often they turn "anonymous" data back into a liability:
- Calling pseudonymised data "anonymous" in your privacy notice. The guidelines are explicit that controllers "should not use descriptions like 'anonymous', 'de-identified' or 'de-personalised' if individuals are actually still identifiable." This is the worst mistake because it is written down, public, and easy for a regulator to check against reality.
- Deleting the name and stopping there. As Taxa 4×35 shows, a lone linking field — phone number, hashed email, customer ID — keeps the record personal.
- Assuming aggregate equals anonymous. Small cohorts fail No Inference. If a segment can shrink to one or two people, it can leak them.
- Leaning on "no one would bother." The EDPB removes lack of motivation from the equation; plan for means, not intentions.
- Anonymising once and never revisiting. Re-identification techniques and available data improve over time. Yesterday's anonymous set is not automatically today's.
How PrivacyForge Helps
Anonymisation is, at heart, a data-classification problem: you cannot decide what is anonymous until you know what personal data you hold and where it flows. PrivacyForge's data mapping builds that record of processing activities, so every dataset — analytics export, loyalty table, training set — has a documented origin and a clear personal-versus-anonymous status rather than an optimistic label.
From there, retention rules attach to the data that is still personal, AI governance tracks which models were trained on which sources, and compliance scoring flags datasets described as anonymous that still carry linking fields. None of this decides the legal question for you — that stays a judgement against the EDPB's criteria — but it gives you the map and the evidence trail to make and defend the call. For the underlying method, see our [data mapping guide](/resources/blog/data-mapping-101-how-to-build-a-record-of-processing-activities).
Frequently Asked Questions
Is anonymised data personal data under GDPR?
Genuinely anonymised data is not personal data and falls outside the GDPR. But the bar is high: under the EDPB's Guidelines 02/2026, data is anonymous only if a person cannot be singled out, linked, or inferred from it using means reasonably likely to be used. Most datasets labelled "anonymised" fail one of these tests and remain personal data.
What is the difference between anonymisation and pseudonymisation?
Pseudonymisation replaces identifiers with tokens that can be reversed with additional information, so the data stays personal and fully within the GDPR. Anonymisation is irreversible: if anyone with means reasonably likely to be used can re-identify individuals, the data is only pseudonymised. The distinction determines whether retention limits, security obligations, and data subject rights still apply.
Can I use anonymised customer data to train an AI model without consent?
Only if the data is genuinely anonymous — which for order-history and behavioural data is hard to achieve, because models exploit the exact fine-grained patterns that single people out. If re-identification remains reasonably likely, the data is personal and needs a lawful basis. The EDPB's Example 3 confirms that sending records to a third party for analysis does not anonymise them.
Does deleting a customer's name make their data anonymous?
No. Removing the name does not anonymise a record that can still be linked to a person through another field, such as a phone number, hashed email, or customer ID. In 2019 the Danish DPA proposed a DKK 1.2 million fine against Taxa 4×35 because trip records remained attributable via retained phone numbers despite name deletion.
Are the EDPB's 2026 anonymisation guidelines legally binding?
The guidelines interpret the GDPR rather than creating new law, and Guidelines 02/2026 are a draft in public consultation until 30 October 2026, so the wording can still change. They are highly authoritative and signal how regulators will assess anonymisation. Controllers who assessed data under the 2014 Opinion need not redo it, but reassessing re-identification risk is good practice.
Conclusion
The EDPB has not made anonymisation impossible — it has made "anonymous" a claim you must be able to prove. The practical shift is to stop asking whether a dataset is anonymous and start asking who could re-identify it, then testing it against No Record Isolation, No Linkage, and No Inference before you drop it out of GDPR scope. Start with the datasets you most rely on being anonymous — analytics segments, loyalty aggregates, AI training sets — because those are the ones a regulator would look at first.
Map your data, classify every "anonymised" set against the three criteria, and document the result. [Start with PrivacyForge's data mapping](/resources/blog/data-mapping-101-how-to-build-a-record-of-processing-activities) to build the record that turns a hopeful label into a defensible one.
This article is informational content, not legal advice. For your specific circumstances, consult a qualified data protection professional.
Sources
- [EDPB Guidelines 02/2026 on Anonymisation (v1.0, adopted 7 July 2026)](https://www.edpb.europa.eu/system/files/2026-07/edpb_guidelines_202602_anonymisation_v1_en_0.pdf)
- [EDPB news: anonymisation and web scraping for generative AI](https://www.edpb.europa.eu/news/edpb-sheds-light-on-anonymisation-and-web-scraping-for-generative-ai-and-adopts-final-version_en)
- [EDPB public consultation — Guidelines 02/2026 on Anonymisation (open to 30 October 2026)](https://www.edpb.europa.eu/public-consultations/guidelines-022026-on-anonymisation_en)
- [GDPR Recital 26 — anonymous data and the "means reasonably likely to be used" test](https://gdpr-info.eu/recitals/no-26/)
- [CJEU Case C-413/23 P, EDPS v SRB (judgment of 4 September 2025) — EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:62023CJ0413)
- [Covington — CJEU clarifies the concept of personal data in EDPS v SRB](https://www.insideprivacy.com/eu-data-protection/eu-court-of-justice-clarifies-the-concept-of-personal-data-in-the-context-of-a-transfer-of-pseudonymized-data-to-third-parties/)
- [EDPB — Danish DPA proposes DKK 1.2 million fine for Taxa 4×35 (2019)](https://www.edpb.europa.eu/news/national-news/2019/danish-data-protection-agency-proposes-dkk-12-million-fine-danish-taxi_en)