When “pseudonymised” doesn’t automatically mean “safe” for transparency obligations

Why this matters

In the compliance world (whether under the General Data Protection Regulation (GDPR) or Regulation (EU) 2018/1725 for EU-institutions), one of the trickiest questions is: 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?
The judgment in Case C-413/23 P gives fresh, concrete clarification — and it has direct relevance for how you set up services such as your Gap Analysis, DPO-as-a-Service, cookie audits, and automated PrivacyOps dashboards.

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

1. 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.
   → For your clients: Even feedback-forms, surveys, voice notes, and user-comments may already engage personal-data obligations.
2. 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.
   → For your services: 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.
3. 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.
   → For your deliverables: 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”.
4. 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: In your “KVKK Startup Launchpad” or “Ongoing Compliance Management” packages you should ensure the privacy notice/consent mechanism includes disclosure of such transfers (even to pseudonymised recipients) when applicable.

How this applies to Kooch’s service catalogue

• 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.
• ISO 27001 Readiness & Documentation: Under Annex A controls (e.g., A.18.1.4 Privacy, A.18.1.3 Compliance) you must capture this nuance. The case reinforces that “data shared pseudonymously” still may require full personal-data controls.
• DPO-as-a-Service / Ongoing Compliance: 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”. This case gives legal backing for that workflow.

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.

Final thoughts

This CJEU judgment doesn’t make life easier by giving bright-line rules. Instead, it emphasises context, perspective and reasonableness. For compliance consultants like us it underscores a key truth: the legal classification of data – personal vs non-personal – is not static or purely technical. It depends on who holds data, what access they have, and what the risk of re-identification is.

For Kooch and our clients, this means: when building service packages, documentation, dashboards and workflows — we must embed this flexibility and reasoned assessment. Pseudonymisation remains a valuable risk-mitigation tool—but it cannot be treated as a blanket exemption.

Ready to treat pseudonymised transfers with the nuance they demand? Let’s ensure our next client’s “data sharing to third parties” checklist is aligned with the new reality.