Pseudonymization vs Anonymization Under GDPR

The difference between pseudonymized and anonymized data is the difference between being inside the GDPR and being outside it. Anonymous data is not personal data, so none of the regulation applies: no lawful basis, no retention limit, no subject access, no transfer restriction. Pseudonymized data is personal data with a good security control attached, and every obligation still stands.

Teams get this wrong in a predictable direction. A masking job runs, the names come out, and the dataset gets relabelled “anonymized” in a data map. The legal position has not moved at all. This is where the line actually sits, what changed in 2025, and what it means for the tooling decision.

What the regulation says

Two definitions in GDPR Article 4 do the work.

Personal data is any information relating to an identified or identifiable natural person, where identifiable means the person can be singled out directly or indirectly, in particular by reference to an identifier.

Pseudonymisation is processing personal data so it can no longer be attributed to a specific person without the use of additional information, provided that additional information is kept separately and subject to technical and organisational measures. The definition contains its own answer: if separately held information can restore the link, the data is still personal data.

Anonymisation is not defined in the articles at all. It appears in Recital 26, which sets the test: information is anonymous when the data subject is not or no longer identifiable, and identifiability is judged by reference to all the means reasonably likely to be used, accounting for cost, time, available technology and technological development. It is a risk test, not a technique checklist, and it is assessed against the state of the world rather than the intent of the person running the transformation.

Three consequences follow immediately:

• Pseudonymisation is a safeguard, not an exit. The GDPR names it as an appropriate measure for data protection by design and for security of processing, and as a factor in whether a new purpose is compatible with the original one. Those are all obligations that only exist because the data is still in scope.
• Hashing an identifier is pseudonymisation, not anonymisation, whenever the input space is small enough to enumerate. Hashed email addresses and hashed phone numbers are re-identifiable by anyone with a dictionary.
• Removing direct identifiers while leaving quasi-identifiers intact fails the singling-out test. Postcode, birth date and job title routinely identify a person on their own.

What the CJEU changed in 2025

For years the working assumption among data protection authorities was that pseudonymised data is always personal data, full stop, for everyone who holds it. The Court of Justice narrowed that in EDPS v SRB, Case C-413/23 P, decided on 4 September 2025.

The facts are unusually clean. The Single Resolution Board collected comments from affected shareholders and creditors, replaced the identifying details with codes, and sent the coded comments to Deloitte for valuation work. The Board kept the key. Deloitte never received it and had no other route to the identities. The question was whether what Deloitte held was personal data.

The Court held that this depends on the circumstances, assessed from the position of the recipient. Data that is personal data in the hands of the controller who holds the re-identification key may not be personal data in the hands of a recipient who cannot reverse the pseudonymisation and cannot identify the individuals by any other means reasonably likely to be used. The Court also confirmed that opinions and personal views expressed by an individual are personal data in themselves, so the content mattered as much as the identifiers.

What this does not license:

• It does not make pseudonymised data anonymous for the controller. The Board’s copy remained personal data throughout.
• It does not create a category of “anonymised by transfer”. The recipient’s position has to be assessed on evidence, not assumed, and a recipient with plausible auxiliary data fails the test.
• It does not remove the transfer itself from scope. The act of disclosing personal data to a recipient is processing by the controller, and it needs a basis.

The practical value of the ruling is narrow and real: a contextual, recipient-relative assessment is legitimate, so a properly separated key and a recipient with no realistic re-identification route can change the analysis downstream. It rewards documentation of exactly who holds what.

What the EDPB expects

The EDPB adopted Guidelines 01/2025 on Pseudonymisation on 16 January 2025, ahead of the judgment, and the two fit together better than the timing suggests. One caveat before relying on them in a filing: this is the version opened for public consultation, which closed at the end of February 2025, and no final text has replaced it. Treat it as the Board’s stated direction rather than as settled guidance, and expect the wording to move.

The guidelines build the analysis around a pseudonymisation domain: the set of parties who are meant to be unable to attribute the data to individuals, with the controller and the holders of the additional information sitting outside it. Within the domain, the data is pseudonymised and remains personal data. The design question becomes who is inside the domain, what they hold, and what stops them from combining it.

Three expectations are worth carrying into a design review:

• The additional information must be genuinely separated. Separation means access controls, key management and organisational division, not a second column in the same table.
• The pseudonyms must not leak. A pseudonym derived deterministically from the identifier without a secret is reversible by anyone who can compute the same function. Keyed constructions and lookup tables held outside the domain are the ways out.
• The residual data must be assessed. Even with perfect pseudonym design, the remaining attributes may single someone out. This is the failure mode that masking tools do not detect, because they were never asked to.

Where AI models sit

For anyone training on personal data, the relevant guidance is EDPB Opinion 28/2024, which addresses whether a trained model is itself anonymous. The Board’s answer is that a model trained on personal data is not automatically anonymous and the claim has to be assessed case by case, with evidence: the likelihood of extracting the training data from the model, and the likelihood of obtaining personal data through queries, both need to be insignificant.

That places model-level attacks squarely inside the compliance analysis rather than beside it. If a membership inference attack can establish that a person’s record was in the training set, the model is carrying personal data regardless of what happened to the training file. Extraction results against large language models make the same point from the other direction. The obligations that attach when a model is found to hold personal data, including erasure requests, are covered in training-data privacy and data-subject rights against AI models.

Mapping techniques to the two categories

Technique	Category	Why
Tokenisation with a retained key	Pseudonymisation	The key restores the link by design
Unsalted hashing of identifiers	Pseudonymisation	Small input spaces are enumerable
Keyed hashing, key held outside the domain	Pseudonymisation	Reversible by the key holder
Deterministic masking preserving joins	Pseudonymisation	Consistency across tables is a linkage
Suppression of direct identifiers only	Neither, usually	Quasi-identifiers still single people out
k-anonymity with l-diversity, assessed	Potentially anonymisation	Depends on the risk assessment, not the parameter
Differential privacy with a stated budget	Potentially anonymisation	Bounded leakage, with the bound documented
Synthetic data from a generative model	Depends entirely on the model	Memorised outliers can reproduce real records

The pattern is that no technique earns the anonymisation label on its own. The two rightmost cases get there only when a risk assessment supports the conclusion, which is why tooling that reports re-identification risk is worth more than tooling that only transforms. Which tools do which is set out in the comparison of open source anonymization tools, and the technique-level detail for ML pipelines is in how to anonymize training data. The synthetic-data case has its own failure modes, examined in the privacy-first comparison of synthetic data generation tools.

A defensible anonymity claim

If a dataset is going to be labelled anonymous and treated as out of scope, the file backing that decision should contain five things:

1. The identifiability analysis. Which attributes were treated as quasi-identifiers, and why that list is complete for this population.
2. The auxiliary data assumed available. Public registers, previous releases, leaked datasets and anything the recipient already holds.
3. The measured residual risk. A number produced by a tool that computes one, before and after transformation.
4. The utility loss accepted. Evidence that the transformation was not quietly weakened to protect a downstream metric.
5. A review date. Recital 26 refers to technological development, which means an assessment made three years ago has an expiry the regulation anticipates.

Absent that file, the safer position is to treat the dataset as pseudonymised and keep the obligations. That is the more conservative call, and it is the one that survives a regulator asking to see the reasoning. To check which regimes reach a specific deployment before making the call, the interactive applicability wizard maps a deployment to the GDPR, EU AI Act and US state duties that attach to it.

Related across the network

• Membership Inference vs. Model Inversion: Privacy Attacks — adversarialml.dev
• Training Data Extraction from LLMs: The Carlini Results Explained — adversarialml.dev
• Model Inversion Attacks: Reconstructing Training Data from Output — adversarialml.dev