Anonymous data now needs a three-test file

“We removed the names” is not an anonymisation assessment. It is one transformation, and often the least difficult one to reverse when the remaining rows still describe people in detail.

On 7 July, the European Data Protection Board adopted draft Guidelines 02/2026 for public consultation. The text gives organisations a practical framework for deciding whether information has actually become anonymous and therefore falls outside the GDPR. The consultation runs until 30 October, so this is guidance in formation rather than a final checklist. Its operational message is already clear: anonymity is a claim about what relevant people can do with the data, not a label attached after an export.

For a small company, the useful output is not a new policy. It is a short file that records who will receive the dataset, what other information they can reach and whether the data passes three tests: no record isolation, no linkage and no inference.

Start with the recipient

The EDPB begins with two legal questions. Does the information relate to a natural person? If it does, is that person identified or identifiable? A “no” to either can make the information anonymous, but the answer may differ from one entity to another.

That perspective is the first practical change to a typical export review. A customer-analysis table might be anonymous for a university receiving only coarse statistics, yet remain personal for the company that keeps the customer table and the key used to produce them. A public release creates a wider set of relevant perspectives than a tightly controlled transfer to one research partner.

The Court of Justice made that context visible in C-413/23 P, EDPS v SRB. The dispute concerned pseudonymised comments transferred by the Single Resolution Board to Deloitte. The Court held that, for the information duty at issue, the nature of the data had to be assessed from the controller’s perspective when the data was collected. The recipient’s inability to identify people did not erase the controller’s earlier obligation to name the recipient.

Before testing a dataset, write one sentence:

The data is intended to be anonymous for [named recipients or public audience] while used for [purpose].

If the sentence cannot be completed, the assessment has no boundary. “Anonymous for us” says nothing about a processor with richer logs, a partner with a customer list or a public user able to combine the release with open records.

Three tests replace the label

The draft framework retains and refines three ideas from the Article 29 Working Party’s 2014 opinion. Passing all three allows the data to be treated as anonymous under either the contextual approach, which considers each relevant entity’s capabilities, or a more conservative simplified approach that does not distinguish between them. Failing one test does not automatically settle that the data is personal, but it requires further analysis.

Test	Operational question	Common warning sign
No record isolation	Can one person’s record be singled out through a unique combination of values?	Exact age, postcode, job and event time form a unique row
No linkage	Can the record be matched to the same person in another dataset?	Stable IDs, rare attributes or matching timestamps exist elsewhere
No inference	Can specific, meaningful information about one person be deduced?	A group statistic reveals a sensitive fact about its only plausible member

Source: EDPB Guidelines 02/2026, sections 3.4–3.5. Last verified 2026-07-15.

Record-level data with many columns and fine detail is particularly difficult. The EDPB calls these properties dimensionality and resolution. A full birth date carries more resolution than a birth year; a row containing location, occupation, purchase history and device details has more dimensions than a regional monthly total. Removing the direct identifier does not remove the pattern.

The smallest useful test is to look for uniqueness before choosing an elaborate method. Map the columns, count unusual combinations and list the external data a realistic recipient could use. If the export contains a single night-shift worker in a small postcode, a customer number replaced with a random string will not make the surrounding facts disappear.

Encryption is access control

Several controls can reduce risk without producing anonymous data. Pseudonyms separate a working identifier from a name. Encryption restricts who can read a file. Contracts prohibit recipients from attempting re-identification. Access controls limit which staff can open the source table.

Those measures matter, but the draft warns against treating them as the conclusion. Encryption is designed to be reversible. A contractual ban complements technical measures but can be revised or ignored. A processor may lack the key while the controller still holds it. In each case, the organisation should ask whether someone in the relevant chain can use means reasonably likely to identify a person.

This distinction affects ordinary decisions. Truly anonymous statistics can fall outside the GDPR. Pseudonymised records remain personal data and keep the GDPR safeguards that apply to their processing. Calling the second category the first can remove the very controls that make the transfer defensible.

For an SME, a conservative classification is often cheaper than a disputed one. If the business still needs row-level detail, stable identifiers or the ability to reconnect results to customers, treat the dataset as personal, minimise it and secure the transfer. Reserve the anonymity claim for an output whose usefulness does not depend on reversing it.

One weak row keeps the file in scope

An export can contain mostly safe aggregates and one vulnerable subgroup. The draft says a dataset as a whole should only be considered anonymous when anonymisation is effective for every included individual. If anonymous and personal parts are not handled separately, the whole dataset should be treated as containing personal data.

That makes small groups the place to start. A national total may reveal nothing, while the same table split by municipality, age band and rare condition produces cells containing one or two people. The risk is not evenly distributed, and an average score can hide it.

A practical release check should therefore include:

• the smallest groups and rarest combinations;
• the columns most likely to appear in another dataset;
• exact dates, coordinates and free-text fields;
• records linked to public roles or unusual events;
• the additional information held by each recipient;
• whether the original and any lookup key still exist, and who controls them.

Delete fields that do not serve the release purpose before testing. Generalise exact values where the purpose allows it. Aggregate rows when individual-level analysis is unnecessary. Then repeat the three tests on the output, not on the intended design.

Keep a one-page assessment

The EDPB does not require a branded anonymisation certificate. A small team can leave a useful audit trail in one page or one ticket:

1. Dataset and purpose: the exact export, version and intended use.
2. Relevant entities: who holds, receives or may realistically access it.
3. Additional information: keys, source tables and external datasets available to those entities.
4. Three-test result: isolation, linkage and inference, including the weakest record or group.
5. Decision and controls: anonymous or personal, with the transformations and access limits applied.
6. Review trigger: a new recipient, data leak, richer external source, method change or fixed review date.

The last line matters because anonymity can decay. The draft notes that re-identification becomes more likely as techniques improve and more outside information becomes available. It does not demand that every assessment completed under the 2014 opinion be rerun merely because these guidelines appeared, but it calls periodic reassessment good practice.

The immediate task is smaller. Choose one dataset currently described as “anonymous”, name who it is supposed to be anonymous for and test its most distinctive row. If the team cannot explain why that row resists isolation, linkage and inference, restore the personal-data controls before the next transfer.