The CNIL considers pseudonymization as a recommended security measure, but it refuses to confuse it with anonymization: pseudonymized data remains personal data subject to the GDPR. Three actions are immediately necessary: document the technique chosen, secure the correspondence table and launch an impact analysis if the processing involves sensitive data.
In brief:
>
- Pseudonymization remains personal data subject to the GDPR, because it retains the possibility of re-identifying an individual using a correspondence table.
- The security of this technique is based on the precise documentation of the process, the protection of the correspondence table, and an impact analysis in the event of processing of sensitive data.
- Effective pseudonymization must simultaneously remove the risks of individualization, correlation and inference, which makes anonymization much more difficult to achieve.
- Recommended techniques vary depending on the sensitivity of the data, including salted hashing, encryption, tokenization or deterministic encryption, subject to rigorous key management.
- Regular review of reidentification capabilities is essential, because the effectiveness of pseudonymization can quickly become obsolete in the face of technical developments and public databases.
Table of contents
- CNIL recommendations pseudonymization: definition and distinction from anonymization
- What legal framework governs pseudonymization in France?
- What pseudonymization techniques does the CNIL recommend?
- How can you assess whether your pseudonymization is really effective?
- What organizational measures does the CNIL actually expect?
- What do CNIL sanctions reveal about pseudonymization errors?
- How to structure the governance of pseudonymization in your organization?
- Priorities for a DPO
- Secure your sensitive documents without changing your work habits
- Sources
CNIL recommendations pseudonymization: definition and distinction with anonymization
Article 4 of the GDPR defines pseudonymization as the processing which replaces a direct identifier (name, social security number, email address) with an alias, while retaining elsewhere the information allowing it to be traced back to the original person. It is this reversibility, even if controlled, which changes everything on a legal level.
The CNIL draws a clear border between the two concepts thanks to three criteria inherited from working group Article 29:
- Individualization: can we isolate a recording belonging to a specific person?
- Correlation: can we link two sets of data concerning the same individual?
- Inference: can we deduce information about the person from other data?
As long as only one of these three risks remains, we remain in the field of pseudonymization. Anonymization requires that all three be neutralized simultaneously, which is why it is so difficult to achieve in practice. Direct consequence for you: a “pseudonymized” document remains covered by the GDPR, with all the obligations that accompany it, from the processing register to the right of access.
What legal framework governs pseudonymization in France?
Three pillars structure French and European bonds. Article 32 of GDPR imposes pseudonymization as an appropriate technical measure to address the risk, article 25 integrates it into the logic of protection from design, and article 4 sets its definition. The CNIL relies on these texts to build its national positions.
In 2025, the EDPS took a step forward by adopting guidelines dedicated to pseudonymization, the first so detailed at European level. They specify the expected technical and organizational guarantees and confirm that pseudonymized data remains personal data, even transmitted to a third party who does not hold the reidentification key.
What this actually changes for your organization:
- Pseudonymization may support processing based on legitimate interest, provided that the documented guarantees are real and verifiable.
- The EDPS confirms that sharing pseudonymised data with a third party remains processing of personal data, unless this third party objectively has no means of re-identification.
- The CNIL relays these guidelines and awaits formal documentation of the technical choice chosen.
What pseudonymization techniques does the CNIL recommend?
The choice of a technique depends on the sensitivity of the data and the need for reversibility. WP216 remains the most cited technical reference for comparing these methods, despite its age.
1. Hashing with salt transforms an identifier into an irreversible fingerprint, but remains vulnerable to brute force attacks or precomputed tables if the salt is incorrectly generated or reused.
2. Symmetric encryption allows reversibility controlled via a key, with risk concentrated on the protection of this key rather than on the algorithm itself.
3. Tokenization substitutes a random token for the original data, stored in a separate lookup table. It is well suited to environments where several applications must manipulate the same data without ever accessing it in clear form.
4. Deterministic encryption always produces the same result for the same input, which makes base joins easier but opens the door to external correlations if an attacker knows certain original values.
Pro tip: never choose a technique for its cryptographic robustness alone. Always ask who in your organization will have access to the key or lookup table, and for how long. This is often where the flaw lies, not in the algorithm.
How to assess whether your pseudonymization is really effective?
Pseudonymization deemed solid in 2024 may become insufficient in 2026 if new public databases allow correlations that did not exist before. The CNIL insists on this point: the evaluation is never frozen in time.
The CNIL points out that the means of re-identification are constantly evolving, which justifies a periodic technical review rather than a one-off check carried out once and for all during production.
Concretely, your evaluation methodology should cover:
- The launch of a DPIA as soon as the processing concerns sensitive data (health, biometric data, offenses) or a large volume of people.
- Reidentification tests simulating a realistic adversary, with access to public databases and multi-source correlation capacity, rather than purely isolated algorithmic tests.
- Documented technical monitoring, led by the data protection officer, on new attack techniques and available external data sets.
What organizational measures does the CNIL actually expect?
Technique alone is never enough. WP216 emphasizes that securing a correspondence table implies a strict separation of roles between the one who processes the pseudonymized data and the one who holds the reidentification key.
Your operational checklist should include:
- Encryption of the correspondence table, with regular rotation of keys and secure destruction procedure when reidentification is no longer necessary.
- Strict access restriction, reserved for a limited number of authorized people, with systematic logging of each consultation.
- A documented retention policy, separate for pseudonymized data and for information allowing its re-identification.
- Audit logs kept long enough to constitute proof in the event of an audit.
Pro tip: Always ask who can technically access the pseudonymized data and the lookup table simultaneously. If the answer is "one team", you don't have role separation, you just added a step.
What do CNIL sanctions reveal about pseudonymization errors?
The files processed by the CNIL on the processing of health and human resources data show a recurring pattern: it is almost never cryptographic weaknesses that trigger the sanction, but organizational shortcomings.
The most common errors in these files:
- The absence of DPIA for processing which nevertheless related to health data or specific categories.
- A correspondence table accessible to a much wider scope of employees than necessary, without access logging.
- Non-existent or obsolete technical documentation, incapable of justifying the choice of the method adopted.
- An assumed confusion between pseudonymization and anonymization in communication intended for the people concerned, which weakens their information on the exercise of their rights.
The effective corrective plan always follows the same logic: map who has access to what, reduce this perimeter, document each technical decision, then regularly check that the guarantees still hold up in the face of new re-identification capabilities.
How to structure the governance of pseudonymization in your organization?
An effective protocol is built with three voices: the DPO establishes the legal framework and documents the processing, the CISO validates the technical architecture and the protection of the keys, the lawyer checks consistency with the information notices and the exercise of the rights of the persons concerned, relying on a complete platform such as Adryo - Your entire domiciliation, a single platform for formalities and legal accommodation.
Pseudonymization directly influences the methods of exercising rights of access and rectification: a data subject can always request access to their data, even pseudonymized, as soon as the data controller has the means to re-identify them. This obligation of means weighs on the accountability of the data controller within the meaning of article 5.2 of the GDPR.
Your deployment checklist should cover:
- Mapping of the documents and flows concerned (contracts, HR files, health data, data rooms).
- The documented choice of the technique and its justification with regard to the risk.
- A mapping export allowing, if necessary, the controlled restoration of the original data.
- Proof of audit that can be used in the event of an inspection by the CNIL.
A pseudonymization that cannot be explained to a listener in ten minutes, with supporting evidence, is not a compliant pseudonymization: it is an undocumented technical promise.
A tool like Safe-doc directly responds to this traceability requirement, by generating an auditability report for each processing operation.
Priorities for a DPO
Among the important priorities, we can remember: launching a DPIA on any pseudonymized processing at risk, securing the correspondence table even before refining the algorithm, and training your teams to never confuse pseudonymization and anonymization in their internal communication. The most common shortcut I see is treating documentation as an administrative formality rather than the first line of defense in the event of an audit. Neglected technical monitoring always ends up costing more than it would have cost to maintain.
- Jacques
Secure your sensitive documents without changing your work habits
Safe-doc processes your documents in real time without ever storing them, which directly responds to the minimization requirement that your legal and CISO teams have been asking of you since Shadow AI became established in daily use. Your employees continue to use ChatGPT or Claude, but sensitive information is pseudonymized before passing through, with a mapping export that allows the original data to be restored when necessary.
For a DPO, this means an audit report that can be used for each processing operation. For a legal department handling contracts or data rooms, this means compliance with Article 4(5) of the GDPR without slowing down the teams. Accounting firms and financial auditors find the same benefit on sensitive client files. Discover the detailed operation on the page dedicated to DPOs and request a demonstration adapted to your volume of documents.
Sources
To learn more: the GDPR on EUR-Lex for the legal text, the CNIL for the French positions, the CEPD for the European guidelines, and the WP216 for the technical reference analysis.
- Article 29 Working Party (WP216) - pseudonymization/anonymization
- EDPB adopts pseudonymization guidelines (2025)
- Regulation (EU) 2016/679 (GDPR)