Pseudonymization mapping table: the GDPR rules in practice

What is a mapping table?

Pseudonymizing a document means replacing whatever identifies a person with a substitute: “Élise Garnier” becomes [PERSONNE_1], “Garnier Immobilier SAS” becomes [ORGANISATION_1]. The mapping table, sometimes called a lookup table or correspondence table, keeps the link between the two:

The table is what makes pseudonymization reversible: with it, you can put the real names back into an AI's answer, or find out who is behind a label. It is also the most sensitive file in the matter, since it gathers every name in one place. The examples above are fictitious.

When you pseudonymize a document before sending it to an AI tool, you almost always use a table rather than an encryption key. If the difference between pseudonymization and anonymization is unclear, start with anonymization vs. pseudonymization under the GDPR.

What does the GDPR say about the mapping table?

The word “table” does not appear, but the definition depends on it entirely. Article 4(5) 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 organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person”.

Three practical consequences:

• No separation, no pseudonymization. A copy that travels with its table, or a table pasted into the same conversation as the copy, does not meet the “kept separately” condition.
• The copy is still personal data. Recital 26 says so: pseudonymized data that could be attributed to a person using additional information relate to an identifiable person. The GDPR still applies, but the risk is lower.
• The table is a security matter. Article 32 lists “the pseudonymisation and encryption of personal data” among the measures appropriate to the risk, together with the ability to “restore the availability” of data after an incident. Both apply to the table: protect it, and don't lose it.

Article 34 gives one more reason to encrypt: after a personal data breach, each data subject need not be notified when measures have rendered the data “unintelligible to any person who is not authorised to access it, such as encryption”. A table stolen in plain text, on the other hand, exposes every client in the matter at once.

What does the EDPB recommend? The pseudonymization domain

The European Data Protection Board (EDPB) adopted its Guidelines 01/2025 on pseudonymisation on January 16, 2025, and put them out for public consultation until March 14, 2025. As of this writing, the EDPB website only publishes that consultation version. Four points apply directly to the mapping table.

1. The table is a pseudonymization secret, and personal data. The EDPB calls keys and “tables matching pseudonyms with the personal data they replace” “pseudonymisation secrets” (paragraph 85). It draws the consequence: lookup tables “are personal data since they allow the identification of data subjects” and must be protected from unauthorized access and use (paragraph 93). The original documents you keep are also part of the additional information that must be kept separate (footnote 21).

2. The pseudonymization domain. This is the context in which pseudonymization must prevent people from being identified: the people operating in it, their means, their systems (paragraph 35). The controller defines it, for example “a single external recipient” or all intended recipients (paragraph 38). It must then ensure that additional information “does not enter” that domain and that pseudonymized data does not leave it without authorization (paragraphs 40 and 111).

For a firm that sends a copy to an AI tool, the domain includes at least the AI provider and its systems. The rule becomes very concrete: nothing that can lift the pseudonyms may go into the conversation, the project, the custom instructions or the files uploaded to the tool.

3. Randomly generated pseudonyms. With a lookup table, “it suffices to choose randomly generated pseudonyms” (paragraph 107). A pseudonym must not be derivable from the original value: no initials, no fragment of a name, no plain hash of a predictable identifier (the New York taxi case is described in our article on re-identification risk).

4. Tables as small as possible. The EDPB distinguishes pseudonyms that follow a person everywhere, which carry more risk, from those valid only for one relationship or one transaction. It asks controllers to define the sets of consistently pseudonymized data “as small as possible” (paragraphs 116 to 121). For a firm, that argues for one table per matter rather than a single table for all clients: a leak exposes only one matter, and two files cannot be linked through their labels.

What does the SRB ruling change?

On September 4, 2025, in Case C-413/23 P, EDPS v SRB (the Single Resolution Board), the Court of Justice ruled on the transfer of pseudonymized comments to Deloitte. The judgment interprets Regulation 2018/1725, which applies to EU institutions, but its definitions mirror the GDPR's. The Court set aside the General Court's judgment and referred the case back to it.

Two lessons matter for the mapping table:

• The recipient's perspective counts. Pseudonymized data “must not be regarded as constituting, in all cases and for every person, personal data”, because pseudonymization may prevent persons other than the controller from identifying the data subject (paragraph 86). That only holds if the recipient has no access to the table or to other reasonable means of re-identification.
• Nothing changes for the firm. Whoever holds the table is still processing personal data. For the duty to inform, the Court held that identifiability must be assessed “at the time of collection of the data and from the point of view of the controller” (paragraph 111).

The EDPB adds a useful point in its Guidelines 02/2026 on anonymisation, adopted on July 7, 2026 for public consultation: when an entity processes data on behalf of a controller, whether the data is personal is assessed from that controller's perspective, and the entity is a processor (paragraph 15). In short, the SRB ruling is no reason to skip the data processing agreement with the AI provider: pseudonymization reduces the risk, it does not replace the contract. On that contract, see ChatGPT and GDPR: can you put client data into it?

What does the CNIL recommend?

The CNIL set out its expectations for the mapping table in its guidance on anonymization and pseudonymization (January 13, 2022, in French). Written for scientific research, it applies as is to a client file (our translations):

• The confidentiality of the elements “(mapping table, ‘salt’, encryption key, etc.)” must be ensured by appropriate technical and organizational measures.
• This information should be accessible “only by authorized persons and under conditions specified in advance”. The CNIL's example: the head of a research project has access, but not the research staff working alongside them.
• An encryption key must be “stored securely and accessible only to authorized persons”, with a “state-of-the-art” encryption method.
• When there is no longer any need to go back to people's identities, this information may be deleted, bearing in mind that the remaining data may still allow indirect identification.

For French lawyers, the AI guide of the Conseil national des barreaux (CNB, the national bar council, April 2026) recommends “systematically” pseudonymizing or anonymizing before any use of generative AI and being mindful of indirect identification through cross-referencing. In its checklist for evaluating AI tools, it also expects client data to be encrypted at rest “with a sufficient encryption algorithm, such as AES-256”, with the key held and managed by the firm (page 26).

What practical rules should a firm follow?

Here are eight rules that translate these texts for a law firm, a notary office or an in-house legal team that sends pseudonymized copies to an AI tool.

If your computer is backed up in full (Time Machine, a backup run by IT), the table is copied along with everything else, and deleting a matter does not remove those older copies: your backup rotation decides how long they live. That is one more reason to keep the table encrypted.

What happens when you delete the table?

Three things happen, and only one of them is usually expected.

1. Re-identification becomes impossible. Nothing can replace [PERSONNE_1] with the real name in an AI answer anymore.
2. The copy does not become anonymous. The CNIL is clear: once that information is deleted, “the remaining data may still allow people to be identified indirectly and then remain subject to the GDPR” (our translation). A docket number, a hearing date or an amount to the cent still points to the matter. And as long as the firm keeps the originals, it can always link the copy back to the people: for the firm, it remains personal data.
3. Copies already sent do not come back. Deleting the table removes nothing on the AI provider's side: the conversation, uploaded files and how long they are kept depend on its terms and your settings. The table protects the copy; it cannot recall it.

Conversely, losing the table by accident (a failed drive, a replaced computer without a transfer) has the same effect as deleting it: past exports can no longer be re-identified. So decide in advance, in writing, how long the table should live, and either back it up or accept losing it. For the full method, from the copy to the answer, see pseudonymize a document for AI, then put the real names back.

How AnonymFiles handles the mapping table

AnonymFiles applies these rules by design. What follows is described in its technical documentation and on its security page:

• One table per folder, on the computer. Each prepared folder has its own private workspace in the user folder (on a Mac, under ~/Library/Application Support, with permissions restricted to your account; on Windows, under %APPDATA%). The same person keeps the same label across every document in the folder, and labels can be renamed.
• Encrypted. Mappings are encrypted at rest with AES-256-GCM, using a 256-bit key created on the computer and protected by the operating system's keychain.
• Never in the export. The export contains the reviewed copies and an index of documents, never the table. Nothing goes to the publisher: no account, no cloud, no telemetry.
• Re-identification on the computer. The AI's answer comes back with its labels, and the app puts the real names back on your machine, as text, Word or PDF.
• Deleted with the folder. Removing a folder from the library deletes its private workspace after confirmation: copies, mappings, search index and rules. The originals are never touched. Exports from that folder can then no longer be re-identified.

Because the app sends neither documents nor tables to its publisher, no data processing agreement is needed for the pseudonymization step itself; the one with your AI provider is still needed. Two honest limits: the table is only as safe as your session (password, screen lock), and the app does not manage your computer's backups for you. The step-by-step workflow is described in how AnonymFiles works; for firms, see also pseudonymization software for lawyers and pricing.