A practical example of Recital 26 is treating data as personal if an organisation can reasonably link it back to a person using other information it holds. Security teams should not assume pseudonymised or hashed data is outside scope, and should assess re-identification risk, access to auxiliary data and the controls needed to prevent linkage.
How Recital 26 works in a real security decision
In practice, recital 26 asks teams to look at the whole re-identification picture, not just whether a record is stripped of obvious identifiers. If an organisation can reasonably link a dataset back to a person using other data it already holds, that dataset should still be treated as personal data for risk and control purposes.
The key operational point is that “pseudonymised” is not the same as “outside scope”. Security teams should assess whether linkage is possible through reference tables, shared attributes, enrichment sources, logs, or business systems that can reconnect the record to an individual.
What makes linkage risk material
Recital 26 becomes practical when a dataset looks anonymous in isolation but becomes identifiable when combined with auxiliary information. That is common where one team holds a tokenised or hashed dataset and another team, system, or vendor holds the map, lookup key, or enough contextual attributes to reconstruct identity.
This is why data classification, access control, and separation of duties matter. A dataset may be low risk for one team and high risk for another if only one of them can reasonably re-link it. The relevant question is not “can someone guess the identity from the record alone?” but “can the organisation reasonably identify the person from the record plus other available information?”
Teams should also remember that pseudonymisation can reduce exposure without removing regulatory scope. That distinction matters for retention decisions, lawful sharing, DPIA-style assessment, and incident response because the controls required for linkable data are usually stronger than those for truly non-identifiable data.
What security teams should check before calling data anonymised
The first check is whether any party in the current environment can reverse or re-create identity using held data, privileged access, or cross-system joins. If the answer is yes, the safer assumption is that the data remains in scope and must be governed accordingly.
The second check is whether the organisation can reasonably prevent linkage over time. Data that is not identifiable today can become identifiable after a new dataset is acquired, a key is exposed, or a business unit starts sharing records more broadly.
The third check is whether the security model protects the auxiliary information as strictly as the dataset itself. If a lookup table, token vault, or correlation data is easier to access than the primary record, the real privacy control failure is often in the supporting system rather than the dataset that is being analysed.
Risk and Threat Considerations
Recital 26 matters because re-identification risk is often created by ordinary operational data, not by a deliberate attack on the main dataset. If auxiliary information is too widely accessible, a supposedly masked dataset can be linked back to individuals through routine joins, export abuse, or internal misuse.
Failure mechanism: The organisation overestimates the protection provided by pseudonymisation or hashing, while a second dataset, lookup table, or business process still enables reasonable identification. That can turn a dataset believed to be low sensitivity into personal data with a broader compliance and exposure footprint.
Impact: Inaccurate classification can lead to under-protecting data, over-sharing it internally or externally, and missing the controls needed for access limitation, retention, and incident handling. If linkage is feasible, the security and governance posture should be built as though the data remains personal.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
GDPR provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | A.5.15 — Security of processing | Recital 26 directly affects when data remains personal and needs security of processing. |
| A.5.1 — Policies for information security | Recital 26 drives policy decisions on classification, sharing, and retention of linkable data. | |
| A.5.12 — Classification of information | Recital 26 is a classification test for whether data should still be treated as personal. | |
| Recommendation — Assess linkability before downgrading controls on pseudonymised data. Classify data by reasonable re-identification risk, not by masking alone. Treat data as personal when auxiliary data makes re-identification reasonably possible. | ||
Practitioner Guidance
What to verify: Confirm whether anyone in the organisation, including analysts, support teams, or vendors, can reasonably re-identify the data using existing systems, reference data, or enrichment sources. If linkage is possible, document that the data remains in scope and align controls to that reality.
Decision rule: If the dataset can be linked back to a person with information the organisation already holds, do not treat pseudonymisation or hashing as a reason to downgrade the control set. If re-identification is not reasonably possible, re-test that assumption whenever new data sources, sharing arrangements, or lookup capabilities are introduced.
What practitioners underestimate: The most common mistake is focusing only on the dataset itself and ignoring the auxiliary information that makes identification feasible. The practical test is not whether the record looks anonymous in a spreadsheet, it is whether the organisation can still reconnect it to a person in normal operations.
Practitioner takeaway: Recital 26 is an operational test of linkability, so the right control question is whether your environment can still re-identify the person, not whether the data looks anonymous in isolation.