Anonymization vs pseudonymization under GDPR, explained

Pseudonymisation replaces direct identifiers with codes or tokens but keeps a way to link the data back to a person, so under the GDPR it is still personal data. Anonymisation removes the ability to identify anyone by any means reasonably likely to be used. Genuinely anonymous data falls outside the GDPR, but the bar is high.

This is general information and not legal advice, and it focuses on the GDPR as a common reference point. Other laws use different definitions, and the legal tests are applied case by case, so speak to a qualified lawyer or data protection specialist before you rely on any claim that data is anonymous.

What does pseudonymisation mean?

Pseudonymisation means processing personal data so that it can no longer be attributed to a specific person without additional information, which is kept separately and protected. The GDPR recognises it as a safeguard, but it still treats the result as personal data.

A typical example is replacing a customer's name and email with a random ID, while a separate lookup table keeps the mapping. The dataset on its own does not name anyone, but whoever holds the table can reverse the step. A hashed email address is a common case: it looks anonymous, but if someone can hash a list of known emails and compare, it can often be reversed.

The value of pseudonymisation is risk reduction. It limits exposure if the data leaks, helps with data minimisation and can support the case for processing. It does not remove the data from the regulation, and a seller who treats pseudonymised data as anonymous is making a serious mistake.

What does anonymisation mean?

Anonymisation means turning personal data into data that no longer relates to an identifiable person, in a way that cannot be reversed by means reasonably likely to be used. If that standard is met, the GDPR does not apply to the resulting data.

The test looks at identifiability in practice. It considers all the means reasonably likely to be used, by the data holder or someone else, to identify a person, taking into account cost, time and available technology. That is deliberately a high and context-dependent standard, not a checklist.

There is a second nuance. Anonymising personal data is itself an act of processing, so the original data needs a lawful basis for that step, even if the output is anonymous. This is one reason legal review upstream of the technical work is worthwhile.

What are the key differences at a glance?

The main differences are reversibility, legal status and what you can safely do with the result. Reversibility is the crux.

• Reversibility: pseudonymised data can be re-linked using additional information; anonymised data cannot, in practice.
• Legal status under the GDPR: pseudonymised data remains personal data; truly anonymous data is outside the regulation.
• Obligations: with pseudonymised data you still need a lawful basis, transparency, security and respect for individual rights; with anonymous data these do not apply to the output.
• Utility: pseudonymised data keeps more analytical value, such as linking records over time; anonymised data often loses detail.
• Risk: pseudonymised data carries re-identification risk if the key or other data is exposed; anonymised data carries risk only if the anonymisation was not as strong as believed.

Many practitioners also describe a spectrum rather than a binary. Data can be more or less identifiable, and the label "anonymous" is a conclusion about the risk, not a technique.

How hard is it to achieve real anonymisation?

It is harder than most people expect, particularly with rich, text-heavy or behavioural data. Removing names and email addresses is rarely enough.

Identification can happen through combinations of ordinary details such as location, job title, dates and unusual events. It can also happen through writing style or specific content, for example a support conversation that mentions a rare product configuration and a small town. The usual concerns are singling out an individual, linking records about the same person across datasets, and inferring facts about a person from the data.

Free text is the hardest case. Support transcripts, emails and documents contain names, account numbers and personal stories in unpredictable places, and automated scrubbing misses some. If your dataset is free text, expect to need layered controls and not just a single pass. The practical steps are discussed in how to de-identify company data before selling it.

Which techniques are used, and what do they achieve?

Techniques vary in strength, and most reduce risk without guaranteeing anonymity. Choose them according to the data type and the use.

Techniques that usually pseudonymise

Tokenisation, encryption with a retained key, keyed hashing and replacement with consistent IDs all preserve the ability to re-link records. They are useful, but you should treat the output as personal data.

Techniques that can contribute to anonymisation

Removing or generalising fields, aggregating, suppressing small groups, adding noise and generating synthetic data can all move data toward anonymity. Whether any one method gets you there depends on the data and the context. Combining techniques and testing for re-identification risk is generally sounder than relying on one.

Why testing matters

A claim of anonymity should come with an assessment of how someone might attack the dataset. That includes trying to match records against public or purchasable data, which is how many published re-identification cases have worked. A documented assessment also helps if a regulator or buyer asks how you reached your conclusion.

What does this mean if you want to sell data?

If you sell pseudonymised data, you are likely still dealing in personal data, which brings obligations around lawful basis, transparency, security and, often, contracts with the buyer. If you sell data you believe is anonymous, you carry the risk that the belief is wrong.

Buyers, particularly AI teams that care about legal risk, will ask how the data was prepared and what they are being promised. Honest descriptions beat grand claims. Say what was removed, what remains, what you tested and what residual risk you accept, and avoid labelling the data "anonymous" unless you have a basis for it.

Contracts should reinforce the technical steps. A buyer should promise not to attempt re-identification or linkage to other data, and to keep any residual personal data secure. These points belong in the data license agreement, and they are more credible when they match what the data actually looks like.

Who is responsible once the buyer has the data?

Responsibility depends on the roles each party plays and on the law that applies, and a contract cannot remove duties the law imposes. If the data is personal data, both sides may have obligations, and a buyer who combines it with other data can change the risk profile considerably.

For that reason a seller should think about the buyer's likely use before agreeing. A buyer who holds large amounts of other data about the same people is better placed to re-identify records than one who does not. Limits on linkage, restrictions on onward transfer and security duties are the contractual response. They are not a substitute for preparing the data properly in the first place.

If a buyer asks you to confirm that data is anonymous, give an answer you can stand behind. A narrow statement of what you did and tested is safer than a broad promise that no one could ever identify anyone.

Be careful, too, about the word "anonymised" in marketing material. Using it loosely in a listing or a pitch can create a misleading impression, and in a dispute it may be read as a promise. Prefer precise descriptions such as "names, emails and phone numbers removed; free text scanned and redacted; residual risk assessed" over a single reassuring label.

What is a sensible workflow before you list?

Work from the legal question first and the technical question second. Decide whether you may use the data for this purpose at all, and only then decide how to prepare it.

1. Identify which fields and free-text areas could relate to a person, directly or indirectly.
2. Decide whether the data can be shared at all for this purpose, and on what lawful basis, if personal data is involved.
3. Choose the preparation approach: remove, generalise, pseudonymise, aggregate or synthesise.
4. Apply it, then test for residual identifiers with sampling and, where proportionate, attempts to re-identify.
5. Document the method, the residual risk and the decisions made.
6. Describe the data accurately in the listing and the contract, including any limits on use.
7. Review the outcome periodically, since new data sources and techniques can change the risk over time.

Step seven is easy to skip. Whether data counts as anonymous can change as other datasets become available, so a one-off conclusion is not permanent.

What about other laws and sectors?

Other laws define de-identification differently, and sector rules can be stricter. A technique that satisfies one definition may not satisfy another.

US state privacy laws, for example, use terms such as de-identified and aggregate data with their own conditions, and health data has its own regime. For HIPAA, the approach is covered in HIPAA de-identification: Safe Harbor vs Expert Determination. If the data crosses borders, local rules in each country matter too, as discussed in cross-border data licensing basics.

Do not assume that preparing data for one law makes it acceptable under all of them. Match the preparation to the strictest rule that realistically applies to your parties and data.

Frequently asked questions

Is pseudonymised data personal data under the GDPR?

Yes. Pseudonymised data can still be attributed to a person using additional information, so the GDPR continues to apply to it. Pseudonymisation is a recognised safeguard that reduces risk, but it does not take the data outside the regulation. Treat it as personal data unless you have a sound basis to conclude otherwise.

Can I call data anonymous if I removed names and emails?

Usually that is not enough. Other fields, combinations of details and free text can still identify people, and the test considers means reasonably likely to be used. Assess re-identification risk properly, document it, and avoid describing the data as anonymous unless you can support the claim.

Is hashing the same as anonymisation?

Not generally. Hashing an identifier such as an email address can often be reversed by hashing a list of candidates and comparing the results. Hashing is usually considered a pseudonymisation technique. Its effectiveness depends on how it is done, so do not rely on it alone to make data anonymous.

Does synthetic data avoid these issues?

Not automatically. Synthetic data that closely reproduces real records can leak information about the people in the source data, and generating it still involves processing the original data. Well-designed synthetic data can reduce risk considerably, but it needs testing. The comparison of synthetic and real data goes into more detail.

Do I need legal advice before selling pseudonymised data?

It is wise. Selling pseudonymised data usually involves personal data, so lawful basis, transparency and contracts matter, and requirements vary by country. A qualified adviser can help you decide whether the sale is permissible and how to structure it. It is better to ask before listing than after a complaint.