Pseudonymisation vs anonymisation: differences and when to use each

In compliance conversations, “anonymise” and “pseudonymise” are often treated as synonyms. They are not. Choosing the wrong technique can leave processing inside the GDPR when teams thought it was out of scope — or block legitimate reuse of data. This comparison clarifies when to apply each approach.

Working definitions

Anonymisation aims to make it impossible to identify a person, irreversibly, taking into account all means reasonably likely to be used (technology, time, cost and context). If the process is robust, the result is no longer personal data and the GDPR no longer applies to that set.

Pseudonymisation replaces identifiers with codes or other values so that data can no longer be attributed to a data subject without additional information kept separately. The data remain personal: the regulation still applies, although risk is reduced and some safeguards become easier to demonstrate.

The key distinction is controlled reversibility. If a key, table or procedure can restore the original identifier, you do not have full anonymisation.

Decision framework

| Question | Anonymisation | Pseudonymisation | | --- | --- | --- | | Do I need to re-identify later? | No | Yes, exceptionally and under control | | Will I publish or disclose outside the organisation? | Preferred | Only with clear legal bases and contracts | | Does the GDPR still apply? | No (if effective) | Yes | | Useful for longitudinal analysis? | Limited | High, if codes stay consistent |

When to anonymise

Use anonymisation when the goal is to publish resolutions, share open datasets, send documentation to third parties without individual follow-up, or keep historical archives without identifiers. It is the natural path for transparency portals and public annexes.

In PDFs and office documents, anonymisation must remove relevant direct and indirect identifiers. Tools such as Anonimatum automate detection and redaction with patterns and AI — critical when volume makes exclusive manual review impossible. See more on our anonymisation page.

When to pseudonymise

Pseudonymisation fits research, quality analysis, system testing, technical support or internal flows where you need to follow a case over time without exposing clear identifiers. It is also useful in development environments: teams work with realistic data while access to the re-identification key stays restricted.

Minimum requirements: logically (and preferably physically) separate the key, encrypt it, limit roles, log access and define destruction timelines for the correspondence table. Without those measures, “pseudonymisation” is only cosmetic relabelling.

Mistakes that create false security

• Publishing “coded” data when the code is reversible from public information.
• Reusing the same pseudonym across unrelated contexts without assessing linkability.
• Storing the key on the same server with the same permissions as the dataset.
• Claiming a dataset is anonymised because the ID number was removed while address + date + diagnosis remain.
• Applying inconsistent pseudonyms (the same person appears under different codes, losing utility without real protection).

A hybrid approach in real organisations

Many entities need both worlds: an internal pseudonymised repository for analytics and an irreversible anonymisation pipeline for public output. The design should be documented in the record of processing and, where relevant, in impact assessments.

In regulated sectors — legal, healthcare, public administration — set criteria by document type and recipient. What works for an internal report does not work for a PDF published on the electronic office.

Practical takeaway

If data must leave the organisation and you do not need to reverse the process, anonymise. If data stays under your control and you need reversible traceability, pseudonymise with segregated keys. In both cases, assess re-identification risk in your concrete context — not only in the abstract.

Documenting the choice

Record why you chose anonymisation or pseudonymisation for each purpose, which identifiers were removed or replaced, and who holds any re-identification key. That documentation speeds DPIAs and shows accountability if a supervisory authority asks how a published file was prepared.

Want both modes in one document workflow? Talk to us at /contacto or review Anonimatum.