Pseudonymisation is one of the concepts that generates the most confusion in data protection practice. It is used daily in reports, exports, software testing environments and analytics projects, and it is frequently confused with anonymisation. The difference between the two is not a technical nuance: it determines whether the GDPR applies to that data or not.
The distinction is clear in the regulation but is often misinterpreted. Pseudonymised data remains personal data: it can be attributed back to a person using additional information, so that the GDPR applies to it in full. Only truly anonymous data —that in which re-identification is irreversible— falls outside the scope of the GDPR. And achieving real anonymisation is much harder than usually believed.
In short
- Pseudonymisation (art. 4.5 GDPR) replaces the identifiers with a pseudonym, but keeps separately the information that makes it possible to re-identify the person.
- Pseudonymised data remains personal data and the GDPR applies to it in full (recital 26).
- Real anonymisation is irreversible: when it is achieved, the data stops being personal and falls outside the scope of the GDPR. It is technically demanding and hard to achieve.
- Pseudonymisation is a reinforced security measure (art. 32) and an example of data protection by design (art. 25). It does not exempt from compliance, but it reduces risk.
What pseudonymisation is under the GDPR (art. 4.5)
The GDPR expressly defines pseudonymisation in its article 4, point 5. Under that provision, pseudonymisation is the processing of personal data in such a way that it can no longer be attributed to a data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures ensuring that the data is not attributed to an identified or identifiable natural person.
The central idea of the legal definition is that pseudonymisation does not break the link between the data and the person: it separates and protects it. There is a piece —the additional information, usually a mapping table or a key— that allows the process to be undone and each individual to be identified again. As long as that piece exists somewhere, re-identification is possible.
An everyday example: a company replaces the names and national ID numbers of its customers in its analytics database with codes (CLI-00817, CLI-00818…) and keeps the table associating each code with the real person in an encrypted file, with restricted access, on a separate server. The analytics data is pseudonymised. But because the mapping table exists, those records still refer to identifiable people.
What anonymisation is and why it is different
Anonymisation pursues a different goal: to irreversibly remove any possibility of linking the data with a specific person. Truly anonymous data is data that no longer bears any relation to an identified or identifiable natural person, not even using reasonable additional means.
The GDPR addresses this in its recital 26, which establishes that the principles of data protection do not apply to anonymous information, that is, information which does not relate to an identified or identifiable person, nor to data rendered anonymous in such a way that the data subject is not or is no longer identifiable. In other words: when anonymisation is real, that data stops being personal data and leaves the scope of application of the GDPR.
The same recital 26 introduces the decisive criterion for assessing when someone is "identifiable": account should be taken of all the means reasonably likely to be used by the controller or by any other person to identify the person directly or indirectly, considering objective factors such as the cost, the time required and the technology available. That is why real anonymisation is so demanding: it is not enough to delete the name; you have to ensure that no combination of the remaining data, cross-referenced with other reasonably accessible sources, allows anyone to be identified again.
The key difference: what data remains under the GDPR and what does not
Here is the point that causes the most mistakes. The legal consequence of one technique and the other is radically different:
- Pseudonymised data → remains personal data. Recital 26 of the GDPR is explicit: pseudonymised personal data which can be attributed to a natural person by the use of additional information should be considered information on an identifiable natural person. Therefore, the GDPR applies to it in full: legal basis, duty to inform, data subject rights, security obligation, breach notification, etc.
- Truly anonymous data → outside the GDPR. If the anonymisation is real and irreversible, that data stops being personal data and is not subject to the Regulation (recital 26). However, the mere fact of calling a dataset "anonymous" does not make it so: if any reasonable route to re-identification exists, it remains personal data.
The boundary is not set by the label we put on the process, but by actual reversibility. As long as there exists —in anyone's hands, not only the controller's— a reasonable means to identify the person again, we are dealing with personal data and the GDPR still applies.
Comparison table: pseudonymisation versus anonymisation
| Criterion | Pseudonymisation | Anonymisation |
|---|---|---|
| Reversibility | Reversible with the additional information | Irreversible (when it is real) |
| Is it still personal data? | Yes, always | No, it stops being so |
| Does the GDPR apply? | Yes, in full | No (recital 26) |
| Legal basis in the rule | Art. 4.5 GDPR (definition) | Recital 26 GDPR |
| Legal nature | Security and minimisation measure | Route to exclude data from the scope of the GDPR |
| Usefulness of the data | Preserved almost entirely | Reduced (loss of granularity) |
| Difficulty of execution | Moderate | High: ensuring irreversibility is demanding |
Pseudonymisation as a security and minimisation measure
Even though pseudonymised data remains under the GDPR, pseudonymising is not a futile effort. On the contrary: it is one of the technical measures that the Regulation itself expressly cites and that helps meet several obligations at once.
Security-of-processing measure (art. 32)
Article 32 of the GDPR, on the security of processing, mentions pseudonymisation —together with encryption— as one of the examples of appropriate technical and organisational measures to ensure a level of security appropriate to the risk. Its logic is one of impact reduction: if a third party improperly accesses a set of pseudonymised data but does not have the mapping table kept separately, the potential harm to individuals is significantly lower than if they had accessed the full data.
Data protection by design (art. 25)
Article 25 of the GDPR, on data protection by design and by default, also cites pseudonymisation as a concrete example of a measure the controller can apply to incorporate the data protection principles into its processing from the outset. Designing a system that works with pseudonymised identifiers instead of direct data is a practical way of applying this principle.
Support for the minimisation principle
Pseudonymisation likewise contributes to the data minimisation principle (art. 5(1)(c) GDPR): it allows many operations —analysis, internal statistics, software development, reporting— to be carried out without needing to handle direct identifiers. Staff working with that data do not need to see each person's real name to do their job, which reduces exposure.
"The most frequent mistake we see is not technical, it is conceptual: believing that replacing a name with a code puts the data outside the law. It does not. If someone, somewhere, keeps the key to reverse the process, you are still processing personal data and you are accountable for it. Pseudonymising protects; truly anonymising frees. Confusing the two is taking on a risk that has not been measured."
Mario P. Talamillo · Managing Partner, Certix®
Common use cases
Pseudonymisation fits especially well in scenarios where you need to work with real data without exposing the direct identity of individuals:
- Software development and testing environments. Instead of dumping real customer data into a test environment, the identifiers are pseudonymised to reduce the risk. The golden rule remains not to use real data in testing when it can be avoided; if it is used, pseudonymisation is a minimum.
- Internal analysis and statistics. Departments studying behaviour, performance or segmentation can operate on pseudonymised identifiers without accessing the real names.
- Research. Projects processing participant data usually pseudonymise the records and keep the key that allows re-identification separately, with very restricted access.
- Sharing data with processors. When information is transferred to a provider for a specific task, pseudonymising reduces the volume of identifying data it handles.
- Reducing the impact of breaches. A compromised pseudonymised dataset, without the additional information, exposes far less than one with direct identifiers.
The most common pseudonymisation techniques
There are different ways to pseudonymise, with different guarantees. Broadly, the most used are:
- Substitution by mapping table. Each identifier is replaced by a code and the table associating code and person is kept separately, encrypted. It is reversible by definition as long as that table exists.
- Tokenisation. The identifiers are replaced by tokens generated and managed by a system that keeps the relationship between token and original data in a protected store.
- Keyed hash functions. A cryptographic function is applied that transforms the identifier. Its robustness depends on the specific technique and on key management: without due precautions, some hashes can be vulnerable to brute-force or dictionary attacks, so their suitability is assessed case by case.
- Encryption of identifiers. The identifiers are encrypted with a key kept separately. Anyone without the key cannot reverse the process.
In all of them, the critical element is not just the algorithm, but how the additional information is protected and separated (the table, the token, the key). If that piece is kept badly —in the same system, without access control, unencrypted— pseudonymisation loses much of its value.
Common mistakes: when people believe pseudonymising is anonymising
The most widespread misunderstanding, and the one with the greatest consequences, is treating pseudonymised data as if it were anonymous. Other frequent mistakes stem from it:
| Mistake | Why it is a problem |
|---|---|
| Calling pseudonymised data "anonymous" | It is wrongly assumed to fall outside the GDPR and its safeguards (information, rights, security) stop being applied. |
| Keeping the mapping table next to the data | It breaks the requirement of art. 4.5 to keep the additional information separate and protected. Pseudonymisation loses effectiveness. |
| Believing it is enough to delete the name | Combinations of the remaining data (postcode, date, sex, etc.) can allow re-identification. Identifiability is assessed by all reasonable means (recital 26). |
| Publishing a re-identifiable dataset as "anonymous" | If any reasonable route to re-identification exists, it remains personal data and its release is processing subject to the GDPR. |
| Confusing pseudonymisation with encryption | They are different measures under art. 32 with different purposes; it is worth understanding what each contributes and, often, combining them. |
Practical checklist
Before regarding a dataset as pseudonymised or anonymised, it is worth reviewing these points:
| ✓ | Check | Reference |
|---|---|---|
| □ | Determine whether the goal is to pseudonymise (reduce risk, keep processing) or anonymise (take out of the GDPR) | Art. 4.5 · Rec. 26 |
| □ | Keep the additional information separate, encrypted and with restricted access | Art. 4.5 GDPR |
| □ | Treat pseudonymised data as personal data for all purposes of the GDPR | Rec. 26 GDPR |
| □ | In anonymisation, assess re-identification by all reasonable means (cross-referencing with other sources) | Rec. 26 GDPR |
| □ | Document the technique used and its justification within the security measures | Art. 32 GDPR |
| □ | Build pseudonymisation into the design of new systems and processing operations | Art. 25 GDPR |
| □ | Periodically review whether the technique remains adequate against new re-identification capabilities | Art. 32 (continuous risk-based assessment) |
Pseudonymisation, anonymisation and the rest of the GDPR
These two techniques do not operate in a vacuum: they connect with the whole set of obligations under the Regulation. If you want to place them within the complete framework —the principles of art. 5, legal bases, data subject rights, security obligations and the penalty regime— you can consult our complete GDPR guide, which develops how the security of processing (art. 32) and data protection by design (art. 25) fit within the general system of the rule.
The decision to pseudonymise, or to attempt anonymisation, and the choice of the specific technique, depend on the processing, the risk and the purpose pursued. It is not a merely technical decision: it has direct legal consequences on whether the GDPR still applies and on what obligations the organisation takes on.
Frequently asked questions about pseudonymisation and anonymisation
Is pseudonymised data outside the GDPR?
No. Pseudonymised data is still personal data and the GDPR applies to it in full. Article 4.5 and recital 26 of the GDPR clarify that pseudonymised information which can be attributed to a person using additional information is considered information on an identifiable person. Only real and irreversible anonymisation leaves the data outside the scope of the Regulation.
What is the difference between pseudonymisation and anonymisation?
Pseudonymisation replaces the identifiers with a pseudonym but keeps separately the additional information that allows re-identification; that is why the data remains personal. Anonymisation irreversibly removes any possibility of re-identification, so that the data stops being personal and falls outside the GDPR (recital 26). True anonymisation is technically demanding and hard to achieve.
Is pseudonymising the same as encrypting the data?
They are not the same, although both are security measures cited in article 32 of the GDPR. Encryption transforms the data with a key to make it unreadable to anyone who does not hold it. Pseudonymisation replaces the direct identifiers with a pseudonym while keeping the usefulness of the data for the processing. They are often combined: the dataset is pseudonymised and the mapping table that allows the process to be reversed is encrypted.
Why is pseudonymisation useful if the data remains personal?
Because it reduces the risk to individuals and helps meet several GDPR obligations: it is a security measure expressly cited in article 32, an example of data protection by design under article 25 and a technique that supports the minimisation principle. Although it does not exempt from GDPR compliance, it lessens the impact of a potential breach and strengthens the controller's position.
This content is purely informational and educational; it does not constitute specialised legal advice in any case. Applying the regulations to each specific case requires individual analysis. To assess whether your organisation should pseudonymise or anonymise a specific processing operation, and with which technique, contact a data protection specialist.