When pseudonymized data still counts as personal data under GDPR

At a glance

What this is: The article explains that pseudonymized data can still count as personal data under GDPR when the recipient can realistically re-identify individuals, and that transparency duties are judged from the controller’s collection-time perspective.

Why it matters: For privacy, IAM, and data governance teams, the ruling changes how sharing, disclosure, and recipient risk are assessed, especially where pseudonymization is treated as a compliance shortcut.

By the numbers:

• The CJEU established binding principles on September 4, 2025 for when pseudonymized data constitutes personal data under the GDPR.
• The case involved the SRB's 2017 decision regarding the resolution of Banco Popular Español.
• On December 19, 2025, the parties withdrew the matter from the General Court.
• The EDPB adopted its first comprehensive Pseudonymization Guidelines in January 2025.

Context

Pseudonymization reduces direct identifiability, but it does not automatically remove data from privacy law. Under GDPR, the legal question is not whether a dataset has been stripped of obvious identifiers, but whether a controller or recipient can still reasonably identify the person behind it.

This matters because privacy governance often treats pseudonymization as a clean boundary. The CJEU's reasoning shows that boundary is recipient-specific and context-specific, which forces organisations to align data sharing decisions, notices, and retention controls with real-world re-identification risk rather than with technical labels alone.

In practice, that brings privacy, data governance, and IAM-style access thinking into the same control problem. If a recipient can combine data with other information and re-identify people, pseudonymization becomes a risk-reduction measure, not a legal off-switch.

Key questions

Q: How should organisations assess whether pseudonymized data is still personal data under GDPR?

A: Start by asking who will receive the data, what other information they already hold, and whether they can realistically re-identify the person using means reasonably likely to be available. If the answer is yes, treat the data as personal for that recipient and apply GDPR obligations accordingly.

Q: Why do privacy notices still matter after data is pseudonymized?

A: Because transparency obligations arise when the controller collects the data, not only after it has been masked. If the controller can identify the person at collection, it must disclose the intended recipients and purposes even if the later transfer uses pseudonymized data. Pseudonymization changes exposure, not the original duty to inform.

Q: What are the biggest mistakes teams make with pseudonymized data?

A: The most common mistake is treating pseudonymization as a blanket exemption from GDPR. Teams also overestimate masking strength, ignore recipient-specific context, and fail to document why re-identification is or is not reasonably likely. That creates weak transfer decisions and weak audit evidence when regulators ask how scope was assessed.

Q: How should organisations decide whether to share pseudonymized data with third parties?

A: They should assess who the recipient is, what other data they hold, whether the recipient can reasonably re-identify people, and whether the share can be justified and documented. If the answer depends on hidden assumptions about the recipient's environment, the share is not ready for approval. Governance should be tied to the actual recipient, not the label on the dataset.

Technical breakdown

Why pseudonymized data can remain personal data

Pseudonymization removes direct identifiers, but it does not necessarily break the link between a record and a person. Under the CJEU's approach, the key issue is whether the recipient has means reasonably likely to be used to re-identify the subject, taking into account context, auxiliary data, cost, time, and available technology. That means the same dataset can be non-personal for one recipient and personal for another. The legal status of the data therefore depends on the recipient's actual position, not just the controller's technical processing step.

Practical implication: Treat pseudonymization as a context-specific control, not a universal exemption from GDPR obligations.

Why collection-time transparency still applies

The court separated the moment of collection from the later transfer or disclosure of pseudonymized data. If the controller can identify the individual when collecting the data, it must disclose the relevant recipients and processing purposes at that point, even if the data will later be pseudonymized before sharing. This prevents organisations from using downstream masking to avoid notice obligations that already existed at collection. The control question is therefore tied to the controller's original visibility, not to the recipient's later limitations.

Practical implication: Map transparency notices to the collection event, not to the later pseudonymized handoff.

How recipient-specific risk changes governance

Recipient-specific assessment is the central governance shift. A privacy team now has to ask what information each recipient already holds, what technical capability they have, and whether the pseudonymization method is strong enough in that exact context. That is closer to access governance than to a one-size-fits-all privacy label: the risk depends on who sees the data, what they can correlate, and whether identity can be reconstructed. The CJEU's relativity principle makes re-identification analysis an operational discipline, not a legal afterthought.

Practical implication: Document recipient-specific re-identification analysis before any share, and re-evaluate it whenever the recipient context changes.

Threat narrative

Attacker objective: The objective is to reconstruct personal identity from pseudonymized data and use that data in a way that bypasses or weakens privacy controls.

1. Entry occurs when a controller shares pseudonymized records with a third party that still has enough context to link them back to individuals.
2. Credential or data access is not defeated by pseudonymization alone when the recipient can combine the data with other information to re-identify subjects.
3. Impact is a privacy and compliance failure, because personal data obligations still apply even though direct identifiers were removed.

Breaches seen in the wild

• Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Pseudonymization is now a recipient-governed control, not a category label. The CJEU's relativity approach means data protection teams cannot rely on a single technical masking step to settle GDPR scope. The operative question is who receives the data, what else they know, and whether re-identification is reasonably likely. For practitioners, that shifts pseudonymization from a static privacy technique into an access and context governance problem.

Collection-time transparency becomes harder, not easier, when data is later masked. If the controller can identify people at intake, it cannot use later pseudonymization as a reason to postpone disclosure obligations. That has direct consequences for privacy notices, consent or lawful-basis workflows, and third-party transfer records. The governance lesson is simple: the notice decision belongs at collection, not after transformation.

Recipient-specific identifiability is the named concept this ruling crystallises. The same dataset may sit inside or outside GDPR depending on the recipient's realistic ability to re-identify it. That makes privacy engineering more like identity risk assessment, where context determines exposure. For organisations, the practical standard is to prove why a given recipient cannot reasonably reverse the masking step.

Privacy teams need a stronger linkage between data-sharing decisions and access governance. Pseudonymization only reduces risk if downstream recipients do not have the auxiliary information needed to restore identity. That means data maps, transfer registers, and recipient capability assessments need to be maintained with the same discipline as privileged access records. The control objective is defensible identifiability analysis, not paperwork after the fact.

From our research library:

• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Recipient-specific identifiability: the decisive privacy question is no longer whether data is pseudonymized in the abstract, but whether a particular recipient can realistically reverse it. That makes data-sharing reviews, transfer registers, and access assumptions part of the same governance workflow as lawful-basis analysis.

Organisations that treat pseudonymization as a final compliance state will continue to under-document third-party visibility. The better model is to manage identifiability as a living risk signal that changes when recipients, auxiliary data, or technical capability changes.

For privacy and identity teams, the lesson is that notice, disclosure, and recipient analysis belong at the point of collection. That is where the legal obligation starts, and where the practical control boundary must be set.

For practitioners

• Build recipient-specific re-identification assessments For each downstream recipient, document what auxiliary data they hold, what technical means they have, and why re-identification is or is not reasonably likely.
• Update privacy notices at collection time Disclose third-party recipients and processing purposes when personal data is first collected, rather than waiting until after pseudonymization or transfer.
• Maintain a pseudonymization decision record Keep the rationale for whether a dataset remains personal data for each recipient, including the assumptions used and the review date.
• Align transfer governance with access governance Treat every pseudonymized transfer as a controlled disclosure event, with approval, logging, and periodic revalidation of recipient context.

Key takeaways

• Pseudonymization reduces direct exposure, but it does not automatically remove GDPR obligations when the recipient can still re-identify people.
• The ruling shifts privacy governance toward recipient-specific analysis, collection-time transparency, and documented transfer decisions.
• Organisations that treat masking as a compliance shortcut will miss the real control point, which is whether identity can still be reconstructed downstream.

Key terms

• Pseudonymized Data: Data that has had direct identifiers replaced or removed so it is harder to link to a person, but not necessarily impossible. Under GDPR analysis, it may still be personal data if a controller or recipient can realistically re-identify the subject using other information.
• Recipient-Specific Identifiability: A privacy assessment approach that asks whether a particular recipient can identify a person using the data and the information available to them. It recognises that the same dataset can have different legal status depending on who receives it and what they can combine it with.
• Transparency At Collection: The obligation to tell data subjects, at the time personal data is collected, who will receive it and why. The CJEU's reasoning reinforces that later masking does not erase the duty that already existed when the controller first gathered the data.
• Re-identification: Re-identification is the process of linking supposedly anonymous or low-risk data back to a person. It often happens when organisations combine datasets across systems, exports, or analytics environments. For identity and privacy teams, the risk is that reuse can turn safe-looking data into identifiable information.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the course if your programme needs a stronger foundation in identity lifecycle and governance controls.