Anonymous for Whom? What the EDPB’s New Anonymisation Guidelines Mean for Every Manager Who Shares Data

CORE THESIS Whether data is anonymous depends not only on its values but also on the relevant entities and the means they can realistically use, which is why the same table can be anonymous for one recipient and personal data for another, and why the organisation that anonymises data may still hold personal data when its recipient does not. The EDPB’s Guidelines 02/2026 turn that judgement into a method with two routes and three tests, and they make one thing plain: removing names, coarsening values or a contractual ban does not by itself guarantee anonymity, so its effectiveness must be tested in an assessment that names the relevant entities and examines their means in context. The EDPB calls it good practice to repeat that assessment, because technical developments and additional information can make re-identification easier.

Picture a research institute holding patient records from a completed study that wants to keep working with the data without the GDPR following every step. It strips the names, coarsens the dates of birth to the year and the postcodes to their first two digits, deletes the originals and retains a small table. The question for the institute’s data protection officer sounds simple: is the table that remains anonymous, so that the GDPR no longer applies to it, or is it still personal data? The answer does not settle everything, since the anonymisation itself is processing that needs a legal basis and the institute’s duties for the original records remain, yet it decides whether the GDPR governs the table from now on and what a leak of it would mean.

The European Data Protection Board, in which the EU’s supervisory authorities coordinate their reading of the GDPR, has now given that officer a method, with a research institute’s table as its running example. The source this article follows most closely is its four-page summary “Anonymisation: How to assess the anonymity of data. Guidelines at a glance”, published in October 2026, which condenses the framework into one definition, two approaches, three criteria and a flowchart.¹ Behind it stands the full text, “Guidelines 02/2026 on Anonymisation”, Version 1.0, adopted on 7 July 2026.² The guidelines set out the EDPB’s interpretation under Article 70(1)(e) GDPR; they are not a new regulation, and this article explains them in the version still under consultation. Version 1.0 was adopted for public consultation, which runs until 30 October 2026, and the final text may change, so what follows describes the draft as it stands.³

Anonymous for whom

The GDPR protects personal data, which means any information that relates to an identified or identifiable natural person, and anonymous data is the mirror image, which falls outside the regulation.⁴ The test has two questions. Does the information relate to a natural person, and is that person identified or identifiable? If either answer is no, the data is anonymous.⁵

The guidelines stress above all that these answers can differ from one entity to another. Information may unambiguously relate to a person, yet only one organisation may be able to work out who that is, so the information is personal data for that organisation and, outside particular circumstances such as onward transfer, anonymous for everyone else.⁵ The practical question, posed in paragraph 12, is this: for whom is the data intended to be anonymous? If an organisation anonymises data for its own use, its own perspective is the relevant one, whereas if it releases the data for independent use, the receivers’ perspectives count.⁶ Information can “relate” to a person by content, purpose or effect, and even group statistics may relate to individuals when techniques can extract them.⁷

The summary’s second practical example concerns perspective. A controller is the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of processing personal data, and a processor is such a body that processes personal data on the controller’s behalf. Where one entity processes on behalf of another, the controller’s perspective governs both, so if the information is personal for the controller it is personal for the processor too, which then carries the GDPR’s processor obligations.⁸ Example 3 is a retailer whose analysis agency therefore holds personal data. Example 4 is the counterpart: a hospital transmits excerpts of patient records that do not by themselves allow identification to an independent research institute, which decides its own purposes and means, so whether the data is personal for the institute is assessed from the institute’s own perspective.⁸ Joint controllership remains a third possibility, since lacking one’s own access to identifying data does not automatically exclude it.⁹

The guidelines add the general principle that where data is anonymised for the recipient but not for the anonymising controller, that controller still holds personal data and keeps all of its obligations.¹⁰ Nor does the recipient’s inability to identify anyone automatically remove the transmitting controller’s information duties. In C-413/23 P the Court of Justice, on Article 15(1)(d) of Regulation (EU) 2018/1725, looked at the time of collection and the controller’s perspective, the guidelines take this up in paragraph 14, and under the GDPR Articles 13 and 14 then have to be checked.¹¹

What “reasonably likely” means in practice

Identifying a person means distinguishing them from others in a given context so that they can be treated differently, whether by a direct identifier such as a name or by a combination of attributes unique in that context.¹² Identification may be indirect, through additional information, methods controlled by others or passing the data to someone with the means. The likelihood of identification does not need to be zero for data to be anonymous; it needs only to be insignificant in reality.¹²

The hinge of the analysis is the phrase “means reasonably likely to be used”, which the Court of Justice has defined in the negative: means may not be reasonably likely to be used if the likelihood of identification appears insignificant in reality because identification would be impossible, would demand disproportionate effort in time, cost and labour, or is prohibited by law.¹³ “Means” is read broadly and includes means that sit with another entity, so the whole chain of means has to be considered, as Example 7, the summary’s first practical example, shows. A controller wants to share information with a business partner and finds in testing that a particular technique would re-identify the data subjects. The partner could not run it itself, yet could easily hire a third party that can, so the technique still counts as a means reasonably likely to be used by the partner.¹³

Whether an entity is likely to use a means is judged on all objective factors, among them the properties of the data, the context of release, the availability and cost of additional information, and current and foreseeable technology.¹⁴ Relevant entities can include anyone who directly or indirectly receives the data, including unauthorised and malicious actors, from rogue employees to journalists, public agencies and cybercriminals.¹⁵ The EDPB also cautions against counting an entity’s lack of motivation, because motivation is hard to assess objectively, may change and may not match its actions, since identification can happen through accident, negligence or outside compulsion.¹⁵

A legal prohibition can take a means out of play because people can generally be assumed to follow the law, yet that assumption is rebuttable where there is evidence that the prohibition is not enforced, that gains outweigh risks or that it has been breached in comparable situations.¹⁶ A prohibition written into a contract, by contrast, should not be treated as a prohibition by law even when it binds the parties. Contractual terms may affect the means reasonably likely to be used, but they only complement technical measures and can be revised or ignored.¹⁶ In my view this paragraph is likely to matter most where data sharing has so far rested mainly on such clauses. Onward transfer explains the note at the foot of the summary’s flowchart: if an entity is reasonably likely to pass the data to a third party that may have the means to identify people, the data is personal for that transfer and for the recipient. It also becomes indirectly personal for the transferring entity, even one that could never have identified anyone itself.¹⁷

The worked example: the research institute’s five rows

The guidelines first show what failure looks like. Example 10 is a research institute’s table with sex, full date of birth, five-digit postcode and an autoimmune disease in which every row is unique, so the table fails the first criterion, No Record Isolation, and because the demographic details may well be available through public registers, singling out is very likely, in which case the data would be personal.¹⁸ Record-level data, meaning data in which each individual’s values can be picked out, is at its most exposed in this form.

Now consider a generalised table. Example 12 is the EDPB’s own illustrative table of a research institute’s patient records, reproduced here as in the guidelines. The date of birth has been reduced to the year and the postcode to its first two digits.¹⁹

Sex	Date of birth	Postcode	Disease
Male	**-**-1946	54***	sclerosis
Male	**-**-1946	54***	sclerosis
Female	**-**-1951	32***	lung cancer
Female	**-**-1951	32***	lung cancer
Female	**-**-1951	32***	lung cancer

No row is unique, so the table satisfies No Record Isolation. Yet the first two rows say something unintended: every man born in 1946 in a postcode beginning with 54 whose record was included has sclerosis. The data can therefore be linked to any other dataset that holds the same person’s sex, year of birth and generalised postcode, and if that link can be made, No Linkage is violated. That is why the guidelines insist on testing the two criteria separately even though data that passes the first will often pass the second.¹⁹

Aggregation does not rescue the table. Example 19 turns it into a histogram of diagnoses by sex, year of birth and abbreviated postcode, and a person’s diagnosis can still be inferred by linking the histogram to those three attributes and to the knowledge that their record was included.²⁰ This is inference, the drawing of a conclusion from the data together with additional information, and the guidelines note that synthetic data can be queried and AI models prompted to the same end.²⁰

Example 22 turns the table into a management decision. The institute, which has deleted the original personal data, uses the contextual approach and first asks who could realistically reach the table. Despite strong security it accepts that a leak is possible over time, so it counts its authorised members, accidental recipients, intruders, authorities acting in the course of their duties and anyone who might obtain the data from them.²¹ People familiar with the patients’ private lives are extremely unlikely to receive the data after a leak that is itself unlikely, so they are not relevant entities. Linkage requires knowing a person’s sex, year of birth and generalised postcode and the fact of inclusion, and none of the relevant entities knows the second, not even the institute’s staff, who had no contact with the patients and hold no record of who was included. The institute therefore concludes that No Linkage is met, a conclusion the guidelines say must be underpinned by careful reasoning about the specific context.²¹

Example 25 asks what would happen if the link were made. Sex, year of birth and generalised postcode are not unique, so the linkage alone does not single anyone out, yet if the second dataset holds an identifying extra attribute or a direct identifier, the table becomes personal data, which is why linked information is re-tested against all three criteria.²² Two cautions belong here. The guidelines present Example 22 only as an illustration of No Linkage, so an overall finding would still require No Inference to be assessed, whose risk Example 19 showed, while No Record Isolation was met in Example 12. And in my reading, which the guidelines do not spell out, the finding rests on facts about the institute, so a leaked list of participants or publication of the table would undo the reasoning without a single value changing.

Three criteria, one logic

No Record Isolation is met if the data contains no unique combination of attribute values relating to a single individual, and it can usually be tested on the given data alone.¹⁸ Singling out, the risk it guards against, is the act of distinguishing a person by matching a unique combination of attributes to them. Aggregate data, meaning data that describes groups and contains no individual records, will usually satisfy it.¹⁸

No Linkage is met if the data contains no record that could be linked to another record which also relates, with certainty or high likelihood, to the same person and comes from a different dataset. It requires knowledge of other datasets. Records may be linked through a common identifier such as a customer number or through matching combinations of attributes.²³

No Inference is met if no specific and meaningful inference can be drawn from the given data, alone or with additional information, including information about the anonymisation process itself. An inference is specific if it relates to a single identified or identifiable person, and meaningful as well if processing it is liable to affect that person’s rights, relies on the given data and could not have been obtained from general knowledge or from data about the population at large.²⁴ From “green is a popular colour” one could infer “Connor likes green”, which is personal data, yet the inference is not meaningful because it comes from population-level information, so the statement stays anonymous.²⁴ A meaningful inference, by contrast, depends on the person’s own record having been in the original data.²⁴

Failing a criterion is not the same as failing the test. If all three are met under either approach the data can be presumed anonymous, and if one is violated further analysis follows.²⁵ Where No Record Isolation fails, the question is whether the isolated records allow singling out with attributes a relevant entity could obtain, and if not, the data can still be anonymous while the other two criteria hold. A failure of No Inference is treated more strictly, since data violating it should not be considered anonymous under the simplified approach, though the contextual approach can still be tried.²⁵ A technique does not need perfect accuracy, yet its result must be sufficiently precise and reliable in context to distinguish the person and treat them differently, and that can already be the case for a single person in the dataset.²⁶

Simplified or contextual: choosing a route

The framework can be applied in two ways, and the choice is a management decision about effort and risk. The contextual approach follows the legal standard in full by identifying each relevant entity and examining the means each is reasonably likely to use. Its weakness is complexity and a risk of false positives where the assessor overlooks one entity’s means.²⁷

The simplified approach ignores differences between entities and asks whether means of identification exist in the abstract, assuming that someone will then use them. It is more convenient and more cautious. The guidelines are careful to say that it is not an alternative legal standard; it voluntarily shifts the risk from false positives to false negatives, and while it can prove that data is anonymous, a third party cannot use it to prove that data is personal.²⁷ In practice a combination of the two can be helpful: a controller starts with the simplified approach, stops if re-identification is not even theoretically possible, and switches to the contextual approach once a method appears, to ask whether it is reasonably likely to be used from the relevant perspectives.²⁷

The summary’s flowchart, drawn from Annex 1 of the guidelines, orders these steps, beginning with a description of the data, where it is stored and what could help re-identification. It then asks whether it is obvious that the data is not anonymous, as with names, phone numbers, easily reversible pseudonyms or data clearly used to evaluate a specific person, and if so the data is treated as personal and the criteria are not needed.²⁸ The guidelines do not define pseudonymisation; they treat easily reversible or themselves identifying pseudonyms as obvious personal data, other pseudonymised data faces the same perspective test as everything else, and anonymisation is any processing that successfully produces anonymous data.²⁸

The chart then branches. On the simplified route the assessor extends the data by every possible linkage and inference, tests the three criteria, and treats the data as anonymous if they pass or if only No Record Isolation fails without singling out being possible; otherwise the data is personal or a contextual analysis follows. On the contextual route the assessor first asks for whom the data is intended to be anonymous, determines the relevant entities and their means, and runs the same criteria entity by entity, so that the data may come out anonymous for some and personal for others.²⁸

What the decision does not settle

A finding of anonymity is dated. The likelihood of re-identification typically increases over time as techniques improve and additional information becomes available, and once it is no longer insignificant the data becomes personal again. The EDPB therefore calls periodic reassessment good practice.²⁹ Most documented re-identification techniques, the guidelines observe, are becoming increasingly accessible and, especially against record-level data, run in reasonable time on commodity hardware, while some aggregate-data techniques need larger resources available as a service. The real cost often lies in obtaining additional information, and the EDPB expects developments in AI, and especially agentic AI, to reduce the time and cost of deploying the techniques and to save time gathering information from publicly available sources.³⁰

Partial success counts as failure for the dataset as a whole, which is anonymous only if the anonymisation works for every included individual; a mix of personal and anonymous data is treated as personal wherever the parts are not handled separately.³¹ Anonymisation is itself processing of personal data, so it needs a legal basis under Article 6, and an exemption under Article 9(2) if health or other special category data is involved.¹⁰ Controllers should state clearly that personal data will be processed into anonymous data, and should not describe data as “anonymous”, “de-identified” or “de-personalised” when individuals remain identifiable.³² Documentation of the process and its testing is what demonstrates both compliance and effectiveness, and it should be retained afterwards.³² Finally, a security incident can reopen the question. Where anonymity rested on certain information staying confidential and individuals can be identified after an incident, the entity that suffered the incident should determine its role and whether it has obligations under Articles 33 and 34.³³

Lessons learned

The first lesson is that the question on a manager’s desk is never “is this data anonymous” but “anonymous for whom, with what means, for how long”. The research institute’s case shows how it resolves. Its No Linkage finding rests on facts about the institute, which has deleted the originals, keeps no participant list and can show that nobody who could realistically reach the table knows either. Paragraph 37 completes the picture, because an organisation that keeps the full records does not shed its own obligations by producing a table that is anonymous for someone else.¹⁰

The second lesson concerns the instruments managers reach for most often. Removing names, generalising dates and signing a non-re-identification clause are all useful, and none by itself guarantees anonymity, because its effectiveness has to be tested in context. Unique records invite singling out, non-unique records can still be linked, aggregates can still support inferences, and a contractual prohibition is not a legal one.¹⁶ The business partner example shows the attitude the Board expects: ask what the recipient could do by hiring someone.¹³

The third lesson is procedural. Start with the simple cases and a data map, choose the simplified route when the entities are hard to characterise and otherwise the contextual one, test all three criteria even after one has failed, and re-test linked data.²⁸ Write the assessment down, keep it, revisit it on a schedule and after any incident or new public dataset that changes what someone could realistically do, and do not use the word “anonymous” in a privacy notice until the assessment supports it.³²

Glossary

Term	Meaning
Personal data	Information relating to an identified or identifiable natural person (Art. 4(1) GDPR)
Anonymous data	Information that does not relate to an identified or identifiable natural person and therefore falls outside the GDPR (Recital 26)
Controller	The natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of processing personal data (Art. 4(7) GDPR)
Processor	A natural or legal person, public authority, agency or other body that processes personal data on behalf of the controller (Art. 4(8) GDPR)
Pseudonym	A code standing in for an identifier; the guidelines treat pseudonyms that can easily be reverse engineered, or that themselves identify, as obvious personal data (para. 50)
Anonymisation	Any processing that successfully produces anonymous data under the GDPR, whether or not the original data is deleted
Relevant entity	Anyone who could contribute to the direct or indirect identification of a person from the given data, including malicious actors
Perspective	The circumstances and means of a particular entity, from which the personal nature of data in its hands is assessed
Means reasonably likely to be used	The identification methods an entity could realistically deploy, including through third parties, judged on all objective factors
Record-level data	Data in which each individual’s values can be picked out as a record
Aggregate data	Data that describes groups of people and contains no individual records
Singling out	Distinguishing one person from others by matching a unique combination of attributes to them
Linkage	Establishing that records in different datasets relate to the same person
Inference	Drawing a conclusion about a person from the given data, alone or with additional information
Contextual approach	Assessing the three criteria separately for each relevant entity and its means
Simplified approach	Assessing the three criteria while ignoring differences between entities’ means
EDPB	European Data Protection Board, composed of the heads of the Member States’ supervisory authorities and the European Data Protection Supervisor (Art. 68 GDPR)

Legal notice: This article serves general information purposes and does not constitute legal advice. For a legally sound assessment in a specific case, consultation with a specialised data protection lawyer is recommended. As of: October 2026.

1. EDPB, “Anonymisation: How to assess the anonymity of data. Guidelines at a glance”, October 2026, four-page summary of Guidelines 02/2026 covering the definition of anonymous data, the two practical examples (means reasonably likely to be used, section 2.4.2, paragraph 28, example 7; identifying the relevant perspective, section 2.2, paragraph 15, examples 3 and 4), the contextual and simplified approaches, the three criteria and the flowchart with its closing note on onward transfer. PDF: https://www.edpb.europa.eu/system/files/2026-10/edpb-summary-102026-anonymisation_en.pdf (accessed October 2026). ↩

2. EDPB, “Guidelines 02/2026 on Anonymisation”, Version 1.0, adopted on 7 July 2026 for public consultation. Full text: https://www.edpb.europa.eu/system/files/2026-09/edpb_guidelines_202602_anonymisation_v1_en_0.pdf (the same document as under the earlier July path). Consultation page, open from 8 July to 30 October 2026: https://www.edpb.europa.eu/public-consultations/guidelines-022026-on-anonymisation_en. Press release: https://www.edpb.europa.eu/news/edpb-sheds-light-on-anonymisation-and-web-scraping-for-generative-ai-and-adopts-final-version_en (all accessed October 2026). ↩

3. Guidelines 02/2026, version history on p. 1 (version 1.0, 07 July 2026, “adoption of the guidelines for public consultation”); consultation deadline of 30 October 2026 according to the EDPB press release cited in ². URL as in ² (accessed October 2026). ↩

4. Guidelines 02/2026, para. 1 with footnotes 1 and 2 (anonymous information as information not relating to an identified or identifiable natural person, Recital 26 GDPR as mirror of Art. 4(1); anonymous data outside the GDPR under Art. 2(1)). URL as in ² (accessed October 2026). ↩

5. Guidelines 02/2026, paras. 6–8 (the two-question core test; answers may vary between entities; the test is one of likelihood). URL as in ² (accessed October 2026). ↩ ↩²

6. Guidelines 02/2026, paras. 11–13 (relevant entities and perspectives; “for whom is the data intended to be anonymous”; factors such as transmission and processing on behalf of another). URL as in ² (accessed October 2026). ↩

7. Guidelines 02/2026, paras. 16–17 (relation by content, purpose or effect; aggregate data may relate to individuals where extraction techniques exist). URL as in ² (accessed October 2026). ↩

8. Guidelines 02/2026, para. 15 and Examples 3 and 4 (controller’s perspective applies to processors; e-commerce retailer and agency; hospital transmitting excerpts that do not by themselves allow identification to an independent research institute, assessed from the institute’s own perspective). The guidelines do not connect Example 4 to the research institute’s table in Examples 12, 19, 22 and 25. URL as in ² (accessed October 2026). ↩ ↩²

9. Art. 4(7) and Art. 26 GDPR; Guidelines 02/2026, para. 9 with fn. 7, which cites CJEU C-210/16 Wirtschaftsakademie Schleswig-Holstein; the relevant passage of the judgment is para. 38 (joint controllership does not require access to the personal data). URL as in ² (accessed October 2026). ↩

10. Guidelines 02/2026, paras. 37–38 (data anonymised for the recipient but not the controller remains personal for the controller; anonymisation requires a legal basis under Art. 6 and an Art. 9(2) exemption for special category data; the previous basis and any Art. 9(2) exemption are presumed to continue only where anonymisation is part of the same processing activity and pursues the same purposes). Author’s note: otherwise Art. 5(1)(b), Art. 6(4) and Art. 9 GDPR must be assessed separately. URL as in ² (accessed October 2026). ↩ ↩² ↩³

11. Guidelines 02/2026, para. 14 and Example 2 (information duty assessed at the time of collection from the controller’s perspective, regardless of the recipient’s perspective), citing CJEU C-413/23 P EDPS v SRB on Art. 15(1)(d) of Regulation (EU) 2018/1725; under the GDPR, Arts. 13 and 14. URL as in ² (accessed October 2026). ↩

12. Guidelines 02/2026, paras. 19–20, 22 and 24 (identification as distinguishing a person so as to treat them differently; direct and indirect identification; likelihood need not be zero but must be insignificant in reality; unique combinations of attributes). URL as in ² (accessed October 2026). ↩ ↩²

13. Guidelines 02/2026, paras. 26–28 and Example 7 (means not reasonably likely if impossible, disproportionate or legally prohibited; “means” read broadly including a chain of means; the business partner who could hire a third party). URL as in ² (accessed October 2026). ↩ ↩² ↩³

14. Guidelines 02/2026, para. 29 (objective factors a to e; legal routes to additional information count as means reasonably likely to be used). URL as in ² (accessed October 2026). ↩

15. Guidelines 02/2026, paras. 30–31 (relevant entities include unauthorised and malicious actors, with the list from the anonymising controller to cybercriminals; caution against “lack of motivation”; value and risk of re-identification for the entity). URL as in ² (accessed October 2026). ↩ ↩²

16. Guidelines 02/2026, paras. 32–34 (legal prohibitions and when the assumption of compliance is rebutted; contractual prohibitions are not prohibitions by law and only complement technical measures). URL as in ² (accessed October 2026). ↩ ↩² ↩³

17. Guidelines 02/2026, para. 21 (onward transfer to an entity with means makes data personal for the transfer, the recipient and indirectly the transferring entity); echoed in the note at the foot of the flowchart in ¹. URL as in ² (accessed October 2026). ↩

18. Guidelines 02/2026, paras. 54–58 and Examples 10 and 23 (No Record Isolation criterion; unique records of sex, date of birth, postcode and autoimmune disease; aggregate data usually satisfies the criterion; singling out via public registers). URL as in ² (accessed October 2026). ↩ ↩² ↩³

19. Guidelines 02/2026, para. 63 and Example 12 (the generalised five-row table; No Record Isolation met; all men born in 1946 in postcode area 54*** whose record is included in this example table carry the entry “sclerosis”; linkage via prior knowledge, information in either dataset or a bridging dataset; No Record Isolation and No Linkage tested separately). URL as in ² (accessed October 2026). ↩ ↩²

20. Guidelines 02/2026, paras. 80–82 and Example 19 (inferred linkage applies to aggregate data; the histogram of diagnoses; inferences from AI models and synthetic data by querying or prompting). URL as in ² (accessed October 2026). ↩ ↩²

21. Guidelines 02/2026, paras. 88–89 and 94 with Example 22 (capabilities vary over time; accessibility of data; para. 94 presents the example as a high-level illustration of the No Linkage criterion only; the research institute’s contextual assessment, its five groups of entities with realistic access, the exclusion of people familiar with the patients, and the conclusion that No Linkage is met). URL as in ² (accessed October 2026). ↩ ↩²

22. Guidelines 02/2026, paras. 101–103 and Example 25 (linkage on non-unique attributes does not identify; extra attributes or a direct identifier in the second dataset would; linked data is re-tested against the three criteria). URL as in ² (accessed October 2026). ↩

23. Guidelines 02/2026, paras. 59–62 (No Linkage criterion; linkage via common identifiers or attribute combinations). URL as in ² (accessed October 2026). ↩

24. Guidelines 02/2026, paras. 66–71 with Example 13 (No Inference criterion; specific and meaningful inferences; “Green is a popular colour” and “Connor likes green”; a meaningful inference is connected to the original dataset). URL as in ² (accessed October 2026). ↩ ↩² ↩³

25. Guidelines 02/2026, paras. 95–100 and the table at para. 97 (compiling the results; singling out after a No Record Isolation failure; data that still passes despite a unique record; No Inference failure under the simplified approach). URL as in ² (accessed October 2026). ↩ ↩²

26. Guidelines 02/2026, para. 87 with Example 20 (effectiveness of a re-identification technique; accuracy need not be perfect, but the result must be sufficiently precise and reliable to let the person be distinguished and treated differently; this can already be the case for a single individual, but not where the correct hit can only be guessed). URL as in ² (accessed October 2026). ↩

27. Guidelines 02/2026, paras. 45–49 with footnote 36 (contextual and simplified approaches; false positives and false negatives; the simplified approach is not an alternative legal standard and cannot be used by third parties to prove data is personal; combining the approaches). URL as in ² (accessed October 2026). ↩ ↩² ↩³

28. Guidelines 02/2026, paras. 10 and 50–51 and Annex 1 (anonymisation as any processing producing anonymous data; simple cases including easily reversible pseudonyms; data mapping as an early step; the flowchart), together with the flowchart as reproduced in ¹. URL as in ² (accessed October 2026). ↩ ↩² ↩³ ↩⁴

29. Guidelines 02/2026, para. 35 (likelihood of re-identification increases over time; previously anonymous data may become personal again; periodic reassessment as good practice). URL as in ² (accessed October 2026). ↩

30. Guidelines 02/2026, paras. 92–93 (re-identification techniques increasingly accessible on commodity hardware or as a service; AI and agentic AI expected to reduce time and cost of deploying techniques and of gathering information from public sources). URL as in ² (accessed October 2026). ↩

31. Guidelines 02/2026, para. 36 (datasets containing a mix of anonymous and personal data; whole dataset treated as personal where parts are not handled separately). URL as in ² (accessed October 2026). ↩

32. Guidelines 02/2026, paras. 40–41 (transparency obligations; controllers should not use labels such as “anonymous” or “de-identified” where individuals remain identifiable; documentation of the anonymisation process and its testing, retained after completion). URL as in ² (accessed October 2026). ↩ ↩² ↩³

33. Guidelines 02/2026, para. 42 (security incidents may require reassessment of anonymity and consideration of Arts. 33 and 34 GDPR). URL as in ² (accessed October 2026). ↩