The quality of pseudonymization is measured by the effective reduction of re-identification risk for those who handle the data, not by the mere application of a technique. It is evaluated against three criteria-singling out, linkability, and inference-supplemented by a realistic adversary model and strict separation of secrets. A documented DPIA, technical linkage tests, and governance evidence then support this conclusion before a regulator or auditor.
In brief:
- Pseudonymization remains personal data under the GDPR; its quality depends on an effective reduction of re-identification risk rather than the technique employed.
- It must be evaluated on the basis of singling out, linkability, and inference criteria, in a context allowing potential re-identification according to plausible attacker profiles.
- The success of pseudonymization is measured with concrete tests: uniqueness control, re-correlation, and deduction of sensitive information, involving various attacker profiles.
- An architecture without persistent storage of the original document greatly reduces the attack vector, but does not exempt you from rigorous documentation and continuous compliance assessment.
- The use of tools like Safe-Doc makes it easy to demonstrate, during an audit, the separation of secrets, the traceability of access, and the management of residual risks.
Table of contents
- What is pseudonymization and how it differs from anonymization
- Regulatory framework and case law useful for evaluation
- Technical criteria and metrics to measure the quality of pseudonymization
- Common techniques and their limitations against re-identification
- Practical evaluation process: DPIA, attack scenarios, and evidence
- Common pitfalls and good operational practices
- Operational checklist for a pseudonymization quality audit
- What a storage-free architecture changes for audit
- Safe-Doc to document and prove the quality of your pseudonymization
- Sources
What is pseudonymization and how it differs from anonymization
Article 4(5) of the GDPR defines pseudonymization as the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organizational measures. This definition carries a serious legal consequence: pseudonymized data remains personal data. It therefore falls entirely within the scope of the GDPR, contrary to what many project teams still believe.
Anonymization, in contrast, aims for irreversibility. Once the link is broken in a durable and verifiable way, the data falls outside the regulatory scope. In practice, very few processing operations reach this threshold: a large-scale aggregated dataset may qualify, but a contractual document pseudonymized for use with a generative AI tool almost never does, because the mapping table still exists somewhere.
This distinction changes everything for a compliance officer evaluating a tool or data flow. Pseudonymizing a financial report before analyzing it with a conversational assistant does not exempt the company from its GDPR obligations; it reduces risk and facilitates the demonstration of compliance, which is not the same thing. A final technical point often goes unmentioned: the anonymization operation itself constitutes processing of personal data at the moment it is executed, and therefore requires its own legal basis before even producing an anonymous result.
Regulatory framework and case law useful for evaluation
The EDPB guidelines adopted on January 16, 2025 set out a simple but often overlooked principle: pseudonymization helps meet data protection by design and security obligations, but it never suffices on its own. Its effectiveness depends directly on the capabilities of the actors who receive or handle the data, and on the robustness with which the additional information necessary for re-identification remains separated from the rest of the processing.
The CNIL, building on the landmark opinion of the Article 29 Working Party on anonymization techniques, has established three criteria that remain the reference in France for judging the robustness of a transformation:
- Singling out: can a record corresponding to a specific person still be isolated?
- Linkability: can two distinct datasets concerning the same person be linked?
- Inference: can information about a person be deduced with significant probability?
If any one of these three vectors remains exploitable, the data is not anonymous-it remains pseudonymized at best.
Recent case law from the Court of Justice of the European Union further refines this framework by imposing a contextual reading. A detailed analysis of the CJEU's contributions shows that the same transformation can be considered non-identifying for one recipient and identifying for another, depending on the means of re-identification actually at its disposal. The question is no longer "is the data pseudonymized?" but "for whom, and with what means reasonably likely to be deployed?" It is this contextual test that must structure any serious quality evaluation.
Technical criteria and metrics to measure the quality of pseudonymization
A solid evaluation translates the three CNIL criteria into concrete tests rather than theoretical checkboxes. Singling out is tested by investigating whether a pseudonymized record remains unique in its context, for example via rare combinations of attributes (date of birth, postal code, job title). Linkability is verified by attempting to cross-reference the pseudonymized dataset with another source, public or private, accessible to the intended recipient. Inference, more subtle, is measured by evaluating whether remaining attributes permit the deduction of a sensitive characteristic with high probability.
The ENISA report on pseudonymization techniques describes the adversary models to use to frame these tests: an external attacker without privileged access, a contractual partner with complementary information, or an internal employee with access to other databases in the organization. Each profile radically changes the outcome of the evaluation; the same pseudonymization may be judged robust against the first and fragile against the third.
Three metrics generally structure a serious audit report:
1. The estimated probability of re-identification for the most relevant adversary profile.
2. The ratio of successful attacks during automated linkage tests on a representative sample.
3. The residual risk score after application of complementary organizational measures (contracts, restricted access, logging).
Pro tip: never test your pseudonymization only against yourself. Bring in someone outside the team that designed the transformation: they will find obvious cross-references that the designers, too close to the system, no longer see.
Operational guides for evaluating the anonymous nature of a dataset emphasize a point often forgotten: these metrics have value only when documented, dated, and tied to a specific scope. A residual risk score calculated for internal use is worthless for judging an export to an external service provider.
Common techniques and their limitations against re-identification
Each pseudonymization technique addresses a different need, and confusing their respective guarantees explains most of the audit errors observed in the field.
- Tokenization replaces a value with a randomly generated token, with no mathematical link reconstructable without the mapping table. It protects well against direct inference but depends entirely on the security of that table.
- Hashing transforms a value via a one-way function. Without salting, it remains vulnerable to dictionary attacks and precomputed tables (rainbow tables), particularly on low-entropy values like a social security number or a work email address.
- Encryption provides controlled reversibility via a key, suitable when future data restoration is planned in the business process.
- Key deletion after use transforms reversible encryption into de facto pseudo-anonymization, but only if the deletion is provable and irreversible, which requires a technical architecture designed for this from the outset.
The ENISA technical report documents the most common attacks against these methods: brute force on restricted value spaces, dictionary search against unsalted hashes, and especially cross-correlation between several datasets pseudonymized separately but sharing a common underlying identifier. This last flaw remains the most underestimated: two perfectly pseudonymized datasets taken in isolation can become identifying once combined.
The countermeasures remain well-known but rarely applied correctly: systematic salting before hashing, encryption keys separated by usage domain rather than a single key for the entire system, and use of recognized algorithms rather than in-house implementations. A practical resource on pseudonymization of IT data flows details how to structure these technical choices according to the type of flow processed.
Practical evaluation process: DPIA, attack scenarios, and evidence
A quality evaluation always begins with the precise delimitation of the pseudonymization domain, that is, all the actors, systems, and contracts that have access to the pseudonymized data, distinct from those that hold the additional information allowing re-identification. Without this written delimitation, no evaluation holds up under scrutiny.
The method then unfolds in four steps:
1. Map the recipients of pseudonymized processing and their actual means of access to external or complementary data.
2. Conduct a DPIA focused on re-identification, explicitly documenting the assumptions retained for each adversary profile considered.
3. Execute concrete technical tests: automated linkage tests, brute force attempts on a sample, and manual reconstruction via public sources (social networks, legal registers, open data).
4. Verify organizational controls: effective separation of technical environments, key rotation policy, contracts governing subprocessors, logging of access to the mapping table.
The EDPB guidelines reiterate a point that many technical teams forget: the evaluation must integrate freely accessible information outside the scope of processing, not just data internal to the organization. A motivated attacker rarely relies on a single source; they systematically cross-reference multiple databases.
This approach has concrete merit: it transforms a subjective conviction ("our pseudonymization is strong") into a verifiable case file, with dates, test results, and explicit hypotheses. It is precisely this type of file that a DPO must be able to produce in a few hours during an inspection, not reconstruct urgently under pressure.
Common pitfalls and good operational practices
Three errors silently cancel the protective effect of a pseudonymization otherwise correctly designed on paper. The first: storing the mapping table in the same technical environment as the pseudonymized data, which amounts to leaving the key under the doormat. The second: applying hashing without salting on values with low variability, making dictionary attacks trivial. The third, more organizational: never rotating encryption keys, which exposes all historical data as soon as a single key leaks.
A practical summary on GDPR pseudonymization and anonymization reiterates a reassuring point: even imperfect, properly documented pseudonymization remains a recognized mitigating factor in the event of a data breach, which justifies formalizing it seriously rather than treating it as incidental.
- Physically or, failing that, logically isolate the mapping table, with access controls distinct from those of the rest of the system.
- Rotate keys according to a defined and documented schedule, not just in the event of an incident.
- Restrict access to the key or table to a minimal number of people, identified by name.
- Maintain timestamped audit logs on each access to the additional information.
Pro tip: an auditor isn't looking to see if you're using a good technique. They're looking to see if you can prove, with logs and dates, that the separation of secrets has held up over time.
Operational checklist for a pseudonymization quality audit
A credible audit file relies on verifiable elements, not statements of intent. Here are the pieces expected by most DPOs and regulators:
- An up-to-date DPIA, explicitly mentioning the adversary profiles selected and their justification.
- Documented results of linkage and reconstruction tests, with dates and methodology.
- Proof of separation of secrets: architecture, access controls, key rotation policy.
- Access logs to the mapping table or keys, retained for a defined period.
- A consolidated residual risk report, including assumptions and their limits.
The operational guide for evaluating the anonymous nature of a dataset proposes a simple acceptability criterion: if any one of the three vectors (singling out, linkability, inference) remains exploitable by the most probable adversary profile, the processing must remain classified as pseudonymization, with the full GDPR obligations that result, never as anonymization.
What a storage-free architecture changes for audit
An architecture that never retains the original document mechanically removes an attack vector that many audits neglect: the risk linked to prolonged storage of sensitive data on third-party servers. Processing documents in real time without retaining them reduces the exposure surface, but it never exempts you from documenting the separation of secrets or conducting a complete DPIA.
DPOs expect specific artifacts to validate a tool: export of the mapping used for pseudonymization, timestamped audit logs, and residual risk analysis report associated with each processing operation. A stateless architecture facilitates the production of these proofs; it does not replace them. No tool, whatever its design, can guarantee compliance alone: pseudonymization remains a technical measure that requires human governance, up-to-date contracts, and continuous vigilance over the actual recipients of the data.
- Jacques
Safe-Doc to document and prove the quality of your pseudonymization
Some pseudonymization platforms process sensitive documents in real time without durably storing them, which prevents teams from handling raw data in unsecured AI tools while retaining the ability to restore the information via a controlled mapping export.
Concretely, the platform automatically detects many types of personal and confidential information before any submission to a conversational assistant such as ChatGPT or Claude, and generates the elements that a DPO requires during an audit: residual risk analysis report, auditability logs, and timestamped mapping export. Whether you are handling contracts, data room files, or HR documents, the integration is done via the web interface or the API and the MCP protocol without changing your teams' habits. For a DPO or compliance officer who must demonstrate, not just assert, the quality of their pseudonymization, the page dedicated to DPOs details the evidence generated for each processing operation. Request a demonstration to evaluate, on your own documents, what this approach concretely changes in your next audit.
Sources
- EDPB - Guidelines on pseudonymization (adopted 16 January 2025)
- CNIL - The G29 publishes an opinion on anonymization techniques
- ENISA - Pseudonymization techniques and best practices