Pseudonymisation GDPR: Legal Rules, Methods and Practice

You must document pseudonymisation as a governed process with recorded controls, not treat it as a compliance exemption that removes personal data from regulatory scope.

The prompt is an analysis of 5 November 2026 of pseudonymisation under GDPR, which argues that pseudonymised data remains personal data because re-identification stays possible with separately held information, and that a defensible implementation requires evidence of separation, proportionate safeguards and documented legal assessment. A law firm sending a witness statement to an external AI model for summarisation must first remove the client's name, date of birth and case number, retaining the mapping separately under access controls. In our assessment, the practical consequence for you is that pseudonymisation reduces identification risk without removing the resulting dataset from data-protection law, and your approval of any such workflow depends on testable answers to where the mapping is stored, who can access it and how failed controls are handled.

What does pseudonymisation actually mean under GDPR?

Pseudonymisation means transforming personal data so that attributing it to a specific person requires additional information kept separately under safeguards. This is an expressly defined concept in Article 4(5) of the GDPR. The definition concerns how you process and protect data, not merely what the resulting document looks like. A file containing coded names can still fail the practical purpose of pseudonymisation if its recipient can readily obtain the corresponding identities.

The useful analogy is a coat check: a numbered ticket attached to a coat doesn't identify its owner by itself, but the matching stub allows the cloakroom to connect the coat with the person collecting it. The linking mechanism needs its own protection. Documents can disclose identity through their content even when their labels have changed—a distinctive account of an incident may identify someone without any lookup table. Professional document handling therefore involves protecting both the text and the information that reconnects it to a person.

Which methods qualify as pseudonymisation?

The strength of a method depends on the attacker model, the linkage the analysis requires and the protection of the secret. ENISA's guidance identifies techniques including random values, keyed hashing, tokenisation and encryption, alongside risks such as brute-force, dictionary-search and guesswork attacks. Generalisation plays a complementary role by reducing the precision of revealing attributes, but works best alongside a substitution method rather than as a substitute for one.

Random substitution is useful when a document needs internally consistent references but no connection to other documents. Deterministic tokens support continuity across a defined analysis, while also revealing that matching records concern the same person. Plain hashes of predictable names are weak because an attacker can test likely inputs. Keyed methods introduce a protected secret, but that secret then becomes a critical security asset in its own right. The underlying architectural risk is that the secret and the dataset shouldn't be handled in the same file, and stored secrets need encryption and proper key management.

1. Restrict recovery permissions to named roles — limit who can access the mapping and document those permissions explicitly.
2. Log each key access — maintain audit records showing when and by whom the mapping was retrieved.
3. Remove insecure temporary copies — delete working files that contain unencrypted secrets or linked data.
4. Encrypt stored secrets — protect the mapping itself with encryption and proper key management.
5. Define legitimate linking scope before choosing tokens — document which connections across systems are necessary for the approved purpose.

What evidence must you produce to defend your safeguards?

Pseudonymised records remain personal data, so the core GDPR duties continue to apply in full. Article 25 requires safeguards proportionate to the processing context and risks. It prescribes no universal token format or fixed technical threshold. A pseudonymised file needs an accountable owner, a retention decision and a rights-handling route, not merely a technical label.

Before approval, record where the mapping is stored, who can access it and how a failed outbound check is handled. Those are testable control questions, not assurances about the accuracy of the resulting analysis. Approve the workflow only after documenting residual identification risk, the legal basis for use and evidence that its controls work. Use an evidence register that connects each control with an owner, a test and an approval decision.

• Identification through rare attribute combinations — a job title, a town and an exact date can point to a person without including their name.
• Reversibility of the transformation — the organisation can reconnect records through its own personnel mapping or other held information.
• Inference from remaining content — distinctive details in the working dataset may disclose identity even after direct identifiers are removed.
• Inadequate secret protection — the mapping is stored with the dataset, unencrypted or accessible to unauthorised roles.
• Scope creep in linkage — the analysis requires connections across systems that weren't necessary for the original approved purpose.

Does pseudonymisation change your legal obligations?

Pseudonymisation may make reliance on legitimate interests under Article 6(1)(f) easier and assist compatibility assessments under Article 6(4), but other GDPR requirements continue to apply. This is not a finding that every pseudonymised use is lawful. Where legitimate interests is the proposed basis, document the interest pursued, why the processing is necessary, and how you balance that interest against individuals' rights and interests. If you propose a new purpose, assess that purpose separately rather than assuming that improved security makes it compatible. A security control can improve a legal assessment without supplying its conclusion.

The controller should explicitly evaluate and accept remaining risk rather than leave that judgement to the tool. The relevant question is whether the proposed safeguards are adequate for this recipient, this dataset and this purpose. Keep jurisdictions distinct: the EU GDPR framework applies in the EU; UK GDPR obligations and ICO guidance apply in the UK, with their own legal context and enforcement.

Tooling can enforce the separation between source material and transformed input, log access to the mapping and alert you to failed controls. What tooling cannot do is determine whether the residual identification risk is acceptable for your purpose, whether your legal basis is sound or whether the balancing of interests meets your obligations. Those judgements remain yours to document and defend.