Data Protection
Pseudonymisation and anonymisation describe different technical and legal situations. A technical examination focuses on the transformation applied to identifiers, the additional information needed for re-linking, the surrounding data flow and the realistic means available to an attacker or recipient.
Short answer
The first step is to inventory direct and indirect identifiers and determine how they are transformed. Hashing, tokenisation, encryption, lookup tables and keyed pseudonyms have different reversibility and linkability properties. The location and protection of keys or mapping tables are therefore part of the examination.
An anonymisation claim cannot be supported merely by removing names. Combinations of quasi-identifiers, external datasets and persistent behavioural patterns can retain re-identification potential. The technical report describes those properties and the tested attack model; final legal classification remains separate.
1. Inventory direct and indirect identifiers
Identifiability can arise from combinations of attributes
Direct identifiers such as names, email addresses, account numbers or device identifiers are recorded together with indirect attributes such as age, location, timestamps, rare categories or behavioural sequences. A field that is not identifying alone can become highly distinctive in combination.
The examination also considers identifiers introduced by infrastructure, including cookies, IP addresses, telemetry IDs, file metadata or stable pseudonymous keys. These may allow records to be linked over time even when obvious names are removed.
The inventory is tied to the concrete dataset and recipient context. The same attribute set can have different re-identification potential depending on what additional information is realistically available.
2. Reconstruct the pseudonymisation method
Different transformations create different technical properties
Tokenisation, keyed hashes, unkeyed hashes, deterministic encryption, random identifiers and mapping-table approaches differ in reversibility, collision behaviour and linkability. The examination identifies the actual algorithm or service and its parameters where available.
Simple hashing of a small or predictable identifier space can often be tested through dictionary or enumeration attacks. A keyed construction can change that risk if the key is protected, but key management then becomes part of the security model.
Persistent pseudonyms can support longitudinal analysis while enabling linkage across records. Rotating or context-specific pseudonyms reduce some linkage possibilities but can affect legitimate processing functions.
3. Examine additional information and separation
The mapping information is part of the technical risk
Where pseudonyms can be mapped back to identities through a table, key or service, the examination identifies where that additional information is stored, who can access it and how separation is enforced.
Access controls, network segmentation, key-management systems and organisational separation can reduce practical re-linkability. A policy statement is not sufficient evidence that the mapping material is technically isolated.
The report distinguishes the pseudonymised dataset from the complete system context. A recipient that also has access to the mapping service has a different technical capability from a recipient that receives only the pseudonymised data.
4. Do not equate anonymisation with removing names
Residual uniqueness and external linkage need an attack model
An anonymisation claim is examined against possible singling out, linkage or inference from the remaining attributes and realistic auxiliary data. Exact legal tests are outside the technical report, but technical re-identification paths can be explored and documented.
Rare combinations, detailed timestamps, precise locations and high-dimensional behavioural data can remain distinctive. Aggregation, generalisation, suppression or noise can reduce that distinctiveness, but each technique also changes analytical utility.
The examination states which attacks or auxiliary information were considered. Failure to re-identify records under one limited test does not prove that re-identification is impossible under all circumstances.
5. Consider data flow and changes of purpose or recipient
Transformation strength depends on the surrounding system
Data can be pseudonymised before export, after ingestion or only within one subsystem. The point of transformation determines which upstream systems still see direct identifiers and which recipients receive the reduced representation.
If multiple datasets use the same stable pseudonym, cross-dataset linkage may be technically possible even without direct identifiers. Conversely, separate context-specific pseudonyms can reduce unintended linkage while complicating legitimate joins.
A later change in recipient, dataset combination or processing purpose can alter the practical re-identification risk. The technical examination therefore describes the data-flow context rather than evaluating the transformation in isolation.
6. Bound the finding by technical properties and attack model
Technical resistance is not a universal anonymity certificate
The conclusion states the transformation method, direct and indirect identifiers remaining, additional information required for re-linking, access paths, tested attacks and relevant environmental assumptions.
The EDPB Guidelines 01/2025 source used here is explicitly the version published for public consultation. It is treated as a consultation document and orientation source, not as a final legal approval or a universal technical threshold.
The technical finding can describe increased separation, reduced direct identifiability or observed re-identification resistance under defined conditions. The final legal question of whether information is anonymous or pseudonymous remains a separate assessment.
Is the technical conclusion sufficiently supported?
- Are direct and indirect identifiers inventoried for the concrete dataset?
- Is the actual pseudonymisation algorithm or service identified?
- Are keys, mapping tables and other additional information included in the examination?
- Are technical separation and access controls verified rather than assumed from policy?
- Are linkage and re-identification risks considered for attribute combinations and external data?
- Is the point of transformation mapped within the data flow?
- Is the attack model and tested auxiliary information stated?
- Does the report keep technical re-identification findings separate from final legal classification?
Constructed example
A research export replaces account IDs with SHA-256 hashes. The source identifiers are sequential numbers with a small range. A dictionary test reconstructs many hashes rapidly, showing that the transformation provides little resistance without additional secret material.
A redesigned process uses keyed, context-specific pseudonyms with the key stored in a separate service and restricted access. The report describes the stronger technical separation but does not certify the resulting dataset as legally anonymous.
The example is entirely constructed and does not describe a real engagement.
Sources and technical basis
- EU guideline – consultation version EDPB Guidelines 01/2025 on Pseudonymisation, version published for public consultation. Used as an orientation source while preserving its consultation status. Open source.
- EU technical report ENISA, Pseudonymisation techniques and best practices, used for technical methods and attack scenarios. Open source.
- EU legal source Regulation (EU) 2016/679, used as the legal source for the concepts of pseudonymisation and anonymous information; legal evaluation remains separate. Open source.
- Author methodology Sources and methodology of the knowledge base; transformation, additional information, data flow and attack model are documented separately.
Further reading
- Technical Reconstruction of Data Flows
- Technical Implementation of Data Minimisation
- Data Transfers and Interfaces
- Deletion, Retention and Access Rights
Critical review and methodological limitation
Re-identification risk is contextual. A test that fails with one auxiliary dataset or one attacker capability does not establish universal irreversibility, while a successful re-identification path demonstrates only the conditions under which that path works.
Pseudonymisation can be a strong technical safeguard even though re-linking remains possible through protected additional information. The technical assessment should describe that architecture precisely instead of forcing a binary anonymous/not-anonymous label.
- Identifiers: include indirect combinations and infrastructure identifiers.
- Additional information: assess keys and mapping services as part of the system.
- Attack model: state recipient capabilities, auxiliary data and tested re-linking methods.
Translation and methodological scope
This English article is based on the reviewed German V1 source article. The translation preserves the technical meaning, methodological distinctions, source status and stated limitations. It does not strengthen technical findings into legal conclusions and does not treat technical references as proof of compliance or suitability for a specific system.
Author's technical literature and publications
The following works provide additional technical and methodological context. They do not replace required primary sources, standards, manufacturer documentation or other independent specialist sources. Unpublished manuscripts, drafts and teaching materials are deliberately not presented here as public sources.
Data Ethics & IT Compliance
Technical examination of documented data-protection, fairness, transparency and compliance-related implementation requirements.
Explore this assessment service