Complete guide to data pseudonymisation: what it is and how to apply it

Pseudonymisation is one of the techniques most recommended by the General Data Protection Regulation (GDPR) to reduce the risk of processing personal data. However, it is often confused with anonymisation — and that confusion can lead to fines. This guide covers what it is, how it differs, how to apply it, and when to go one step further.

What is pseudonymisation?

Article 4(5) GDPR defines pseudonymisation as the processing of personal data in such a manner that the data can no longer be attributed to a specific data subject without the use of additional information, provided that such information is kept separately and subject to technical and organisational measures preventing re-identification.

In practice: you replace direct identifiers (name, ID number, email, licence plate) with a token, code or hash, and store the mapping table in a secure, separate location.

Pseudonymisation vs. anonymisation

• Pseudonymisation: reversible. Still personal data. Still subject to the GDPR.
• Anonymisation: irreversible. No longer personal data. Falls outside the GDPR (Recital 26).

This distinction is critical: many organisations think they are anonymising when they are in fact pseudonymising, and therefore remain obliged to comply with the full regulation.

Why does the GDPR treat pseudonymised data as personal data?

Because a key exists that allows the token to be linked back to the individual. Even if the key is held by a different entity, the risk of re-identification does not disappear. The GDPR therefore treats pseudonymisation as a security measure, not as a way to stop applying the regulation.

Even so, it is a highly valued measure: it appears explicitly in Articles 25, 32 and 89.

Common pseudonymisation techniques

1. Tokenisation

Each identifier is replaced by a random, meaningless token. The token↔real value table is stored encrypted in a separate vault with access control.

2. Keyed hashing (HMAC)

A hash function is applied with a secret key. Without the key, the hash cannot be recomputed. Useful for matching records without exposing the original.

3. Reversible encryption

The identifier is encrypted with AES or another symmetric algorithm. Requires strict key management.

4. Partial masking

Part of the data is kept (for example, the last 4 digits) for internal traceability while hiding the rest.

When to pseudonymise and when to anonymise

• Development and test environments: pseudonymisation.
• Internal analysis with a need to re-identify: pseudonymisation.
• Publication in a transparency portal or open data: anonymisation.
• Sharing with third parties without a processing agreement: anonymisation.
• Training AI models on sensitive data: pseudonymisation with risk assessment, or anonymisation.

Best practices

1. Keep the key separate from the processed data.
2. Encrypt the key vault and limit access with MFA.
3. Rotate keys periodically and after any incident.
4. Document it in the record of processing activities (Art. 30 GDPR).
5. Assess quasi-identifiers: date of birth, postcode, sex can re-identify even if you pseudonymised the name.
6. Periodically review whether pseudonymisation is still sufficient.

Common mistakes

• Storing the token↔data table in the same database as the pseudonymised data.
• Using unsalted or unkeyed hashes: a hashed ID can be brute-forced in seconds.
• Publishing "pseudonymised" data on a public portal, believing you comply risk-free.
• Forgetting quasi-identifiers and metadata.
• Not informing the data subject because "there is no personal data anymore".

How anonimIA handles it

anonimIA manages both pseudonymisation and anonymisation of documents. You can choose to replace identifiers with reversible tokens when you need internal traceability (for example, in review workflows or ongoing case files), and apply irreversible anonymisation when the document is going to be published or shared externally. The transition between the two states is fully logged, with encryption in transit and at rest.

Frequently asked questions

Can pseudonymised data be published freely?

No. It is still personal data and its publication requires a legal basis, information to the data subject, and security measures. For unrestricted publication, data must be irreversibly anonymised.

Does pseudonymisation remove the obligation to notify breaches?

No, but it reduces risk. A breach affecting only pseudonymised data whose key is not compromised may not require communication to the data subject (Art. 34(3)(a) GDPR).

Can I use pseudonymisation to train AI models?

Yes, but with a data protection impact assessment (DPIA) if the processing is large-scale or involves special categories of data. Often it is better to go one step further and anonymise the training dataset.

Conclusion

Pseudonymisation is an essential tool to reduce risk without losing internal utility of the data, but it does not release you from GDPR compliance. Combine it with anonymisation wherever re-identification must be ruled out, and document every step.