Scope
This guide helps your data governance team audit current personal data classifications following the Court of Justice of the European Union's SRB ruling. You'll find the regulatory context, a classification decision tree, and a reference table for common edge cases that may now require reclassification under GDPR Article 4(1).
The ruling doesn't create new obligations, but it clarifies boundaries that many organizations have interpreted differently. If your team has debated whether certain identifiers or pseudonymized datasets qualify as personal data, this decision provides binding precedent.
Key Concepts and Definitions
Personal Data (GDPR Article 4(1)): Any information relating to an identified or identifiable natural person. The SRB ruling emphasizes that "relating to" has a broader scope than many compliance teams assumed.
Identifiable Person: Someone who can be identified, directly or indirectly, particularly by reference to an identifier such as a name, identification number, location data, or online identifier. The ruling reinforces that indirect identifiability counts, even when your organization alone cannot perform the identification.
Pseudonymized Data: Data that can no longer identify a subject without additional information, provided that additional information is kept separately and subject to technical and organizational measures. The SRB decision clarifies that pseudonymization doesn't remove data from GDPR scope; it remains personal data with a modified risk profile.
Data Relating To: The ruling expands on three connections that establish the "relating to" test:
- Content: information about a person
- Purpose: information used to evaluate, treat, or influence a person's status or behavior
- Result: information whose use is likely to impact a person's rights and interests
Requirements Breakdown
Article 4(1) Interpretation Post-SRB
The Court emphasized that you can't narrow the definition of personal data by focusing only on direct identifiers. Your classification must consider:
Reasonably likely identification: Even if your team can't identify someone using a dataset, it's still personal data if another party could reasonably do so using legal means.
Combined datasets: Data that seems anonymous in isolation may become personal data when combined with other information, whether you hold that information or not.
Future identifiability: You must assess whether identification is possible now or could become possible with technological advancement or additional data acquisition.
Practical Classification Test
Ask these questions in sequence:
Step 1: Does the data contain direct identifiers (name, email, national ID number)?
→ Yes = Personal data, proceed to processing requirements
→ No = Continue to Step 2
Step 2: Could your organization identify an individual by combining this data with other information you hold?
→ Yes = Personal data
→ No = Continue to Step 3
Step 3: Could another party (vendor, data broker, government agency) reasonably identify individuals using legal means?
→ Yes = Personal data
→ Uncertain = Treat as personal data until you document why identification isn't reasonably likely
Step 4: Does the data relate to an individual by content, purpose, or result?
→ Yes to any = Personal data
→ No to all = Document your analysis; consider a Data Protection Impact Assessment
Implementation Guidance
Audit Your Current Classifications
Start with datasets your team has previously classified as non-personal or anonymized:
Hashed Email Identifiers: Even with salt, these remain personal data because the underlying email is recoverable by the party that created the hash, or through rainbow table attacks for common domains.
IP addresses: The SRB ruling reinforces that dynamic IP addresses are personal data for website operators, even if you don't have ISP subscriber information, because the ISP can identify the user.
Device IDs and Mobile Advertising IDs: These qualify as online identifiers under Article 4(1). Don't rely on reset capability to argue they're not personal data.
Aggregated metrics with small cohorts: If a segment contains fewer than 50 individuals, re-identification risk may be high enough to treat the aggregated data as personal data.
Update Your Legal Basis Documentation
For each dataset you reclassify:
- Document which Legal Basis for Processing applies (Article 6(1)(a), (f))
- If you previously processed without consent based on anonymization, determine whether you now need Prior Consent
- Update your Records of Processing Activities (Article 30)
- Assess whether existing privacy notices accurately describe the processing
Vendor and Third-Party Review
Your Data Processing Agreements must reflect accurate data classifications. Review contracts where you've stated "no personal data is shared" but the SRB test suggests otherwise:
- Analytics vendors receiving pseudonymized user IDs
- Ad tech partners receiving hashed identifiers
- Cloud storage containing "anonymized" logs
If the vendor can re-identify individuals, you're a data controller transferring personal data, and Chapter V transfer mechanisms apply.
Common Pitfalls
Assuming pseudonymization = anonymization: Pseudonymization is a security measure under Article 32, not a path out of GDPR scope. The SRB ruling confirms that pseudonymized data remains personal data.
Relying on "we can't identify them": Your inability to identify someone doesn't determine classification. The test is whether identification is reasonably likely by any party.
Treating aggregation as a classification exit: Aggregated data can still relate to individuals if the cohort is small or the metrics reveal individual behavior patterns.
Ignoring indirect identifiers: Online identifiers, location data, and device characteristics count. The ruling reinforces that Article 4(1) explicitly includes these.
Misapplying the "means reasonably likely to be used" test: This test (from Recital 26) applies to anonymization claims, not to whether data is personal. If someone could identify individuals using legal means, it's personal data.
Quick Reference Table
| Data Type | Pre-SRB Gray Area | Post-SRB Classification | Key Requirement |
|---|---|---|---|
| Hashed Email Identifiers (salted) | Often treated as pseudonymized or anonymous | Personal data | Article 6 Legal Basis required |
| Dynamic IP addresses | Debated for website operators | Personal data | Prior Consent for Terminal Equipment Access |
| Mobile Advertising IDs | Sometimes treated as device data | Personal data (online identifier) | Granularity for different processing purposes |
| Pseudonymized user IDs | Assumed outside GDPR if keys separated | Personal data | Data Processing Agreements with vendors |
| Aggregated cohorts (<50 users) | Treated as anonymous | Likely personal data | Re-identification risk assessment |
| Cookie IDs | Mixed treatment | Personal data | Consent before storage (ePrivacy) |
| Server logs (pseudonymized) | Often excluded from scope | Personal data if identifiable | Retention limits (Article 5(1)(e)) |
| Behavioral segments | Treated as anonymous profiles | Personal data by "result" test | Purpose Disclosure in privacy notice |
Next Steps
- Schedule a classification audit for datasets marked "non-personal" or "anonymized" in your Records of Processing Activities.
- Review your Consent Management Platform configuration; consent you didn't collect because you believed data was anonymous may now be required.
- Update vendor questionnaires to ask whether they can re-identify individuals from data you share.
- Document your reasoning for any dataset you continue to treat as non-personal data, including why identification isn't reasonably likely.
The SRB ruling doesn't require perfection, but it does require honest assessment. If you're uncertain whether a dataset is personal data, the safer path is to treat it as such until you can document otherwise.
