Pseudonymised data is personal data and every GDPR obligation still applies to it. Anonymised data is not personal data and the regulation does not apply at all. That is the entire distinction, and it is worth more than any other definitional point in the regulation, because it decides what you may keep, for how long, and whether anyone can ask you to delete it. The test is not whether you hold the key. It is whether re-identification remains reasonably possible for anyone.
This article covers what each term means in the text, the standard Recital 26 sets for anonymity, the three risks a technique has to defeat, why hashing an email address does not anonymise it, and where pseudonymisation genuinely pays off despite keeping you in scope.
What The Regulation Actually Defines
Only one of these terms is defined in the GDPR. Article 4(5) defines pseudonymisation as processing personal data in such a way that it can no longer be attributed to a specific data subject without the use of additional information, where that additional information is kept separately and is subject to technical and organisational measures ensuring non-attribution.
Read the shape of that. It assumes the additional information continues to exist. Pseudonymisation is a way of holding data such that the link is broken in the dataset while the means to restore it are held apart. Separation, not destruction.
Anonymisation is not defined in the articles at all. It appears in Recital 26, which says the principles of data protection do not apply to anonymous information — information that does not relate to an identified or identifiable person, or personal data rendered anonymous in such a way that the data subject is not or no longer identifiable. Recital 26 also disposes of a common misconception directly: pseudonymised data which could be attributed to a person by the use of additional information should be considered information on an identifiable person.
So the two are not points on a scale. Pseudonymisation is a security and risk-reduction measure that happens inside the regulation. Anonymisation is an exit from it. Article 32(1)(a) names pseudonymisation alongside encryption as an example of an appropriate security measure, which is exactly where it belongs and exactly what it is — the same list our article on whether GDPR requires encryption works through.
"Reasonably Likely To Be Used" Is The Real Test
Recital 26 sets the standard for identifiability, and it is broader than most teams apply.
To determine whether a person is identifiable, account should be taken of all the means reasonably likely to be used to identify them, either by the controller or by another person. Whether means are reasonably likely to be used is judged against objective factors: the cost and time required, the technology available at the time of processing, and technological developments.
Two things in that sentence do a great deal of work.
"Or by another person" means your own capabilities are not the test. If you delete the mapping table but your analytics vendor, your data warehouse, or a public dataset would let someone else re-link the records, the data is not anonymous. The question is not "can we identify these people," it is "could anyone, using means reasonably likely to be used."
"Technological developments" means the assessment has a shelf life. A dataset that was genuinely anonymous under 2018 conditions may not be under current ones, particularly where the identifying route is a combination with data that did not exist publicly at the time.
The practical effect is that anonymisation is a high bar and an irreversible one. If you can get back, you did not anonymise. And because it is irreversible, it is the only route to keeping a dataset indefinitely — storage limitation under Article 5(1)(e) does not apply to data that is no longer personal.
The Three Risks A Technique Has To Defeat
European regulators assess anonymisation techniques against three distinct risks, set out in the Article 29 Working Party's Opinion 05/2014 on Anonymisation Techniques and still the working framework. A technique only anonymises if it addresses all three. Defeating two is common and insufficient.
Singling out is the possibility of isolating records corresponding to one individual, even without a name — and it is the one risk Recital 26 names in the regulation's own text. A dataset where one row can be picked out as belonging to one person has not anonymised that person — you know there is someone, you know what they did, and that is enough to keep it in scope.
Linkability is the possibility of connecting two records relating to the same individual, whether within your dataset or between yours and another. Any stable identifier creates linkability, whatever it is made of, because the whole point of a stable identifier is that it matches.
Inference is the possibility of deducing an attribute with significant probability from other values. A dataset with no direct identifiers can still support a confident inference about a specific person if the combination of quasi-identifiers is narrow enough.
This is why removing the name column is not anonymisation. Postcode plus date of birth plus job title will frequently identify exactly one person, and no direct identifier was involved. Aggregation helps only when the group sizes are large enough that no cell describes an individual — a count of one is a person.
Why Hashing An Email Address Is Not Anonymisation
This is the single most common mistake in this area, and it is worth stating plainly: hashing produces pseudonymised data, not anonymous data.
Two reasons, and either is fatal on its own.
Hashes are deterministic. The same input always produces the same output, which is exactly why hashed identifiers are useful for matching and joining — and matching is linkability. A stable hash is a stable identifier, functionally identical to a customer number for the purpose of this test.
And the input space is small enough to search. Email addresses are not random. Common formats, known domains and existing breach corpora make reversing a hash of an email address a matter of computation rather than cryptanalysis. Adding a salt held by you improves security substantially and changes nothing about scope, because you still hold the salt, which is precisely the "additional information kept separately" of Article 4(5).
The same logic applies to encryption. Encrypted personal data is pseudonymised while the key exists, not anonymous. And in-product data scrubbing follows the pattern too — an error monitoring tool that strips personal data before events leave your infrastructure is doing valuable and genuine risk reduction, but what remains is minimised data rather than anonymous data. Our article on Sentry and what ends up in your error logs works through where that scrubbing actually happens in one such tool, which is the thing that determines how much it is worth.
Where Pseudonymisation Pays, Even Though You Stay In Scope
None of this makes pseudonymisation a consolation prize. The regulation rewards it in several concrete places.
It is named in Article 25 as a means of implementing data protection by design, and in Article 32(1)(a) as an appropriate security measure. It is relevant to the compatibility assessment under Article 6(4) when you want to use data for a new purpose. It reduces the severity of a breach, which affects both your risk assessment and what you have to tell people. And Article 11 provides that where you can no longer identify a data subject, you need not acquire additional information purely to comply — though the individual can supply information enabling identification, at which point the rights apply again.
There is a straightforward operational case too. Pseudonymised production data is what lets analytics, debugging and testing happen with meaningfully lower exposure, without pretending you have left the regulation behind.
The distinction matters commercially in one more way worth naming. "We anonymise the data" appears constantly in privacy notices, DPAs and questionnaire responses, and it is very often untrue as written. It is a statement about legal scope, it is checkable, and a customer's legal team will check it. If the mapping table still exists anywhere, the honest word is pseudonymised, and using the honest word costs you nothing except a sentence of explanation. A recording, a masked session or a hashed identifier all sit on the same side of the line — as does the question of whether a session replay has been anonymised by masking, which it has not.
Common Mistakes With Anonymisation And Pseudonymisation
Calling hashed identifiers anonymous. A hash is a stable identifier and therefore supports linkage. Salting improves security and does not change the answer, because you hold the salt.
Removing direct identifiers and stopping there. Quasi-identifiers routinely single people out in combination. The test is whether one record can be isolated, not whether a name column is present.
Assessing identifiability only from your own position. Recital 26 asks what means are reasonably likely to be used by anyone, including your vendors and anyone holding a dataset that joins to yours.
Keeping the mapping table "just in case." Retaining the key is the definition of pseudonymisation. A dataset described as anonymised while a re-identification route sits in a separate system is a mislabelled dataset and, if it appears in a contract, a misstatement.
Treating aggregates as automatically safe. Small cells identify individuals. A count of one, or a breakdown fine enough that one group has a single member, has not anonymised anybody.
FAQ
Is a hashed email address personal data under GDPR?
Generally yes. Hashing produces a stable identifier that supports linkage between records, and the limited input space of email addresses makes reversal feasible with available resources. It is a useful pseudonymisation technique and a real risk reduction, but the data stays in scope with all rights attached.
Is encrypted data anonymous?
No, not while a key exists that could reasonably be obtained. Encryption is a security measure, and encrypted personal data is pseudonymised rather than anonymous. If the key were destroyed irretrievably and no other route to re-identification existed, the analysis could differ — but that is data destruction, not a data strategy.
Can we keep anonymised data forever?
Yes. Storage limitation under Article 5(1)(e) applies to personal data, and genuinely anonymous information is not personal data. That is the main commercial reason to do the work properly. It is also why the claim gets made far more often than it is true.
Does pseudonymisation reduce our GDPR obligations?
It reduces risk rather than obligations. Every requirement still applies — lawful basis, retention, access and erasure rights, records of processing. What pseudonymisation does is lower the severity of a breach, count in your favour under Articles 25 and 32, and support a compatibility assessment for further processing.
Closing Thought
The reason this distinction is worth the attention is that anonymisation is the only genuine exit the regulation offers, and almost nobody who claims to have used it has. Everything else — encryption, hashing, masking, tokenisation, dropping the name column — reduces risk while leaving you exactly where you started, in scope, with retention limits and erasure obligations intact.
That is not a failure of those techniques. It is a reason to be precise about which one you actually did, particularly in the documents where you told a customer which one it was.
ComplyDog keeps the records that depend on getting this right — your records of processing activities, which have to state what data you hold and how long you keep it, your subprocessor list, and your DPAs — in one portal hosted on your own domain. You can try it free for 14 days, no credit card required.
