GDPR Recital 26 explains when data counts as personal data and when it does not. It says identification depends on all means reasonably likely to be used, directly or indirectly, by the controller or another person, so pseudonymized data may still be personal data if reidentification remains feasible.
How Recital 26 Defines Personal Data
recital 26 is the lens the gdpr uses for borderline cases. The core test is not whether data is directly named or obviously identifying on its face, but whether a person can be identified by means reasonably likely to be used, directly or indirectly, in context.
That makes the recital especially important for pseudonymized datasets, logs, analytics exports, and shared research records. A dataset can move away from obvious identifiers without moving outside GDPR if reidentification remains realistic.
Why Reasonably Likely Means Context Matters
The recital requires a practical assessment, not an abstract one. Controllers need to think about the likely tools, auxiliary data, internal access paths, cost, time, and technical effort that would be needed to identify someone.
This is why the same data can be personal data in one organisation and less clearly so in another. If a controller, a partner, or another person can reasonably combine the dataset with other available information, the identification risk remains part of the GDPR analysis.
Pseudonymisation, Reidentification, and Boundary Cases
Recital 26 is often misunderstood as a safe harbour for pseudonymisation. It is not. Pseudonymized data may still be personal data when the link back to an individual can be restored with means that are realistically available.
That matters for design choices around tokenization, identifiers, and shared environments. Strong pseudonymisation can reduce risk, but it does not by itself erase the legal status of the data if reidentification remains feasible.
What This Means for Handling Data Safely
Because Recital 26 sits behind the definition of personal data, it affects classification, sharing, retention, access control, and security-by-design decisions. It is the reason teams should not assume that removing names alone makes a dataset outside GDPR. GDPR Compliance Guide for Security Teams is a useful companion for the operational side of that decision-making.
When the identification test is still met, organisations should treat the data as regulated personal data and apply the appropriate governance, technical, and contractual safeguards. That includes understanding who can reidentify, what auxiliary data exists, and whether disclosure changes the practical exposure.
Risk and Threat Considerations
Recital 26 creates a real exposure zone for organisations that assume pseudonymized data is automatically outside GDPR. If reidentification is reasonably likely, a dataset can still carry privacy, disclosure, breach-notification, and regulatory risk even when obvious identifiers are removed.
Failure mechanism: Teams underestimate the power of linkage attacks, auxiliary datasets, or internal access paths, then share or store data under the wrong legal and security assumptions.
Impact: Personal data may be processed with weaker controls than required, increasing the chance of unlawful disclosure, poor governance, and avoidable compliance findings.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
GDPR and ISO/IEC 27001:2022 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art. 4(1) — Personal Data | Defines personal data by identifiability, which Recital 26 interprets. |
| Art. 25 — Data Protection by Design and by Default | Recital 26 shapes design choices for pseudonymisation and minimisation. | |
| Art. 32 — Security of Processing | Recital 26 affects what security measures are needed when data remains identifiable. | |
| Recommendation — Assess whether identification remains reasonably likely before classifying data as personal data. Build privacy controls so reidentification risk is reduced by design. Apply security controls proportionate to the residual identifiability of the data. | ||
| ISO/IEC 27001:2022 | A.5.12 — Classification of information | Recital 26 depends on classifying data according to identifiability and handling needs. |
| Recommendation — Classify datasets by residual identifiability before deciding how they may be shared or protected. | ||
Practitioner Guidance
Why practitioners should care: Recital 26 is a classification rule, but it has concrete operational consequences. The moment reidentification is realistically possible, privacy, security, and legal obligations can all remain in force.
Common misunderstanding: Pseudonymized is often treated as equivalent to anonymized. In practice, those are very different states, and Recital 26 makes the difference hinge on what can still be reasonably done with the data.
Practitioner takeaway: Treat the identification question as a contextual risk assessment, not a naming exercise, and use the result to drive both control selection and data-sharing decisions.