What the GDPR actually says about pseudonymization of legal documents
Pseudonymization is defined in Article 4(5) of the GDPR as processing personal data in such a manner that it 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 subject to appropriate technical and organizational measures. In other words, a contract in which the parties' names have been replaced with codes remains personal data so long as the lookup table exists somewhere. The technique does not remove the processing from the scope of the GDPR. It reduces risk without eliminating it.
For legal professionals, this framework has direct consequences. A pseudonymized judgment sent to an analytics vendor, a client file processed by an AI tool, archived correspondence with substituted identifiers-all remain subject to GDPR obligations so long as reidentification remains possible by reasonable means.
Here are the key points of the applicable legal framework:
- Article 4(5) GDPR: legal definition of pseudonymization, based on separate storage of additional information.
- Recital 26 GDPR: clarifies that whether a person is identifiable must be assessed by reference to all means reasonably likely to be used, taking into account cost, time, and available technology.
- Article 25 GDPR: pseudonymization is among the data protection by design (privacy by design) measures.
- Article 32 GDPR: pseudonymization is cited as an appropriate technical security measure to protect processed data.
- CJEU case law, judgment of 7 March 2024 (C-479/22): pseudonymized data remains personal data for the controller. For a third party, it is personal data only if reidentification is not materially impossible-that is, if it would require disproportionate effort in terms of time, cost, and human resources.
- Conseil d'État decision no. 498628 of 13 February 2026: upheld CNIL sanctions in the "Thin" and "Gers Études clients" database cases, reaffirming that pseudonymization is equivalent to anonymization only if the risk of reidentification is insignificant.
- CNIL position: pseudonymization is a technical security measure, not a legal basis for processing. Consent or another lawful basis remains necessary.
The CJEU further confirmed in September 2025 that pseudonymization does not exempt the controller from its transparency and documentation obligations. Processing a legal document with pseudonyms without informing data subjects or documenting the measure exposes you to sanctions.
Pseudonymization or anonymization: what are the practical legal differences?
Confusion between these two concepts is common-and costly. Yet the distinction drawn by the CNIL is clear: pseudonymization is reversible; anonymization is not. An anonymized document falls outside the scope of the GDPR; a pseudonymized document remains fully subject to it.
| Criterion | Pseudonymization | Anonymization |
|---|---|---|
| Reversibility | Yes, with the lookup table | No, irreversible by definition |
| GDPR scope | Maintained for the controller | Excluded if risk of reidentification is insignificant |
| Risk of reidentification | Residual, to be assessed contextually | Theoretically zero |
| Legal basis required | Yes | No (outside GDPR scope) |
| Data subject rights | Maintained (access, rectification, erasure) | Not applicable |
| Typical legal use | Transmission to third parties, AI use, archiving | Publication of court decisions, research |
The practical consequences for legal documents are significant. A lawyer who pseudonymizes a file before submitting it to an AI tool must still comply with professional secrecy and data subject rights. Pseudonymization facilitates processing; it does not exempt you from it.
Two situations clearly illustrate where pseudonymization is insufficient to remove processing from GDPR scope:
- Linked data: in the case adjudicated by the Conseil d'État in 2026, patient codes combined with age, pathology, consultation date, and prescriber identifiers allowed individualized care pathways to be reconstructed using a simple spreadsheet. Pseudonymization was deemed insufficient.
- Data-rich legal context: a contract in which names are replaced by codes but which contains references to addresses, case numbers, or specific amounts may remain identifiable through cross-referencing.
Professional secrecy adds an additional layer of obligation. For lawyers and notaries, pseudonymizing documents transmitted to external service providers is not merely a GDPR best practice-it is also part of the ethical duty to protect information entrusted by clients.
Which pseudonymization techniques are suitable for legal documents?
Not all methods are equal in every context. Recommended techniques for legal documents typically combine several approaches, depending on data sensitivity and processing purpose.
- Identifier substitution: replacing names, first names, and case numbers with randomly generated alphanumeric codes or pseudonyms. Most common method in contracts and correspondence.
- Encryption: identifying data is encrypted with a key kept separately. The encrypted data remains in the document; the key is stored in an isolated environment. Suitable for long-term archives.
- Hashing: irreversible transformation of an identifier into a digital fingerprint. Useful for verification without reidentification, but beware: an unsalted hash can be reversed by dictionary attack on predictable data such as social security numbers.
- Tokenization: replacement of the real identifier with a token managed by a secure third-party system. Common in document management platforms for legal departments.
- Generalization: replacing a precise value with a range or category (e.g., replacing an exact date of birth with an age range). Useful for statistical analysis on cases.
Strict separation of the lookup table is non-negotiable. The CNIL regularly audits the robustness of what it calls the "pseudonymization vault": all information enabling de-pseudonymization must be stored in a separate environment, with strict access controls and full traceability of consultations.
The legal classification of data does not depend on the technique used. It rests solely on an objective assessment of the actual risk of reidentification, considering the means reasonably available to achieve it. Conseil d'État, decision no. 498628, 13 February 2026.
To choose the appropriate technique for a legal document, three questions are essential: must reidentification remain possible internally? Will the document be transmitted to third parties? What is the planned retention period? A contract sent to an AI vendor for analysis calls for identifier substitution coupled with encryption of the lookup table. A judgment intended for publication may, depending on the level of generalization achieved, approach anonymization.
How to ensure GDPR-compliant pseudonymization in your processes
Compliance is more than applying a technique. It requires an organizational and documentary architecture that the CJEU and CNIL scrutinize closely during audits.
- Record of processing activities: each pseudonymized processing operation must be documented with a description of the technique used, categories of data concerned, recipients, and associated security measures. The absence of this precise documentation is one of the first grounds for sanction during a CNIL audit.
- Privacy notices: data subjects must be informed that their data is being pseudonymized, even if they do not see the pseudonyms. The lawful basis for the underlying processing must be clearly identified.
- Access control to the lookup table: only strictly authorized individuals may access the pseudonymization vault. Each access must be logged.
- Reidentification risk assessment: it must be documented and updated, particularly when new public data sources become available or technologies evolve. The Conseil d'État recalled in 2026 that a simple spreadsheet can suffice to reverse poorly designed pseudonymization.
- Regular audit: technical and organizational measures must be tested periodically. The CNIL may request to examine access logs and key management procedures.
- Data protection impact assessment (DPIA): for high-risk processing, particularly involving health data or criminal records, a DPIA remains mandatory even if data is pseudonymized.
Pro tip: The pseudonymization key should never be stored in the same environment as the pseudonymized data. Use a dedicated secrets manager (enterprise digital vault type) with multi-factor authentication for all access to the lookup table. Document each access with operator identity, timestamp, and justification.
Secure key management is the first element supervisory authorities examine. System robustness depends less on the existence of the key than on the conditions under which it is protected and used.
Pseudonymization in practice: three real-world cases in legal documents
Contracts and notarial deeds transmitted to an AI service provider
A law firm wants to use a generative AI tool to analyze M&A contracts. Before any transmission, parties' names, contact details, SIREN numbers, and amounts are replaced with randomly generated codes. The lookup table remains in the firm's internal environment, encrypted and accessible only to the partners responsible for the file. The AI tool receives a functional document stripped of direct identifiers. After analysis, the results are reintegrated into the original file via the table. This workflow enables AI use on sensitive files without exposing client data.
Judgments and court decisions for legal research
A legal department at a large company archives court decisions to build an internal case law database. Parties', witnesses', and experts' names are substituted with identifiers such as "Party_A" or "Expert_02." Precise dates are generalized to the year. The resulting database can be queried by in-house lawyers without exposing identities. However, if highly specific contextual elements (atypical amounts, rare industry sectors, precise locations) remain, the risk of reidentification must still be assessed.
Pseudonymization is a risk management tool, not a legal end in itself. Residual risks must always be assessed, documented, and reduced as much as possible. CNIL, recommendations on pseudonymization of personal data.
Correspondence and HR files transmitted to third parties
A data protection officer oversees the transmission of employee files to a social audit service provider. Names, social security numbers, and addresses are pseudonymized before transmission. Data subject rights remain fully applicable: if an employee exercises the right of access, the controller must be able to retrieve the individual's data via the lookup table and communicate all information concerning them. Pseudonymization does not suspend GDPR rights; it simply makes them more complex to exercise in practice, hence the importance of a clear reidentification procedure on request.
The main limitation of pseudonymization in these contexts remains the risk of reidentification through cross-referencing. The less precise the residual data, the stronger the protection. But over-generalizing can render the document unusable for the intended analysis. Striking the right balance is an exercise in professional judgment, not a mechanical application of rules.
Safe-doc: pseudonymize your legal documents without changing your tools
The main obstacle to compliant pseudonymization in law firms and legal departments is not lack of will-it is operational friction. Manually pseudonymizing a hundred-page contract before submitting it to ChatGPT or Claude is time-consuming, error-prone, and discouraging to teams, who end up using AI tools directly on original documents. This is precisely the phenomenon known as Shadow AI: uncontrolled use of consumer tools on sensitive data, outside any compliance framework.
Safe-doc addresses this problem with an automatic pseudonymization layer that sits between your documents and the AI tools you already use. Pseudonymization is performed locally, without documents transiting through third-party servers or being stored on the platform. Identifying data is detected and substituted in real time, before transmission to the AI tool. The lookup table remains in your environment.
For data protection officers, Safe-doc directly meets the requirements of Article 32 GDPR regarding technical security measures, while simplifying compliance and audit of AI-involving processing. Processing logs, data separation, and absence of external storage are concrete arguments during a CNIL audit.
Pro tip: Before deploying Safe-doc in your firm or legal department, map the document flows already passing through unsecured AI tools. This mapping of existing Shadow AI will allow you to prioritize use cases to secure first and demonstrate a proactive approach during an audit.
Pseudonymization of legal documents with Safe-doc also preserves the full functionality of AI tools for analysis, assisted drafting, and document research, without compromising professional secrecy or exposing client data. For teams handling M&A transactions, litigation files, or social audits, it is an operational response to GDPR requirements.
Key takeaways
Pseudonymization of legal documents remains subject to the GDPR so long as reidentification is possible by reasonable means, requiring precise technical, organizational, and documentary measures at each stage of processing.
| Point | Details |
|---|---|
| Strict legal definition | Article 4(5) GDPR requires separation of additional information under appropriate security measures. |
| Pseudonymization ≠ anonymization | Pseudonymization is reversible and keeps processing within GDPR scope; anonymization excludes it if risk of reidentification is insignificant. |
| Reidentification risk must be assessed | The Conseil d'État confirmed in 2026 that a simple spreadsheet can suffice to reverse poorly designed pseudonymization. |
| Documentation mandatory | Processing record, privacy notices, and access logs to the lookup table are audited by the CNIL. |
| Safe-doc for legal teams | Safe-doc pseudonymizes locally, without external storage, and integrates with existing AI tools for operational GDPR compliance. |