Anonymisation vs Pseudonymisation: GDPR Guide

The short answer: anonymised information does not relate to an identified or identifiable person and falls outside the GDPR. Pseudonymised data cannot be attributed to a person without additional information that is kept separately and protected, but it is normally still personal data for the controller that can reconnect it. Pseudonymisation is therefore a safeguard, not a way to avoid GDPR duties.

Conceptual comparison — purpose: anonymisation is intended to prevent identification for the relevant parties; pseudonymisation is intended to prevent attribution inside a defined domain unless authorised additional information is used. Reversibility: genuine anonymisation must withstand means reasonably likely to be used; pseudonymisation may deliberately preserve a controlled route back to the person. Legal status: anonymous information is outside the GDPR; pseudonymised personal data remains subject to lawful basis, transparency, minimisation, retention, security and data-subject-right requirements where the person remains identifiable.

A practical prompt example shows the gap. “Summarise María López’s complaint about her rare condition at the only clinic in town” is plainly personal data. Changing the name to “[CUSTOMER_01]” is pseudonymisation if your CRM or a colleague can reconnect the token. Even without a lookup table, the rare condition, clinic and detailed circumstances may single María out. A safer working version removes unnecessary details, generalises the location and condition, and asks only for the analysis needed — but whether the result is anonymous still requires a contextual assessment.

The same applies to documents. An HR spreadsheet where “Anna Jensen” becomes “EMP-4827” remains pseudonymised if HR holds the employee-number mapping. A contract with names masked may still identify a party through an address, case number, signature, metadata or a distinctive sequence of events. A support ticket can remain personal data through an email quoted in an attachment or through enough dates, product details and location clues to identify one customer.

The EDPB Guidelines 02/2026 propose a practical three-part test: No Record Isolation, No Linkage and No Inference. As at 23 August 2026, these guidelines were adopted for public consultation and feedback remained open until 30 October 2026; they were not final guidance. They are nevertheless a useful current framework, but organisations should monitor the final text and relevant case law.

“No record isolation” asks whether a unique combination of attributes isolates one person’s record — the practical singling-out risk. “No linkage” asks whether records can be connected with other data about the same person, including public or internal sources. “No inference” asks whether specific and meaningful information about an identifiable person can be deduced from the data and available context. Passing all three supports an anonymity conclusion; failing one calls for further analysis rather than an automatic conclusion.

Context matters. The 2026 EDPB draft reflects recent EU case law by assessing what means are reasonably likely to be used from each relevant entity’s perspective. A dataset may be anonymous for an independent recipient that cannot lawfully or practically obtain the key, while remaining personal data for the organisation that holds the source records. If a service provider processes the material on the controller’s instructions, the controller’s perspective still matters; outsourcing is not a shortcut around the GDPR.

Anonymisation also has limits. Free text is high-dimensional and can contain rare facts, writing style, chronology and hidden identifiers. Hashing predictable identifiers without a strong secret can be reversed by guessing. Synthetic or aggregated outputs can leak membership or enable inference. Re-identification capabilities and available external data change, so risk assessments, testing and documentation should be reviewed over time. Anonymising personal data is itself processing and needs a lawful, secure and transparent design.

When does masked content remain personal data?

Assume it remains personal data when your organisation retains the original or token key, when a person can be identified from context, when the same token enables records to be linked, or when a recipient can reasonably obtain additional information. Removing names alone is de-identification, not proof of anonymity. The conclusion depends on the data, purpose, recipients, available means and current technology — and should be documented rather than inferred from the name of a software feature.