When pseudonymized data still counts as personal data under GDPR

At a glance

What this is: This is an analysis of the CJEU’s EDPS v SRB ruling, which clarifies when pseudonymized data still qualifies as personal data under the GDPR.

Why it matters: It matters because identity and privacy teams must assess identifiability from the controller’s and recipient’s perspectives, especially when third parties, data access, and disclosure obligations intersect.

By the numbers:

• While 71% of IT teams have been advised on AI agent data access, only 47% of compliance teams, 39% of legal teams, and 34% of executives have the same visibility.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.

👉 Read Securiti's analysis of when pseudonymized data constitutes personal data under GDPR

Context

Pseudonymization reduces direct identifiability, but it does not automatically remove data from privacy law. The key governance problem is that controllers often treat re-identification risk as a binary question, when the legal test depends on who receives the data, what information they hold, and whether they can realistically identify the subject.

In GDPR programmes, this matters wherever personal opinions, employee feedback, customer comments, or stakeholder submissions are shared outside the original collection context. The CJEU’s reasoning is especially relevant to data-sharing workflows that mix privacy operations, access control, and third-party processing, because the compliance duty begins at collection, not after transfer.

For identity and access teams, the article’s starting position is typical of modern privacy programmes: the control issue is not pseudonymization itself, but the assumptions made about recipient visibility and disclosure obligations.

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 pseudonymized datasets still create privacy obligations after sharing?

A: Because pseudonymization reduces identifiability but does not necessarily remove it. If the controller or recipient can still link records to individuals through context, auxiliary records, or operational knowledge, the data can remain personal data and still trigger disclosure, purpose limitation, and accountability duties.

Q: What do privacy teams get wrong about pseudonymization and transparency notices?

A: Many teams assume notices can be fixed later after data is anonymized or shared. In practice, transparency obligations are judged at collection time, so the controller must disclose relevant recipients and purposes before transfer, not after the data has already left the original context.

Q: Who is accountable when pseudonymized data is shared with a third party?

A: The controller remains accountable for deciding whether the data is identifiable at collection and whether the disclosure notice is complete. Third-party recipients may also carry obligations, but they do not erase the controller’s duty to assess identifiability and inform data subjects up front.

Technical breakdown

Why pseudonymization does not end personal data analysis

Pseudonymization removes direct identifiers, but it does not erase context. Under GDPR reasoning, data remains personal when a controller or recipient can still link it back to an individual using information reasonably likely to be available. That means the legal status of a dataset depends on the surrounding ecosystem: access to auxiliary records, technical capability, cost, and the purpose of processing. The same dataset can be personal data for one party and effectively non-identifiable for another. Practical privacy governance therefore has to treat pseudonymization as a risk reducer, not a scope-exclusion switch.

Practical implication: map recipient-specific identifiability before sharing pseudonymized datasets.

Why personal opinions are treated as personal data

The court’s reasoning is broader than re-identification. A statement of opinion is itself linked to the person expressing it, because it reflects a subjective view, judgment, or assessment. That means comments, survey responses, and stakeholder submissions are not made non-personal simply by stripping names or identifiers. This matters for privacy operations because opinion data often travels through feedback platforms, case management tools, and outsourced review processes where the content may still reveal the individual’s relationship to the issue. The governance challenge is to classify the content correctly at collection, not only at downstream sharing.

Practical implication: classify opinion content as personal data before routing it into third-party workflows.

How transparency obligations attach at collection time

The court rejected the idea that a controller can wait until after pseudonymization or transfer to decide whether disclosure duties apply. Transparency obligations are assessed from the controller’s perspective at the moment of collection, when the controller already knows who the data subjects are and why the data is being gathered. That creates a separation between internal collection knowledge and downstream recipient identifiability. In operational terms, legal teams need notices, records of processing, and transfer documentation aligned to the original collection event, not to the later state of the shared dataset.

Practical implication: align privacy notices and records of processing to collection-stage reality, not transfer-stage assumptions.

NHI Mgmt Group analysis

Pseudonymization relativity is now the controlling concept. The decisive issue is no longer whether data has been stripped of direct identifiers, but whether a particular recipient can realistically re-identify the subject. That creates a governance model in which the same dataset can move between personal-data and non-personal-data treatment depending on context, access, and auxiliary information. Privacy teams should treat recipient-specific identifiability as a standing classification requirement, not a one-time legal label.

Collection-stage transparency is the control point that many programmes miss. The ruling makes clear that controllers cannot postpone disclosure obligations by relying on downstream pseudonymization. This is structurally similar to identity governance failures where teams assume later controls can compensate for poor intake decisions. In privacy programmes, the intake decision is where the duty crystallises, so notices, purpose limitation, and third-party disclosures must be designed before data leaves the collection boundary.

Opinion data should be governed as personal data by default. Personal comments, views, and assessments are intrinsically tied to the speaker, even when the name is removed. That pushes organisations toward stronger intake classification, especially in employee listening, customer feedback, and regulated consultation workflows. The practitioner conclusion is straightforward: if the content expresses a person’s view, pseudonymization alone does not remove the GDPR governance burden.

This ruling strengthens the case for privacy controls that are recipient-aware, not dataset-only. Organisations need to distinguish between internal sanitisation and external identifiability, because the same record can produce different compliance outcomes in different hands. For teams responsible for identity verification, access governance, or data-sharing controls, the lesson is that access context is part of the privacy assessment. The right control model follows the recipient, not just the file.

What this signals

Pseudonymization programmes are moving toward recipient-aware governance, where legal teams must evaluate identifiability separately for each disclosure path. That makes data-sharing inventories, notice management, and records of processing more operationally important than one-time classification exercises.

Recipient-aware privacy controls: the practical standard is shifting from “is the dataset redacted?” to “who can still identify the subject, and with what means?” That question will increasingly shape compliance decisions in employee feedback, customer analytics, and outsourced review workflows.

For teams already managing identity, access, and data governance together, this ruling reinforces a broader pattern: control effectiveness depends on context, not labels. The next improvement step is to connect disclosure approvals to access context and recipient capability, using privacy governance as part of the broader security control plane.

For practitioners

• Review pseudonymization by recipient context Document what auxiliary data each recipient holds, what re-identification paths exist, and whether those paths are reasonably likely to succeed. Use that assessment to determine whether the shared dataset remains personal data for that recipient.
• Update collection-stage transparency notices Ensure notices describe third-party disclosure before transfer occurs, especially where the controller can identify the person at collection. Align the notice language with the actual collection purpose and downstream recipients.
• Classify opinion and feedback content as personal data Treat survey responses, stakeholder comments, and employee feedback as personal data even after names are removed. Build that assumption into intake workflows, retention rules, and processing records.
• Separate sanitisation from legal scope decisions Do not let redaction or pseudonymization automatically decide GDPR scope. Require a separate legal review of identifiability, recipient capability, and the purpose of onward sharing.

Key takeaways

• Pseudonymized data can still be personal data when the recipient can realistically re-identify the subject.
• The court’s ruling makes collection-stage transparency and recipient-specific assessment central to GDPR compliance.
• Organisations need privacy governance that tracks context, not just redaction, if they want pseudonymization to hold up operationally.

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 obligation: A transparency obligation is a requirement to tell users when they are interacting with AI and to document how the system operates. It turns AI use into an auditable disclosure problem, which means the organisation must be able to prove what was told, to whom, and when.

What's in the full article

Securiti's full article covers the legal reasoning and implementation detail this post intentionally leaves for the source:

• Step-by-step discussion of the CJEU reasoning on personal opinions as personal data and how that affects privacy assessments
• Detailed explanation of the recipient-specific identifiability test and the role of Recital 26 in practice
• Operational implications for transparency obligations at collection time under Article 15 and related disclosure duties
• Context on how the ruling interacts with the EDPB pseudonymization guidance and the Digital Omnibus proposal

👉 The full Securiti article covers the CJEU reasoning, collection-stage transparency, and practical pseudonymization implications.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management with a focus on practical control design. It is designed for practitioners who need to connect identity governance to broader security and compliance programmes.