Pseudonymisation vs Anonymisation: 6 Proven GDPR Rules

Pseudonymisation does not take data out of the GDPR. Anonymisation does. Almost every costly mistake in this area starts with treating the two as points on the same scale rather than as different legal outcomes.

The Regulation is unusually clear about it, in one recital most people have read past.

What pseudonymisation actually means

Article 4(5) defines it as processing personal data so that they can no longer be attributed to a specific data subject without the use of additional information — provided that the additional information is kept separately and is subject to technical and organisational measures ensuring non-attribution.

Three conditions, and the second and third are the ones audits fail on. A key stored in the same database as the data it unlocks is not kept separately. A mapping table that every analyst can read is not subject to measures ensuring non-attribution. In both cases the processing does not meet the definition, whatever the design document says.

Pseudonymised data is still personal data

Recital 26 states it directly: personal data which have undergone pseudonymisation, and which could be attributed to a natural person by the use of additional information, should be considered to be information on an identifiable natural person.

So every obligation still applies. Lawful basis, transparency, retention limits, subject access, breach notification, records of processing — all of it. Pseudonymisation changes the risk, not the scope.

That is not a disappointment, it is the point. Recital 28 says the application of pseudonymisation can reduce the risks to the data subjects concerned and help controllers and processors to meet their data-protection obligations — and adds that its explicit introduction is not intended to preclude any other measures of data protection. It is a control that makes compliance cheaper and breaches less severe. It is not an exemption.

The test for anonymisation is harder than people expect

Recital 26 sets the threshold for leaving the Regulation entirely: the principles do not apply to anonymous information, or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable.

To decide whether someone is identifiable, account must be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person.

Two phrases do most of the work.

“Singling out.” Identification does not require a name. If a record can be isolated as belonging to one individual — a unique combination of postcode, job title and start date will often do it — the person is identifiable. Removing direct identifiers rarely defeats this on its own.

“Or by another person.” The test is not what you could do. It includes what a recipient, a partner or an attacker could do with data they hold and you do not. A dataset that is anonymous inside your organisation may not be anonymous once published.

Anonymisation is a claim with an expiry date

The recital goes further. Assessing whether means are reasonably likely to be used requires considering all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments.

Costs and time fall. Technology advances, and the Regulation says so expressly. An anonymisation assessment made against the compute and datasets of five years ago does not automatically describe today.

The practical consequence: treat an anonymisation decision as a dated assessment with a review point, in the same way you treat a risk assessment. If you cannot produce the reasoning and the date, you have an assertion rather than a determination — and the burden of showing data fell outside the Regulation sits with you.

Where pseudonymisation earns its place

The Regulation names it in four operative provisions, and each is a distinct benefit worth claiming:

• Article 32(1)(a) — pseudonymisation and encryption appear together as security measures appropriate to the risk.
• Article 25(1) — it is the named example of a data protection by design measure implementing data minimisation.
• Article 6(4)(e) — the existence of appropriate safeguards, which may include encryption or pseudonymisation, is weighed when deciding whether further processing is compatible with the original purpose.
• Article 11 — where the purposes no longer require identification, the controller is not obliged to maintain, acquire or process additional information just to identify data subjects.

Article 6(4)(e) is the commercially useful one. It is often what makes analytics or model training on data collected for another purpose defensible — not because pseudonymisation grants permission, but because it is a safeguard the compatibility assessment can weigh.

Recital 29 adds a point teams get wrong: pseudonymisation measures should be possible within the same controller, whilst allowing general analysis, where the additional information is kept separately with appropriate measures. You do not need to hand data to a third party to benefit.

How to decide which you have

1. Can anyone re-identify with information you hold? Then it is pseudonymised, and in scope.
2. Could a recipient single out an individual using data they hold? Then it is not anonymous, whatever you removed.
3. Is the key genuinely separated, with access controls of its own? If not, you do not even have pseudonymisation.
4. Have you written down the reasoning and the date? An anonymisation claim without an assessment is not defensible.

How pseudonymisation connects

Where to start

1. Audit where your keys live, since separation is a condition of the definition, not a nicety.
2. Stop describing pseudonymised datasets as anonymous in policies and contracts — the wording gets quoted back at you.
3. Test for singling out, not just for names, before releasing anything as anonymous.
4. Assess the recipient’s data too, because the test includes what another person could do.
5. Date and diarise anonymisation assessments, given what the recital says about technological developments.
6. Claim Article 6(4)(e) explicitly in compatibility assessments where you rely on it.

This guide reflects Regulation (EU) 2016/679 as published on EUR-Lex, read at 16 August 2026. Supervisory authority guidance on anonymisation techniques develops separately — check your regulator’s current position before releasing a dataset.

The GDPR Toolkit provides 100+ editable templates covering the records of processing, the DPIA, the technical and organisational measures register and the assessments that have to record a pseudonymisation or anonymisation decision.