The CNIL treats pseudonymization as a recommended security measure but draws a firm line: it is not anonymization. Pseudonymized data remains personal data subject to GDPR. Three actions are immediately required: document your chosen technique, secure the mapping table, and conduct a Data Protection Impact Assessment if the processing involves sensitive data.
In brief:
- Pseudonymization remains personal data under GDPR because it preserves the ability to re-identify individuals through a mapping table.
- The security of this technique rests on precise documentation of the process, protection of the mapping table, and a DPIA when processing sensitive data.
- Effective pseudonymization must simultaneously eliminate the risks of singling out, linkability, and inference-which is why true anonymization is far more difficult to achieve.
- Recommended techniques vary by data sensitivity, including salted hashing, encryption, tokenization, or deterministic encryption, all contingent on rigorous key management.
- Regular review of re-identification capabilities is essential, as pseudonymization effectiveness can quickly become obsolete with technical advances and newly available public datasets.
Table of contents
- CNIL pseudonymization recommendations: definition and distinction from anonymization
- What legal framework governs pseudonymization in France?
- What pseudonymization techniques does the CNIL recommend?
- How do you assess whether your pseudonymization is truly effective?
- What organizational measures does the CNIL concretely expect?
- What do CNIL sanctions reveal about pseudonymization failures?
- How do you structure pseudonymization governance in your organization?
- Priorities for a DPO
- Secure your sensitive documents without changing your work habits
- Sources
CNIL pseudonymization recommendations: definition and distinction from anonymization
Article 4 of the GDPR defines pseudonymization as processing that replaces a direct identifier (name, social security number, email address) with an alias while retaining elsewhere the information that allows tracing back to the original person. It is this reversibility-even when tightly controlled-that fundamentally changes the legal picture.
The CNIL draws a clear boundary between the two concepts using three criteria inherited from the Article 29 Working Party:
- Singling out: can a record belonging to a specific person be isolated?
- Linkability: can two datasets concerning the same individual be connected?
- Inference: can information about the person be deduced from other data?
As long as even one of these three risks persists, you remain in the realm of pseudonymization. Anonymization requires all three to be neutralized simultaneously, which explains why it is so difficult to achieve in practice. The direct consequence for you: a "pseudonymized" document remains covered by GDPR, with all the accompanying obligations-from maintaining processing records to honoring access requests.
What legal framework governs pseudonymization in France?
Three pillars structure French and European obligations. Article 32 of the GDPR mandates pseudonymization as an appropriate technical measure proportionate to risk; Article 25 integrates it into privacy by design; and Article 4 establishes its definition. The CNIL builds its national positions on these texts.
In 2025, the EDPB took a major step by adopting dedicated pseudonymization guidelines-the first at European level with this level of detail. They clarify the expected technical and organizational safeguards and confirm that pseudonymized data remains personal data, even when transmitted to a third party who does not hold the re-identification key.
What this concretely changes for your organization:
- Pseudonymization can support processing based on legitimate interest, provided the documented safeguards are real and verifiable.
- The EDPB confirms that sharing pseudonymized data with a third party remains personal data processing, unless that third party objectively has no means of re-identification.
- The CNIL echoes these guidelines and expects formal documentation of the chosen technical approach.
What pseudonymization techniques does the CNIL recommend?
The choice of technique depends on data sensitivity and the need for reversibility. WP216 remains the most widely cited technical reference for comparing these methods, despite its age.
1. Salted hashing transforms an identifier into an irreversible fingerprint but remains vulnerable to brute-force attacks or rainbow tables if the salt is poorly generated or reused.
2. Symmetric encryption enables controlled reversibility via a key, with risk concentrated on protecting that key rather than on the algorithm itself.
3. Tokenization substitutes a random token for the original data, stored in a separate mapping table. It suits environments where multiple applications must handle the same data without ever accessing it in cleartext.
4. Deterministic encryption always produces the same output for the same input, which facilitates database joins but opens the door to external correlation if an attacker knows certain original values.
Pro tip: Never choose a technique based solely on cryptographic strength. Always ask who in your organization will have access to the key or mapping table, and for how long. That's usually where the vulnerability lies, not in the algorithm.
How do you assess whether your pseudonymization is truly effective?
Pseudonymization deemed robust in 2024 may become inadequate in 2026 if newly available public databases enable correlations that did not exist before. The CNIL insists on this point: evaluation is never fixed in time.
The CNIL emphasizes that re-identification methods evolve constantly, which justifies periodic technical review rather than a one-time check performed once during production deployment.
Concretely, your evaluation methodology should cover:
- Launching a DPIA whenever processing involves sensitive data (health, biometric data, criminal offenses) or a substantial volume of individuals.
- Re-identification testing that simulates a realistic adversary with access to public databases and multi-source correlation capability, rather than purely isolated algorithmic tests.
- Documented technical surveillance, led by the data protection officer, on emerging attack techniques and available external datasets.
What organizational measures does the CNIL concretely expect?
Technical measures alone are never sufficient. WP216 underscores that securing a mapping table requires strict separation of roles between those who process the pseudonymized data and those who hold the re-identification key.
Your operational checklist should include:
- Encryption of the mapping table, with regular key rotation and secure destruction procedures when re-identification is no longer necessary.
- Strict access restrictions, limited to a small number of authorized individuals, with systematic logging of every access.
- A documented retention policy, distinct for pseudonymized data and for the information enabling re-identification.
- Audit logs retained long enough to constitute proof in the event of a CNIL inspection.
Pro tip: Always ask who can technically access both the pseudonymized data and the mapping table simultaneously. If the answer is "a single team," you don't have role separation-you've just added a step.
What do CNIL sanctions reveal about pseudonymization failures?
The cases handled by the CNIL on health and HR data processing show a recurring pattern: it is almost never cryptographic weaknesses that trigger sanctions, but organizational gaps.
The most common errors in these cases:
- Absence of a DPIA for processing that nevertheless involved health data or special categories.
- A mapping table accessible to a far broader set of employees than necessary, without access logging.
- Nonexistent or obsolete technical documentation, unable to justify the chosen method.
- Assumed confusion between pseudonymization and anonymization in communications to data subjects, which undermines their understanding of how to exercise their rights.
The effective remediation plan always follows the same logic: map who has access to what, narrow that scope, document each technical decision, then regularly verify that the safeguards still hold against new re-identification capabilities.
How do you structure pseudonymization governance in your organization?
An effective protocol requires three voices: the DPO establishes the legal framework and documents processing activities, the CISO validates the technical architecture and key protection, and legal counsel verifies consistency with privacy notices and data subject rights-supported by a comprehensive platform such as Adryo - All your domiciliation, one platform for compliance formalities and legal hosting.
Pseudonymization directly affects how access and rectification rights are exercised: a data subject can always request access to their data, even when pseudonymized, as soon as the controller has the means to re-identify them. This obligation of means rests on the controller's accountability under Article 5(2) of GDPR.
Your deployment checklist should cover:
- Mapping of affected documents and data flows (contracts, HR files, health data, data rooms).
- Documented choice of technique and its justification in relation to risk.
- A mapping export enabling controlled restoration of original data when necessary.
- Audit evidence usable in the event of a CNIL inspection.
Pseudonymization that cannot be explained to an auditor in ten minutes, with supporting evidence, is not compliant pseudonymization-it's an undocumented technical promise.
A tool like Safe-doc directly addresses this traceability requirement by generating an auditability report for each processing operation.
Priorities for a DPO
Among the critical priorities: launch a DPIA on every at-risk pseudonymized processing, secure the mapping table before perfecting the algorithm, and train your teams never to conflate pseudonymization and anonymization in their internal communications. The most common shortcut I observe is treating documentation as an administrative formality rather than the first line of defense during an inspection. Neglected technical surveillance 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 durably storing them, directly addressing the minimization requirement your legal and CISO teams have been demanding since Shadow AI became embedded in daily workflows. Your colleagues continue to use ChatGPT or Claude, but sensitive information is pseudonymized before it reaches those platforms, with a mapping export that enables restoration of the original data when necessary.
For a DPO, this means an auditable report for every processing operation. For a legal department handling contracts or data rooms, it means Article 4(5) GDPR compliance without slowing down your teams. Accounting firms and financial auditors find the same benefit on sensitive client files. Explore the detailed functionality on the page dedicated to DPOs and request a demonstration tailored to your document volume.
Sources
To go deeper: the GDPR on EUR-Lex for the legal text, the CNIL for French positions, the EDPB for European guidelines, and WP216 for the reference technical analysis.
- Article 29 Working Party (WP216) - pseudonymization/anonymization
- EDPB adopts pseudonymization guidelines (2025)
- Regulation (EU) 2016/679 (GDPR)