Pseudonymization

Legal Framework

Pseudonymization is defined in Article 4(5) GDPR as processing personal data so that it can no longer be attributed to a specific data subject without additional information held separately. Critically, pseudonymized data remains personal data — the GDPR treats pseudonymization not as anonymization but as a risk-reduction technique. A lawful basis under Article 6 is therefore still required.

Article 25(1) GDPR embeds pseudonymization into data protection by design, requiring controllers to implement it where appropriate:

"passende technische en organisatorische maatregelen, zoals pseudonimisering, die zijn opgesteld met als doel de gegevensbeschermingsbeginselen, zoals minimale gegevensverwerking, op een doeltreffende manier uit te voeren"
— GDPR Art. 25(1)

For archiving, scientific research, or statistical purposes, Article 89(1) requires appropriate safeguards and explicitly names pseudonymization:

"Deze maatregelen kunnen pseudonimisering omvatten, mits aldus die doeleinden in kwestie kunnen worden verwezenlijkt."
— GDPR Art. 89(1)

The EDPB similarly identifies pseudonymization as an appropriate technical and organizational measure for international data transfers and cross-border cooperation.

Key Developments

Dutch courts have addressed pseudonymization primarily in document-production and access contexts. In a 2024 Gerechtshof ruling on access to an investigative report under Article 195 Rv, the court held that an employer may pseudonymize the report before providing it to the employee:

"Wel mag de werkgever het rapport pseudonimiseren en wordt het de werknemer verboden mededelingen aan derden te doen over het rapport."
— Gerechtshof

The court permitted pseudonymization under the judiciary's pseudonymization guidelines, coupled with a prohibition on third-party disclosure — an approach that balances the employee's interest in access against third-party privacy.

By contrast, the Rechtbank in separate proceedings found that failure to pseudonymize documents submitted in litigation did not by itself cause actionable harm to concrete individual interests, limiting the remedial consequences of non-pseudonymization in that procedural posture.

On the enforcement side, the Polish DPA (UODO) treated the absence of pseudonymization as a standalone security failure:

"The DPA also found that the processor failed to pseudonymize and encrypt the data."
— UODO, Fortum

Status of the Debate

This topic is contested in court. The divergence is visible: one court treats failure to pseudonymize as harmless absent concrete individual harm, while another conditions document access on the employer's right to pseudonymize. Enforcement authorities, meanwhile, treat the absence of pseudonymization as a security deficiency in its own right. The EDPB is actively developing guidelines on pseudonymization, which signals that the boundaries — particularly when pseudonymization is mandatory versus recommended — remain unsettled. A definitive ruling clarifying whether pseudonymization is a standalone legal obligation or merely a best-practice measure would resolve the current divergence.

Practical Guidance

• Implement pseudonymization under Article 25(1) as a default data-protection-by-design measure, particularly where data minimization principles require it; document the rationale in your DPIA.
• For research, statistical, or archiving processing under Article 89(1), evaluate whether pseudonymization enables the purpose — if it does, it should be the preferred safeguard.
• In litigation and access requests, apply pseudonymization to third-party data unless the requesting party's interest in unredacted data clearly outweighs privacy concerns, following the Gerechtshof's conditional-access approach.
• Treat the absence of pseudonymization as a security gap — the UODO enforcement action against Fortum demonstrates that DPAs will cite failure to pseudonymize as evidence of insufficient technical and organizational measures.
• Remember that pseudonymized data remains personal data under Article 4(1) — maintain a lawful basis under Article 6, honor data subject rights, and store the re-identification key separately with restricted access.