Why this matters
GDPR and Regulation (EU) 2018/1725 raise a question when data is pseudonymised: when exactly does “pseudonymised” data still count as personal data – and when can it be treated as anonymised or outside the scope of those rules?
Case C-413/23 P addresses identifiability and transparency. Its findings can inform a Gap Analysis and reviews of data-sharing arrangements.
The case in a nutshell
- The controller: Single Resolution Board (SRB) – an EU body that had collected comments from shareholders/creditors in a bank‐resolution context.
- The data: Feedback/comments from affected individuals (with identity known to SRB) which were then pseudonymised (alphanumeric codes) and transferred to a third‐party firm (consultant) for valuation purposes.
- The dispute: The European Data Protection Supervisor (EDPS) found that SRB failed to inform data subjects that their (pseudonymised) data would be shared. The General Court had sided with SRB that in the hands of the recipient the data was not personal data — but this judgment from the CJEU re-examines that.
Key take-aways you need to know
- Opinions/comments = personal data
The Court reiterates that an individual’s personal opinions or comments are in principle “information relating to” that person and thus fall within the concept of personal data. You don’t always need to dig deep into “purpose, effect, content” to determine that.
In practice: Even feedback-forms, surveys, voice notes, and user-comments may already engage personal-data obligations. - Pseudonymisation is not a free-pass to drop obligations
The ruling clarifies that pseudonymised data may still be personal data – but crucially, it is contextual: it depends on whether the recipient (third party) has “means reasonably likely to be used” to re-identify the data subject.
Practical assessment: When designing a PrivacyOps dashboard or automated CMP/cookie tracking, you cannot assume that “we removed the names, replaced with codes, so it’s fine”. You must assess whether any actor downstream could re-identify individuals. - Perspective matters: controller vs recipient
The Court draws an important distinction: The identifiability of the data subject must be assessed at the time of data collection and from the point of view of the controller (here SRB) – not only the recipient. However, for the recipient the data may or may not still be personal data depending on identifiability.
Documentation: Your gap-analysis or documentation templates should reflect this dual mindset: “what risks and obligations the controller has at collection” and “what the sharing/recipient side sees”. - Transparency obligations still bite
Even if the recipient cannot identify the individual, the controller must inform the data subjects at the time of collection about the possibility of transfer/disclosure to third parties (under transparency duties) — because the controller is in the position of holding the key.
→ In practice: As part of an Ongoing Compliance review, check whether the privacy notice explains the relevant sharing arrangements.
Applying the assessment to controls and documentation
- Gap Analysis: When you review processing inventories, ask: Do we share pseudonymised data with external consultants/processors/analytics? If so — document whether those external parties have means of re-identification; reflect that in risk scoring.
- Security documentation: Record the controls applied to pseudonymised data and the reasons for selecting them.
- Ongoing compliance reviews: In outsourcing models, ensure the controller’s transparency obligations and the subsequent contractual safeguards (processor/recipient cannot re-identify, etc.) are rigorously documented. Reflect this in your SOPs and client deliverables.
- Automated Compliance Toolkits / PrivacyOps Dashboards: When building dashboards tracking “pseudonymised transfers”, you may want to create a flag: “Third-party receives data – assess re-identification risk & transparency obligation”. Use the flag to prompt a documented assessment.
Practical checklist for you or your clients
- At data-collection stage:
- Have you listed all potential onward recipients (including external consultants, processors)?
- Have you informed the data subject of the possibility of such transfers (transparency notice)?
- Before transferring pseudonymised data:
- Does the recipient hold (or have access to) any additional information or “key” that allows re-identification?
- Are technical/organisational measures in place to ensure that the recipient cannot reasonably re-identify the data subject?
- In contracts / data processing agreements:
- Include a clause to specify the recipient’s inability to re-identify, if applicable.
- Define liability if re-identification becomes possible.
- In risk assessment / DPIA:
- Treat pseudonymised transfers as a potential personal-data processing activity unless you have documented proof that re-identification risk is negligible.
- Document and justify your assessment (“means reasonably likely” threshold).
- In audit / monitoring:
- Review periodically whether the recipient’s environment or external circumstances changed (e.g., new data sets, AI capabilities) so that someone could plausibly re-identify.
- Update your policies if the risk profile shifts.
Assessing identifiability
Assess identifiability in the relevant context: who holds the data, what other information they can access and which means of re-identification are reasonably likely to be used.
Record the identifiability assessment in the data-sharing review. Pseudonymisation can reduce risk, but does not create a blanket exemption.
Revisit the assessment when sharing arrangements or available information change.
Related guidance and practical next steps
.webp)
