When is data really anonymous? The EDPB's 2026 anonymisation guidelines in practice

The shift that matters 

The EDPB adopted its Guidelines 02/2026 on anonymisation for public consultation on 7 July 2026. They are therefore not yet in final form, and the text may change before adoption. Even so, the direction they set is clear enough to act on now, and organisations building data-driven services or research pipelines should read them as the current statement of how the Board approaches the boundary between personal and anonymous data. 

The guidelines update the Article 29 Working Party's Opinion 05/2014 on anonymisation techniques, which had until now been the main reference point. The most consequential development is the Board's acceptance, following the Court of Justice in EDPS v SRB (Case C-413/23 P), that whether data relate to an identified or identifiable person may vary from one entity to another. In the words of the guidelines, anonymity should be assessed from each relevant entity's perspective, typically the party for whom the data is intended to be anonymous. 

This reframes how any data project should be scoped. The GDPR boundary is no longer treated as an absolute property of the dataset. The same information can be personal data in the hands of one party and anonymous in the hands of another. It is the identifiability test in Recital 26 GDPR applied to the actual party, the actual means available and the actual context. The practical consequence is that the first step in an anonymisation exercise is not technical but analytical. The question to settle first is whose perspective matters. 

The first question: for whom is the data intended to be anonymous? 

The guidelines frame the core test as two questions. First, does the information relate to a natural person, whether by its content, its purpose or its effect? Second, is that person identified or identifiable? If the answer to either question is no, the data are anonymous. Crucially, the guidelines state that the answers may differ from one entity to another, so the test has to be run entity by entity rather than once for the dataset as a whole. 

To identify the relevant perspective, the guidelines direct the assessor to ask a plain question: for whom is the data intended to be anonymous? Four practical settings follow from it. Where data are anonymised for an organisation's own internal use, that organisation's perspective governs. Where data are transferred for independent use by recipients, anonymity is generally assessed from the perspective of those recipients. Where data are released publicly, the universe of possible access and auxiliary information is at its widest, so the assessment is correspondingly demanding. Where data are held in a controlled or research environment, the access conditions, security controls and realistic re-identification pathways all bear on the analysis. 

The guidelines illustrate the point with the Court's decision in OC v Commission (Case C-479/22 P), where a press release was, by its nature, intended for distribution to journalists, including investigative journalists whose research skills exceed those of an average person. The assessment of whether the publication contained personal data therefore had to be performed from at least those journalists' perspective. The lesson for clients is that the intended audience and the intended use fix the perspective, and the perspective drives everything that follows. 

The processor trap 

This is the point most likely to catch organisations out. The guidelines make clear that the relevant perspective for an entity depends on whether that entity determines the purposes and means of the processing. Where an entity processes information on behalf of another, the guidelines say the assessment uses the controlling entity's perspective. In practice, if an entity processes data on behalf of a controller who can identify the individuals, the data are personal for that entity too, even where it is itself technically unable to identify anyone. That entity is a processor and is subject to the obligations that fall on processors. 

The guidelines describe this as a teleological application of the GDPR, on the basis that the processor concept exists precisely to stop controllers avoiding their obligations by outsourcing processing to third parties. The contrast between two examples in the guidelines captures the boundary. In one, an e-commerce retailer sends excerpts of its customer records to a third-party agency for analysis. Because the retailer determines the purpose and means and can identify the customers, the data are personal for both the retailer and the agency. In the other, a hospital sends excerpts of patient records to an independent research institute that determines its own purposes and means, does not return the data and does not act on the hospital's instructions. In that situation, the institute's own perspective governs. 

This matters in practice. Organisations increasingly depend on services such as clean rooms, secure processing environments, cloud analytics tools and shared research platforms, and these are typically run by an outside party acting on the organisation's behalf. That party is usually a processor, or close to it. The fact that it cannot itself identify anyone does not, on its own, take the processing outside the GDPR where it acts for a controller who can. Getting the role classification right, and being able to show genuine independence where it is claimed, is therefore central. The guidelines cross-refer to the EDPB's Guidelines 07/2020 on the concepts of controller and processor for the underlying analysis. 

It is worth being precise about what EDPS v SRB decided, because the case is easily over-read. In that case, the Court held that the obligation to inform data subjects about the recipients of their data had to be assessed at the time of collection and from the controller's perspective, because that obligation formed part of the legal relationship between the controller and the data subject. That specific holding does not abolish contextuality. As the guidelines reflect, some obligations carry their own built-in perspective, and processor relationships require the controller's perspective to follow the processing, but outside those situations the identifiability test remains contextual. 

When is someone “identifiable” and by what means? 

The guidelines define identification as distinguishing a person from others within a given context in a way that makes it possible to treat them differently. Two features of the test deserve emphasis. First, the likelihood of identification does not have to be reduced to zero, but it must be insignificant in reality. This is an important corrective to the intuition that any residual possibility of re-identification defeats anonymity. Second, a unique record is not automatically personal data. Uniqueness may enable singling out, but the operative question remains whether the relevant entity can use that uniqueness to distinguish and treat the individual differently by means reasonably likely to be used. 

On means, the guidelines take a deliberately broad view. "Means" covers everything from reading a document to running complex analyses, and it includes means available not only to the entity itself but to others, where a chain of means could realistically come together. The guidelines give the example of a recipient who could not itself run a re-identification technique but could readily hire a third party to do so. That technique still counts as a means reasonably likely to be used. Recital 26 GDPR and the Court's reasoning in Breyer (Case C-582/14) and Scania (Case C-319/22) underpin this chain-of-means approach. 

Whether means are reasonably likely to be used is assessed against objective factors set out in the guidelines: (i) the properties of the data, including whether they are aggregated and how unique and precise the records are; (ii) the context of the release or processing, including any effective and permanent access restrictions; (iii) the availability of additional information and how easily it can be obtained; the cost and time involved; and (iv) the available technology, including reasonably foreseeable developments. Means may fall away where identification would be practically impossible, would involve disproportionate effort, or is prohibited by law. 

The guidelines also address who counts as a relevant entity, and here the list is expansive. It may include, depending on the circumstances, recipients, rogue employees, an individual's associates, investigative journalists, domestic and foreign intelligence agencies, unethical companies and cybercriminals. The guidelines temper this with the qualification that not every perspective needs to be considered in every case, and with a general assumption that people will follow the law. That assumption can be rebutted where there is concrete evidence that an unlawful means is nevertheless reasonably likely to be used, for example where a prohibition is not effectively enforced or where the data are especially vulnerable to illegal access. It is worth noting that the reach of this adversary analysis, and how far foreseeability limits it, has attracted critical commentary, and it is one of the areas most likely to be refined before the guidelines are finalised.

 Two ways to run the assessment: contextual and simplified 

Before turning to the three criteria, it is worth being clear about the two ways the guidelines allow the assessment to be carried out, because the choice affects both the effort involved and the result. The guidelines set out a contextual approach and a simplified approach, and they are not two competing legal tests. They are two ways of applying the same standard. The contextual approach assesses identifiability separately for each relevant entity, using what that entity can actually do and how likely it is to do it. It reflects the full legal standard and, done properly, gives the most accurate answer to whether a dataset is within the scope of the GDPR. Its drawback is complexity, and the guidelines acknowledge that it carries a risk of false positives: an assessor who is unaware of a particular entity’s means may wrongly conclude that data is anonymous. 

The simplified approach deliberately ignores the differences between entities and their respective means, and asks only whether re-identification is possible at all. The guidelines are explicit that it is not an alternative legal standard, and that it may lead a controller to treat data as personal even where the data would in fact be anonymous for the relevant entities. It is, in other words, a cautious shortcut: it shifts the risk from false positives towards false negatives, so that in cases of doubt the data is treated as personal. That caution has a practical value the guidelines confirm. A controller may use the simplified approach to satisfy itself that data is anonymous, but a third party cannot use it to prove the opposite, that data is personal. 

In practice the two are often combined. A controller may begin with the simplified approach and, if it shows that re-identification is impossible in theory, treat the data as anonymous without going further. If the simplified approach flags a possible route to re-identification, the controller can then move to the contextual approach and test whether that route is in fact reasonably likely to be used by any relevant entity. For a project that shares data between several parties, the contextual approach is usually the one that matches reality, because the whole point is that the answer differs from one party to another. 

The three criteria, and why failing one is not fatal 

The technical core of the guidelines is a framework built on three criteria carried forward from the 2014 Opinion: (i) ‘No Record Isolation’, (ii) ‘No Linkage’ and (iii) ‘No Inference’. ‘No Record Isolation’ asks whether the data contain a unique combination of attributes relating to a single individual. ‘No Linkage’ asks whether a record can be connected to other data about the same person. ‘No Inference’ asks whether a specific and meaningful inference can be drawn. 

The most practically valuable rule in this part of the guidelines is how the criteria interact with the conclusion. If all three are met, the data may be regarded as anonymous. But the guidelines are explicit that violating a criterion does not automatically make the data personal. Instead, a failed criterion requires further analysis of the effect of that violation and whether the data can still be considered anonymous. The three criteria are therefore structured tests that organise the assessment, not a checklist in which a single imperfection returns the dataset to the GDPR. 

On record isolation, the guidelines use a street-scene example. Within a given street, neither "the person in a black suit" nor "the person walking a dog" is unique, but "the person in a black suit who is also walking a dog" may be. That combination singles the person out within that context. The careful point for clients is that singling out evidences identifiability. Whether it amounts to identification still depends on whether the person can be distinguished and treated differently, and this is another area where the guidelines have drawn commentary. 

Learning is not leakage: analytics, AI and inference

For organisations doing analytics or developing AI, the treatment of inference is the most important section of the guidelines. The Board says an inference defeats anonymity only where it is both specific and meaningful. An inference is specific if it relates to a single identified or identifiable individual. It is meaningful if its processing is liable to affect that person's rights and interests, relies on the given data, and could not be obtained from general knowledge or from information about the population at large. 

Two examples in the guidelines make the distinction concrete. In one, the statement "Green is a popular colour" is anonymous. One might infer that a named person likes green, but that inference, while specific, is not meaningful because it derives from information about the population at large. In the other, an anonymised historical loan dataset shows that people with certain attributes tend to default, and a bank applies that insight to a new applicant who was never in the dataset. The guidelines treat this as not meaningful in the relevant sense, so the historical dataset can still satisfy the ‘No Inference’ criterion. The principle these examples protect is the boundary between learning about a population and leaking information about a person represented in the source data. General learning does not turn the training material into personal data. 

The guidelines do not, however, treat AI outputs as anonymous by default. They recognise membership inference, where it can be inferred that a particular individual's data were in the original dataset, and they warn that AI models and synthetic data may still permit specific inferences about individuals through querying or prompting. On effectiveness, the guidelines add a useful qualification. A re-identification technique counts only if it is accurate enough to distinguish and treat the individual differently. An inference that cannot, with sufficient confidence, be attributed to the right person is not sufficiently effective. This connects to the Board's separate Opinion 28/2024 on AI models, to which the guidelines refer. 

Record-level and mixed datasets: two rules to watch 

The guidelines set two rules that are easy to miss and costly to get wrong when sharing record-level data. First, on mixed datasets, the Board says a dataset as a whole is anonymous only if anonymisation is effective for all the individuals in it. This does not require an identical level of protection for everyone, but it does require the likelihood of re-identification to be insignificant for each of them. Where a dataset contains a mix of personal and anonymous data and the parts cannot be treated separately, the whole dataset must be treated as personal data. The guidelines draw a comparison with the Court's approach in Meta v Bundeskartellamt (Case C-252/21) to mixed special-category and ordinary data. 

Second, the guidelines state that a re-identification technique can be successful even if it succeeds against only a single individual in a much larger dataset. Taken together, these two rules mean that an average or aggregate view of risk is not enough. If some records remain vulnerable, they must be reliably suppressed or segregated, or the dataset as a whole has to meet the standard. For organisations preparing record-level data for sharing, this is the point at which many otherwise reasonable transformations fail, and it deserves specific attention in the design. 

Contracts and controls: necessary, not sufficient 

Organisations often rely on contractual prohibitions on re-identification to support an anonymisation claim. The guidelines are clear that this is not enough on its own. A contractual prohibition, even where legally binding on the parties, should not be treated as a prohibition by law. Contractual terms may affect which means are reasonably likely to be used, but they should complement technical measures rather than substitute for them, and they must be reliable, verifiable and enforceable, bearing in mind that contracts can be revised or simply disregarded. The guidelines reinforce this in the technical analysis, stating that technical, organisational and contractual measures can help restrict access but are not by themselves sufficient to make data anonymous. 

There is a live tension here that organisations working across regimes should keep in view. In the competition context, the Commission's approach to search-data sharing under Article 6(11) of the Digital Markets Act treats contractual and organisational measures as capable of reducing residual re-identification risk to an insignificant level, which sits less comfortably with the EDPB's position that contracts cannot perform the decisive legal act of anonymisation. The transferable lesson is straightforward. Build anonymisation on technical transformation assessed in context, and treat contractual controls as reinforcement of a technically sound result rather than as the thing that crosses the legal line. 

Anonymisation is not permanent 

The guidelines are explicit that the likelihood of re-identification typically increases over time, as re-identification techniques improve and additional information becomes available. If that likelihood rises to a level that is no longer insignificant, previously anonymous data should again be treated as personal data, and the controller becomes accountable for processing it. The guidelines recommend periodic reassessment wherever possible and appropriate, and they note that a security incident may itself require reassessment where anonymity depended on certain information staying confidential. 

For governance purposes, this is best operationalised as a set of reassessment triggers rather than a vague commitment to review. Sensible triggers include a material security incident, the appearance of a new auxiliary dataset that could enable linkage, a change in who has access to the data or on what terms, a newly validated attack technique, and a move from controlled access to wider release. The guidelines specifically flag that developments in AI, and agentic AI in particular, are likely to reduce the time and cost of running re-identification techniques, which is a reason to keep the state of the art under active review rather than assuming that an assessment made today will hold indefinitely. 

Legal basis, transparency and documentation 

Two further points are easy to overlook because they concern the anonymisation process itself rather than the resulting data. First, anonymisation is processing of personal data, so it needs a legal basis under Article 6 GDPR, and where special-category data are involved, an exemption under Article 9(2) GDPR. The guidelines indicate that, where anonymisation forms part of the same processing activity and pursues the same purpose, the legal basis and any Article 9(2) exemption can be presumed to coincide with those of the preceding processing. 

The guidelines also note that immediate anonymisation combined with deletion of the original data can weigh positively in a legitimate-interest balancing test for the preceding processing. Second, the guidelines caution against misleading labelling. Controllers should not describe data as “anonymous”, “de-identified” or “de-personalised” where individuals remain identifiable, and they should be transparent that personal data are processed to produce anonymous output that then falls outside the GDPR. Finally, the guidelines stress documentation. Recording the anonymisation process, including the testing of the supposedly anonymous dataset, and retaining that record afterwards, is what allows an organisation to demonstrate both that the process complied with the GDPR and that the anonymisation was effective. In practical terms, that documentation is the organisation's principal answer if a supervisory authority later questions whether the data are truly anonymous. 

What this means in practice 

Read together, the guidelines turn anonymisation from a one-off technical transformation into a structured, documented assessment. A defensible exercise now runs through the following steps: 

• Fix the perspective before touching the data. Decide for whom the data are meant to be anonymous, then run the identifiability test from that perspective. This choice shapes everything else, so it comes before any technical work, not after it. 
• Separate genuine recipients from parties acting on your behalf. The same transfer can produce two different answers depending on the relationship. If the recipient processes the data on your instructions, for your purposes, it is a processor, and its position is judged from your perspective. Because you can identify the individuals, the data stay personal for the processor too, even though it cannot identify anyone on its own. If instead the recipient decides its own purposes and means, does not act on your instructions and the data are not routed back to you, it is an independent recipient, and identifiability is judged from its own perspective, so the data may be anonymous in its hands. Labelling a party "independent" does not make it so, so where you rely on genuine independence, make sure the arrangement reflects it in substance and be ready to evidence that. 
• Map the data and what could be combined with it. Set out the records, the attributes, and any additional information that relevant parties hold or could realistically obtain, including through others in a chain. 
• Apply the three criteria, then look harder. Test the ‘No Record Isolation’, ‘No Linkage’ and ‘No Inference’ requirements. Where one fails, analyse what that failure actually enables rather than assuming the data are personal. Check the record-level and mixed-dataset position too. An average level of risk is not enough, and records that remain vulnerable must be suppressed or held separately. 
• Layer your controls, but know which one does the legal work. Technical, organisational and contractual measures work best together, but it is the technical transformation that carries the data across the line. Contract reinforces a sound result, it does not create one. 
• Start from a legal basis, and write everything down. Anonymisation is itself processing of personal data, so it needs a legal basis under Article 6 GDPR, and an Article 9(2) exemption where special-category data are involved. Record the assessment and how the anonymisation was tested, and keep that record. This is what lets you defend the data as being outside the GDPR if challenged.
• Decide in advance what reopens the question. Name the events that trigger a fresh assessment and keep the state of the art, including AI-assisted re-identification, under review. 

Collaborative projects, including EU-funded consortia, raise a further difficulty. Where one partner removes the direct identifiers from a dataset, keeps the key that would allow re-identification, and shares the coded dataset with the others, the legal status of that shared dataset is not the same for everyone who holds it. For a partner with no realistic means of attributing the data to an individual, it may be anonymous and outside the GDPR. For the partner that retains the key, it remains personal data. Establishing which of the two it is, for each partner, is not straightforward where the partners are joint controllers, and it determines how the position should be reflected in the joint controller arrangement, the data protection impact assessment and the data management plan. We address that question, and how the EDPB's guidelines on anonymisation and on the processing of personal data for scientific research apply as data move through a research consortium, in a forthcoming post. 

Where this leaves organisations 

The guidelines are in public consultation and the text may still change, particularly on the treatment of adversaries, foreseeability and singling out. But the contextual approach itself is the settled direction of travel, and organisations that build their anonymisation practice around it, assessing per entity, testing against the three criteria, documenting the result and revisiting it over time, will be well placed whatever the final wording. The central message is that anonymisation has become an exercise in evidence and judgement, not a label. Treated that way, it remains a genuine and valuable route out of the GDPR. Treated as a formality, it will not withstand scrutiny. 

Funding acknowledgement and disclaimer 

The authors are involved in EU-funded projects relevant to digital health, health data and AI-enabled healthcare technologies.

• Nayana Murali participates in the PATH project and the AISYM4MED project. PATH is supported by the Innovative Health Initiative Joint Undertaking (IHI JU) under Grant Agreement No. 101253520. The IHI JU receives support from the European Union’s Horizon Europe research and innovation programme and COCIR, EFPIA, EuropaBio, MedTech Europe and Vaccines Europe. AISYM4MED is funded by the European Union under the Horizon Europe research and innovation programme, Grant Agreement No. 101095387.

• Vaisakh Shaji participates in VOLABIOS and Bigpicture projects. VOLABIOS is funded by the European Union under the Horizon Europe Programme, Grant Agreement No. 101156162. The Health and Digital Executive Agency (HaDEA) is the granting authority. Bigpicture is funded by the European Union under Horizon 2020 programme, Grant Agreement No. 945358. 

Views and opinions expressed in this article are those of the authors only and do not necessarily reflect those of the European Union, the IHI JU, the HaDEA, or any other relevant granting authority. Neither the European Union, IHI JU, HaDEA nor any other relevant granting authority can be held responsible for them.