Yes, pseudonymizing PDF contracts complies with the GDPR, with three non-negotiable conditions: applying a controlled pseudonymization technique (deterministic or random depending on use), keeping the correspondence table in a strictly separate environment, and documenting the technical and organizational measures put in place. Without these safeguards, the processing remains exposed to the risk of re-identification and does not meet the requirements of Articles 25 and 32 of the GDPR.
The two use cases that most often justify this approach:
- Sharing with an AI or an external service provider: submit an employment contract or NDA to ChatGPT, Claude or an audit firm without exposing the names, NIR, IBAN or contact details of the parties.
- Audits and benchmarking: transmit supplier contracts to a third party for comparative analysis while preserving the confidentiality of co-contractors.
Pro tip: Before any pseudonymization, classify your contracts by level of sensitivity (health data, financial data, HR data) - this determines the technique to apply and the level of access control required on the mapping.
Key points
Pseudonymization of PDF contracts is GDPR compliant if the lookup table is separated, encrypted and subject to strict access control, and the technical and organizational measures are documented.
| Point | Details |
|---|---|
| Pseudonymization ≠ anonymization | Pseudonymized data remains personal: the GDPR applies in full, CNIL and EDPB confirm this. |
| Mandatory separation of mapping | The correspondence table must be stored separately from the corpus, encrypted and accessible only to authorized operators. |
| Human validation essential | A quality control on sample is necessary before any distribution: NER and regex produce false negatives. |
| Choose the technique according to use | Tokenization or AES encryption for structured identifiers; RNG for final exports without re-identification. |
| Safe-doc: zero storage, native audit | Safe-doc processes PDF contracts in stateless mode and generates a PDF audit report after each processing. |
Table of contents
- In which cases should you pseudonymize your PDF contracts?
- What exactly does “pseudonymization” mean under GDPR, EDPB and CNIL law?
- How to pseudonymize a PDF contract step by step?
- Which pseudonymization technique should you choose for your contracts?
- What technical and organizational measures are required?
- What risks and pitfalls await your pseudonymization process?
- How to choose a pseudonymization tool for your PDF contracts?
- What practice reveals that guides don't say
- Safe-doc: pseudonymize your PDF contracts without storing a single piece of data
- Sources
In which cases should you pseudonymize your PDF contracts?
Pseudonymization is not a universal answer. It is necessary in specific situations, where the processing involves communication to a third party or secondary use of the data.
- Transmission to a generative AI: any contract submitted to a tool like ChatGPT or Claude must be pseudonymized beforehand, as detailed in guide to contract confidentiality and artificial intelligence.
- Data room and due diligence: during a business sale, contracts shared with potential buyers must mask the identities of employees or subcontractors.
- Internal model training: train a classification model on real contracts without exposing the parties' personal data.
- Disciplinary or arbitration procedures: transmit contractual documents to a third-party arbitrator by masking identities not relevant for the analysis.
- Legal benchmarking: compare contractual clauses between entities of the same group without cross-referencing the personal data of the co-contractors.
The level of risk varies: transmission to an external AI should be treated as high priority, the data room also with high priority, internal training with medium priority, and internal benchmarking with low priority if the scope remains controlled.
Pro tip: For lawyers, pseudonymization before sending to an AI is not only a good GDPR practice: it is an ethical obligation linked to [professional secrecy](https://safe-doc.ai/blog/avocats-chatgpt-secret-professionnel.html). The CNB reminded that any sharing of customer data with an unauthorized third party constitutes a potential violation.
What exactly does “pseudonymization” mean in GDPR, EDPB and CNIL law?
The definition of Article 4(5) and its implications
GDPR defines pseudonymization in Article 4(5) as the processing of personal data in such a way that they can no longer be attributed to a person without recourse to additional information, provided that this information is kept separately and is subject to technical and organizational measures. Essential point: pseudonymized data remains personal data. The data controller remains subject to all GDPR obligations.
The EDPB guidelines 01/2025 specify that pseudonymization can constitute a complementary measure for international transfers, provided that contractual and technical guarantees strictly limit access to the pseudonym and the correspondence table. The notion of “domain of pseudonymization” is central: protection is only effective if the recipient cannot, in its context, reconstruct the real identity.
The CNIL emphasizes this point: pseudonymization does not exempt from a risk analysis, a valid legal basis, nor the implementation of technical and organizational measures within the meaning of articles 25 (protection by design) and 32 (security of processing). For lawyers, professional secrecy is added as an additional constraint, making local or stateless solutions particularly suitable.
The distinction with anonymization is legally structuring: anonymized data leaves the scope of the GDPR, pseudonymized data never leaves it. Consulting Safe-doc comparative page on pseudonymization and anonymization allows you to clarify this point before any treatment decision.
How to pseudonymize a PDF contract step by step?
Operational flow for native and scanned PDFs
The process takes place in seven sequential steps. Each step conditions the next: incomplete detection upstream compromises the entire processing.
1. Preparation of the corpus: inventory the contracts to be processed, classify them by type (work, supplier, NDA, service) and identify the categories of PII present (names, SIREN, IBAN, NIR, addresses, dates of birth).
2. Text extraction: For a native PDF, use a direct extraction tool (pdftotext, PyMuPDF). For a scanned PDF, apply an OCR engine (Tesseract, AWS Textract) page by page before any detection. The quality of the OCR directly determines the PII detection rate.
3. PII detection: combine named entity recognition (NER) for names and organizations, regular expressions for structured identifiers (NIR, IBAN, SIREN, contract numbers), and checksums for financial data. A single engine is not enough.
4. Choice of pseudonymization policy: deterministic if you must maintain consistency between several documents (same pseudonym for the same entity throughout the corpus); random if non-linkability takes precedence over analytical usefulness. The ENISA recommends aligning this choice with the protection/utility compromise.
5. Application and replacement: substitute each PII detected by its pseudonym, preserving the syntactic structure of the contract (approximate length, grammatical gender, consistency of cross-references in the document).
6. Human quality control: reread a representative sample (at least 10% of the corpus or the first 5 pages of each contract). Verify the absence of residual PII, the consistency of pseudonyms and the integrity of essential contractual clauses.
7. Export and secure conservation of the mapping: export the correspondence table in an encrypted environment, separate from the pseudonymized corpus. Record the date, operator, tool version, and applied settings in an audit log.
Checklist before broadcast
Before transmitting a pseudonymized contract, systematically check:
- Metadata of the PDF file (author, title, revision history): to be purged using a dedicated tool.
- Integrated annotations and comments: often forgotten, they may contain names or direct references.
- Electronic signatures: they can reveal the identity of the signatories via on-board certificates. Explicitly decide to keep them or delete them depending on usage.
- Scanned images and stamps: A scanned company stamp or handwritten signature is not processed by a NER text engine.
- Hidden PDF form fields: Some PDFs contain data in fields that are invisible on display but readable by extraction.
Pro Tip: Always test your pipeline on a sample of 3-5 representative contracts before running a batch. A false negative NER on a specific type of clause (e.g. non-compete clause with names embedded in the text) can go unnoticed on a large scale.
For batch processing, maintain a unique lookup table per corpus to ensure cross-document consistency: the same individual must receive the same pseudonym in all contracts in the batch, unless the random policy has been deliberately chosen to maximize non-linkability.
Which pseudonymization technique should you choose for your contracts?
The technical choice depends on two parameters: do you need to re-identify the data later, and do you want to maintain correlations between documents?
| Technical | Reversible | Cross-corpus consistency | Resistance to attacks | Recommended use for contracts |
|---|---|---|---|---|
| Tokenization | Yes (via table) | Yes (deterministic) | High if secure table | Names, company names, relational coherence |
| Symmetric encryption (AES) | Yes (separate key) | Yes | Very high | IBAN, NIR, structured financial data |
| MAC (authentication code) | No | Yes (deterministic) | Very high | Identifiers where re-identification is not required |
| Salted hash (SHA-256 + salt) | No | Yes if fixed salt | Average (vulnerable to the dictionary if predictable data) | Low entropy identifiers not recommended |
| RNG (random identifier) | Yes (via mapping) | No by default | Very high | Irreversible export, definitive redaction |
The ENISA report highlights that the simple hash without salt remains vulnerable to dictionary attacks, particularly on low-entropy data such as common names or postal codes. For structured identifiers (NIR, IBAN, SIREN), AES encryption with a key managed by a dedicated KMS or tokenization via an encrypted table offer the best balance.
- Prefer tokenization or a neutral identifier for the names of natural and legal persons when consistency between documents is necessary.
- Opt for reversible encryption (AES-256, separate key) for financial data and national identifiers.
- Reserve the RNG for final exports where no re-identification is planned.
Pro tip: If you are using a deterministic policy on a large corpus, check that the same pseudonym is not assigned to two separate entities (collision). A uniqueness check in the correspondence table is essential before distribution.
What technical and organizational measures are required?
Key management and mapping separation
The correspondence table is the most sensitive element of any pseudonymization system. Its compromise voids all protection. The minimum requirements are:
- Dedicated KMS (key manager) with periodic rotation of encryption keys, access restricted to authorized operators only.
- Physical or logical separation between the pseudonymized corpus and the correspondence table: two distinct environments, two distinct access controls.
- Encryption at rest and in transit for the lookup table (AES-256 at rest, TLS 1.3 in transit).
- Access logging: each consultation or modification of the table must be traced with timestamp, operator identifier and reason for access.
Contractual obligations and auditability
Any service provider accessing the pseudonymized corpus must be bound by a specific confidentiality clause and an explicit limitation of the pseudonymization domain: they cannot attempt to re-identify the data, nor cross-reference the corpus with other sources. These clauses must appear in the subcontracting contract within the meaning of Article 28 of the GDPR.
The retention period of the mapping must be aligned with the legal retention period of the original contracts, with secure destruction upon expiry. Access logs must be kept for at least the time necessary for a compliance audit, generally three years.
For transfers to third countries, the EDPB Guidelines 01/2025 specify that pseudonymization can constitute a complementary measure to standard contractual clauses, provided that the recipient has access neither to the mapping nor to the information allowing re-identification in its context.
Pro tip: Generate a PDF audit report after each batch job: date, volume of documents processed, types of PII detected, technique applied, operator. This report constitutes your proof of effort in the event of a CNIL inspection.
What risks and pitfalls await your pseudonymization process?
Re-identification and contextual attacks
The main risk is not technical, it is contextual. A “jigsaw attack” consists of crossing the pseudonymized corpus with public data (commercial register, LinkedIn, economic press) to reconstruct the identity of the parties. A supplier contract mentioning a precise amount, a date and a sector of activity may be sufficient to identify the parties even without an explicit name.
Frequent technical problems
- Unpurged PDF metadata: the “Author” or “Company” field of the file reveals the identity of the writer even if the text is pseudonymized.
- Images and stamps: a scanned company logo or handwritten signature is not processed by a NER engine. These items must be removed or replaced manually.
- False negative NER: names integrated into atypical contractual formulations (“Mr. General Manager Jean Dupont”) or in tables are often missed by standard models.
- Electronic signatures: certificates embedded in a signed PDF contain the name of the signatory in plain text in the certificate metadata, independently of the visible text.
- Hidden fields: certain PDF forms store data in fields not displayed on the screen but extractable by a technical tool.
operational precaution described by Corporatech explicitly recommends treating metadata and images as separate stages of the pipeline, not as byproducts of text detection.
Pro tip: After pseudonymization, open the PDF file in a hex editor or use a metadata inspection tool (ExifTool, pdfinfo) to check for residual data. This check takes two minutes and avoids major incidents.
How to choose a pseudonymization tool for your PDF contracts?
Technical criteria and professions to be evaluated
1. PII detection scope: does the tool cover specific French identifiers (NIR, SIREN, SIRET, IBAN FR, permit numbers) in addition to generic entities (names, addresses, dates)?
2. Scanned PDF support: Does it have a built-in OCR engine or does it require external pre-processing? The quality of OCR on degraded documents is a differentiating criterion.
3. Mapping reversibility and management: can the mapping be exported in an encrypted format? Who holds the key? Does the supplier have access to it?
4. Processing mode: cloud with document storage at the provider, or stateless (in-memory processing without persistence)? For sensitive contracts, stateless mode is preferable.
5. Auditability: does the tool generate a time-stamped and signed audit report after each processing?
6. Integrations: REST API available for integration into an existing DMS or workflow? Compatibility with PDF and DOCX formats?
7. Location of servers: hosting in the European Union mandatory for data subject to the GDPR.
Questions to ask the supplier
- Who holds the mapping encryption keys, and where are they stored?
- Are the processed documents kept, even temporarily, on your servers?
- Do you have ISO 27001 certification or a SOC 2 report?
- What are your contractual commitments in the event of a data breach (notification time, liability)?
- Is your solution covered by a DPA compliant with Article 28 of the GDPR?
Local tools like gdpr-pseudonymizer or the Siegfried project illustrate the 100% local approach, without transmission to a third-party server, with encrypted export of the mapping and mandatory human validation. This architecture is particularly suitable for law firms subject to professional secrecy.
Pro tip: Always ask for a demonstration on your own documents (anonymized for testing) rather than on datasets provided by the vendor. The actual detection rate on your contract types may differ significantly from marketing figures.
What practice reveals that guides don’t say
Pseudonymization of PDF contracts is often presented as a technical problem. It is first of all a problem of governance. The incidents that we observe do not come from a poorly chosen technique, but from a correspondence table accessible to too many people, from a mapping exported without encryption “to go faster”, or from human validation removed under deadline pressure.
Safe-doc's stateless solution was designed precisely to meet this reality: zero storage by design, native auditability with PDF report generated after each processing, and detection of more than 90 types of PII including specific French identifiers. Legal teams using it do not change their usual AI tools. They add a layer of protection before using them.
The real question is not “should we pseudonymize?” » but “how can we ensure that the process lasts over time, with team rotation and deadline pressure? » The answer lies in workflow automation and systematic traceability, not manual procedures that no one follows after six months.
Safe-doc: pseudonymize your PDF contracts without storing a single piece of data
Your contracts contain data that you cannot entrust to an AI without prior protection. Safe-doc solves this problem without requiring you to change your work habits.
The platform automatically detects more than 90 types of PII, including specific French identifiers (NIR, SIREN, IBAN), processes your native and scanned PDFs in real time, and does not save any documents on its servers. The mapping is exported encrypted, under your exclusive control. Each processing generates a time-stamped PDF audit report, which can be used directly in the event of a CNIL inspection.
For legal departments, DPOs and firms handling sensitive data, Safe-doc can be integrated via REST API into your existing workflows or used directly from the web interface. Consult the page dedicated to DPOs and compliance managers for details on contractual guarantees and security architecture, or access page on security and zero storage architecture for technical specifications.
Sources
To learn more about or verify the regulatory points covered in this article:
- Guidelines 01/2025 on Pseudonymization
- ENISA - Guidelines on shaping technology according to GDPR provisions
- CNIL - European regulation: data protection (chapter 1)
- Legifrance
- How to pseudonymize or redact a document before sending it to an AI (GDPR) - Corporatech
- gdpr-pseudonymizer v2.1.1 - PyPI
Note: pseudonymization and anonymization are not interchangeable in law. Only irreversible anonymization removes the data from the scope of the GDPR. If in doubt about the qualification of a treatment, consult your DPO or the CNIL before distribution.
This article constitutes general information and is not a substitute for advice from a qualified attorney. Consult a qualified legal professional regarding your individual case before acting on this content.