What is pseudonymization?

By Weapp · Updated 2025-08-25

Pseudonymization is replacing direct identifiers, like names and ID numbers, with codes so the data no longer points to a person without a separate key. The key still exists, which means the data still counts as personal data and falls under GDPR. It lowers the risk but doesn't exempt you from the rules.

Pseudonymization sounds technical, but the idea is simple, and the term comes up as soon as a system needs to handle personal data more safely. It’s often confused with anonymization, and that mix-up can get expensive. Here’s what pseudonymization actually is, and why that distinction matters.

What pseudonymization is

Pseudonymization means replacing the data that directly points to a person – name, ID number, email – with codes or pseudonyms. Instead of “Anna Svensson,” the data shows “AB-4471.” The relationships between the rows remain, but who each row belongs to is no longer apparent from the data itself.

The link between the code and the real person instead lives in a separate key. With the key, you can restore who is who; without it, you only see the codes. That key is the entire point – and it’s what makes pseudonymization fundamentally different from making data anonymous.

The decisive difference from anonymization

This is where most people trip up. Anonymization and pseudonymization sound alike, but in the eyes of the law they’re opposites.

With anonymization, the link is cut for good. There’s no key, no way back, and the data can no longer be tied to a person by anyone. Then it’s no longer personal data, and GDPR doesn’t apply.

With pseudonymization, the key still exists. As long as someone – you, a vendor, anyone – can recreate the link, the person is still identifiable. That’s why the data remains personal data, and the entire framework applies. The rule of thumb: if the data could in theory be linked back, it isn’t anonymous.

A practical example: test data and AI training

Take a common case. A development team needs realistic data to test a new system, or to train an AI model. Letting them work against live customer data is needlessly risky – but entirely made-up data doesn’t behave like reality.

The solution is often pseudonymization. The customer register is run through a process that swaps names, ID numbers, and emails for codes, while the structure and relationships are preserved. The developers get data that looks and behaves like the real thing, without knowing who each record belongs to. The risk drops substantially, while the tests or the model stay meaningful.

But – and this is the usual trap – the team sometimes assumes the pseudonymized copy is “de-identified” and therefore free of GDPR. It isn’t.

Because the key exists, the people are still identifiable, and that makes the data personal data under the law. That has concrete consequences:

You still need a lawful basis to process it, even for testing or training purposes.
The requirements for security, access control, and retention apply to the pseudonymized data just as they do to the original.
A breach of pseudonymized data is still an incident that may need to be reported.

What GDPR does do, on the other hand, is explicitly reward pseudonymization as a safeguard. It lowers the risk, can soften the consequences of a breach, and counts in your favor when the authority assesses how responsibly you’ve handled the data. So the point isn’t that the measure is ineffective – quite the opposite – but that it isn’t a safe zone.

A common objection is: “but if the key sits with someone else, isn’t the data anonymous for us?” The answer is no. Whether someone is identifiable is assessed based on all means that could reasonably be used – including the possibility of obtaining the key, whether from you or from a partner. As long as such a path back exists and isn’t unreasonably difficult, the data is personal data. That’s why pseudonymization almost never reaches full anonymity in practice: the key still exists somewhere, and that’s the whole point of choosing pseudonymization over destroying the link.

How to use this

Build pseudonymization in wherever you can, especially in test, analytics, and training environments, but treat the result as personal data regardless. Keep the key separate and strictly access-controlled, and document where it lives and who can reach it.

Above all: never blur “pseudonymized” and “anonymous” in your routines or contracts, because that’s where costly misunderstandings happen. Want to build data protection in the right way from the start? At Weapp we’re happy to bring that into the systems work as early as the requirements stage.

Frequently asked questions

What's the difference from anonymization?

The decisive difference is the key. With pseudonymization, identifiers are replaced with codes, but a key that can link the codes back to people still exists – so the data still counts as personal data. With true anonymization, the link is gone for good and can't be restored, and then the data falls outside GDPR entirely.

Is pseudonymized data still personal data?

Yes. As long as there's a key or any way to link the data back to a person – held by you or by someone else – it counts as personal data. GDPR therefore applies in full, including lawful basis, security, and deletion. Pseudonymization is a safeguard within the rules, not a way out of them.

When is pseudonymization used?

Often in test data and AI training. When developers or models need realistic data but don't need to know who each row belongs to, customer IDs and names are swapped for codes. That lets the work happen with lower risk, while the data keeps its structure and relationships intact. It's also a common requirement in contracts and security routines.

Is pseudonymization enough to satisfy GDPR?

No, but it helps. Pseudonymization is one of the safeguards GDPR explicitly highlights and can reduce both the risk and the impact of a breach. But it doesn't replace the requirements for lawful basis, purpose, and retention limits. Think of it as one layer of protection, not the whole solution.

Where should the key be kept?

Separate from the pseudonymized data, with strict access control. The whole point of the measure is lost if the key sits together with the data or is accessible to everyone who sees the data. Separate the storage, limit who has access, and log the usage, or the protection is mostly on paper.