Teams routinely call masked or hashed data "anonymised" and then process it as if GDPR no longer applied, when in law most of it is still personal data. Data masking is an engineering technique; pseudonymisation and anonymisation are legal outcomes with different consequences. Which outcome a masked dataset reaches depends on whether the change can be reversed, who holds the means to reverse it, and how easily a record can still be singled out or linked. This guide compares the three on reversibility, legal status under the GDPR and UK GDPR, re-identification risk and fit for common use cases, including the 2025 CJEU ruling on pseudonymised data in the hands of a recipient. It is written for privacy engineers, data protection officers, data platform owners and security architects deciding how to label and govern a dataset.
Key takeaways
- Masking is a method, not a legal category. A masked dataset is pseudonymised data, anonymous information or still plainly identifiable, depending on the result, never on the tool used.
- Pseudonymised data is personal data for the controller. Recital 26 GDPR, the EDPB's 2025 pseudonymisation guidelines and the ICO all say so; pseudonymisation lowers risk and earns credit under Articles 6(4), 25, 32 and 89, but the GDPR still applies.
- Anonymous information falls outside the GDPR, and the bar is high. The test is whether anyone can identify a person by means reasonably likely to be used, and the Article 29 Working Party treats singling out, linkability and inference as the three risks to rule out.
- Who holds the key now matters in EU law. In C-413/23 P EDPS v SRB (4 September 2025) the Court of Justice held that pseudonymised data is not personal data in all cases and for every person, while the controller's duties are assessed from its own position at collection.
- Label by outcome and review it. Record the reversibility, the holders of any additional information and the re-identification assessment for every dataset, and revisit the label when the data, recipients or available auxiliary data change.
The short answer
Use pseudonymisation when you need to keep linking records about the same person (analytics, research cohorts, fraud models, joining datasets) and can keep the additional information separate and protected; treat the result as personal data. Use anonymisation only when nobody downstream needs to know who anyone is, you can show that re-identification is not reasonably likely, and you accept a real loss of detail; the result leaves the GDPR but the process of anonymising is itself processing. Use data masking as the engineering toolbox for either goal, and for operational needs such as test data and on-screen display, but never let the word "masked" stand in for a legal assessment. For the masking techniques themselves see the Data Masking vs Data Redaction and Static vs Dynamic Data Masking comparisons.
Side by side
| Dimension | Data masking | Pseudonymisation | Anonymisation |
|---|---|---|---|
| What it is | Techniques that hide or replace values (substitution, shuffling, character masking, nulling, tokens, format-preserving encryption) | Legal outcome in GDPR Art. 4(5): data can no longer be attributed to a person without additional information kept separately | Legal outcome: information that does not relate to an identified or identifiable person (Recital 26) |
| Reversibility | Varies: tokens and encryption are reversible by design; random substitution may not be | Reversible by whoever holds the additional information (lookup table or key) | Must be irreversible by means reasonably likely to be used, by anyone |
| GDPR status for the controller | Depends on the result | Personal data | Not personal data; the anonymising step is processing |
| Record-level linkage kept | Often yes (deterministic masking keeps joins) | Yes, by design | No stable link to an individual |
| Main residual risk | Unmasked source copies, weak techniques, quasi-identifiers left intact | Theft of the secret, linkage through quasi-identifiers, inference | Singling out, linkage with outside data, inference, especially as auxiliary data grows |
| Typical use | Test and development data, support screens, demos | Analytics, research, data sharing with processors, ML training on individual records | Open data, published statistics, external sharing where individuals are not needed |
| Ongoing obligations | Those of the resulting category | All GDPR duties, with risk reduction credited | Periodic re-assessment, governance of the release |
Reversibility: the first question to ask
Reversibility decides most of the legal answer, so record it precisely for each transformation:
- Reversible by design: vault tokenisation, deterministic encryption and format-preserving encryption. Whoever holds the token vault or the key can recover the original. This is pseudonymisation at best. See the Tokenisation vs Encryption comparison and Format Preserving Encryption.
- Reversible by inference: keyed hashes (HMAC) cannot be inverted without the key, but anyone with the key can recompute the hash for a known identifier and match it. Plain unsalted hashes of emails, phone numbers or national identifiers can be reversed by dictionary because the input space is small.
- Not reversible from the value, but linkable: random substitution with a consistent mapping table. Destroy the table and the value cannot be recovered, yet a consistent pseudonym still links every record about a person, so other attributes may identify them.
- Not reversible and not linkable: nulling, generalisation into bands, aggregation, noise addition and synthetic replacement. These are the building blocks of anonymisation, but irreversibility of each field does not make the dataset anonymous if the remaining combination of attributes is unique.
The Pseudonymisation Techniques Guide covers the transformation methods and secret handling in depth; this page focuses on what each result means legally.
Legal status under the GDPR and UK GDPR
Pseudonymisation
Article 4(5) GDPR defines pseudonymisation as processing personal data so that it can no longer be attributed to a specific data subject without the use of additional information, provided that information is kept separately and protected by technical and organisational measures. Recital 26 states that pseudonymised data which could be attributed to a person by the use of additional information should be considered information on an identifiable natural person. The EDPB's Guidelines 01/2025 on pseudonymisation (adopted for consultation on 16 January 2025; the consultation closed on 14 March 2025) take the same position, including where the additional information is held by another party, and introduce two useful terms: the pseudonymisation secret (the lookup table or key) and the pseudonymisation domain (the set of people or systems from whom attribution is meant to be withheld). The ICO's guidance says plainly that pseudonymous information is still personal data and the law applies to it.
What pseudonymisation buys you is risk reduction that the regulation credits:
| GDPR provision | How pseudonymisation counts |
|---|---|
| Art. 6(4)(e) | Appropriate safeguards, which may include encryption or pseudonymisation, are a factor when assessing whether further processing is compatible with the original purpose |
| Art. 6(1)(f) | The EDPB says the risk reduction achieved can be considered in the legitimate interests balancing test |
| Art. 25(1) | Named as an example of a data protection by design measure; Recital 78 adds pseudonymising personal data as soon as possible |
| Art. 32(1)(a) | Pseudonymisation and encryption are listed security measures; the EDPB notes pseudonymisation is normally not sufficient on its own |
| Art. 89(1) | A safeguard for archiving, scientific or historical research and statistics; Recital 156 gives it as an example |
| Art. 11(1) | A controller that no longer needs to identify people is not obliged to keep or acquire additional information just to comply with the regulation |
Recital 75 lists unauthorised reversal of pseudonymisation as a risk to data subjects, which is why theft or misuse of the secret should be handled as a potential personal data breach.
Anonymisation
Recital 26 states that the principles of data protection should not apply to anonymous information, and that identifiability is judged by all the means reasonably likely to be used, by the controller or by another person. The Article 29 Working Party Opinion 05/2014 on anonymisation techniques (WP216), still the most cited EU reference on the point, describes anonymisation as processing that irreversibly prevents identification and says pseudonymisation is not a method of anonymisation. It assesses each technique against three risks: singling out, linkability and inference. It also warns that anonymisation is not a one-off exercise and advises against a "release and forget" approach. The ICO adds that applying anonymisation techniques is itself processing of personal data, so you need a lawful basis and a compatible purpose for that step. The ICO notes that its anonymisation guidance is under review following the Data (Use and Access) Act, so check the current version before relying on UK detail.
The relative view after EDPS v SRB
In Case C-413/23 P, decided on 4 September 2025 under the EU institutions' data protection regulation (Regulation 2018/1725, whose definitions mirror the GDPR), the Court of Justice considered comments that the Single Resolution Board had pseudonymised and passed to a consultancy that held no key. According to the Court's press release, pseudonymised data must not be regarded as constituting, in all cases and for every person, personal data: depending on the circumstances, pseudonymisation may stop recipients other than the controller from identifying the data subject. The Court also held that the controller's information duty is assessed at the time of collection and from the controller's point of view, so the SRB still had to tell data subjects about the recipient.
Practical reading for engineers and DPOs:
- For you as controller: nothing changes. If you hold, or can obtain, the additional information, the data is personal data and every GDPR duty applies, including transparency about recipients.
- For a recipient: data may fall outside the GDPR for that recipient only if it genuinely lacks means reasonably likely to be used to re-identify, which depends on contracts, technical separation and the auxiliary data it holds. This is a case-by-case assessment, not a blanket exemption.
- For design: the strength of separation (who can reach the secret, what other data the recipient has) now carries legal weight, so document it in the data sharing agreement and the record of processing.
Re-identification risk in each option
| Risk (WP216) | Masked data | Pseudonymised data | Anonymised data |
|---|---|---|---|
| Singling out | High if quasi-identifiers (date of birth, postcode, job title) are untouched | Present by design: each pseudonym is one person | Must be prevented, typically by generalisation, suppression or aggregation |
| Linkability | High with deterministic masking reused across systems | High within the domain; controlled by per-recipient keys or domains | Must be prevented across releases and against public data |
| Inference | Sensitive attributes often left in clear | Sensitive attributes usually present | Must be limited; WP216 notes k-anonymity does not prevent inference attacks |
| Key or table compromise | Reverses tokenised or encrypted fields | Reverses the whole dataset | No key should exist |
Measuring the risk, running a motivated intruder test and choosing release models are covered in the Anonymisation and Re-identification Risk Guide. NIST SP 800-188 makes a related point for public sector releases: tools that merely mask personal information may not provide enough functionality for de-identification, and it recommends a disclosure review board to approve releases.
Threat model and controls per option
Data masking
- Threats: the unmasked source extract left in a staging bucket; developers with access to the masking rules or vault; inconsistent rules across environments; masked values that are realistic enough to be mistaken for real data in a breach notice assessment.
- Controls: mask in the pipeline before data lands in lower environments, delete intermediate extracts, version-control masking rules, test outputs for residual identifiers, and restrict who can run unmasking functions.
Pseudonymisation
- Threats: theft of the secret; one key used for every recipient so datasets can be joined; analysts re-identifying via quasi-identifiers; secrets stored next to the data.
- Controls: keep the secret in a separate trust domain (HSM or key management service with separate administrators), use distinct keys or domains per recipient or purpose, contractually forbid re-identification attempts, log every lookup and re-identification request, and rotate keys when a domain changes.
Anonymisation
- Threats: new public datasets that enable linkage; repeated releases that can be differenced; small cells in aggregates; synthetic data that memorises outliers.
- Controls: documented re-identification assessment, minimum cell sizes and suppression rules, differential privacy for query interfaces where suitable, a release register, and scheduled re-assessment. See the Differential Privacy Guide and the Synthetic Data Risk Guide.
Where identity fits
The control that separates pseudonymisation from simple masking is access to the secret, and in modern pipelines that access belongs to machines rather than people. ETL jobs, tokenisation services, data platform service principals and AI agents that call a detokenise API all hold the means to re-identify. Treat each as a privileged non-human identity: give it a narrow scope (tokenise only, or detokenise for named fields), keep detokenise permissions out of analytics workloads, issue short-lived credentials, and alert on detokenise volume spikes. A pseudonymisation domain is only as strong as the weakest service account inside it. See the Data Minimisation guide for limiting what each workload receives in the first place.
Decision guidance and use cases
| Use case | Usually the right outcome | Why |
|---|---|---|
| Test and development databases | Masking aiming at pseudonymisation or better, with no route back to production values | Realistic, referentially intact data without production exposure; SA-3(2) in SP 800-53 addresses live data use |
| Customer support screens | Dynamic masking on display | Source remains personal data; masking limits exposure by role |
| Longitudinal analytics and cohort research | Pseudonymisation | Needs stable linkage over time; Art. 89 safeguards |
| Sharing with a processor or consultancy | Pseudonymisation with recipient-specific domain | After EDPS v SRB, separation strength affects the recipient's position; controller duties remain |
| Training ML models on individual records | Pseudonymisation, plus privacy-preserving training where outputs are shared | Models can memorise; see the Differential Privacy vs Anonymisation for AI Training Data comparison |
| Open data and published statistics | Anonymisation | Recipients are unknown and may hold any auxiliary data |
- Choose pseudonymisation when: you must re-contact, correct or delete individuals, or join data over time, and can run a separate key custody function.
- Choose anonymisation when: the purpose works on aggregates or heavily generalised records and you can defend the result against a motivated intruder.
- Small organisations: rely on well-supported features (database masking, a managed tokenisation or key service) and default to treating outputs as personal data; anonymisation claims need assessment effort that small teams rarely have.
- Large organisations: centralise key custody, define pseudonymisation domains per business unit or recipient, and run a disclosure review step for any dataset labelled anonymous.
Worked scenario: a health insurer
A health insurer wants to give claims data to an analytics consultancy, build a test environment for a new claims system and publish regional claims statistics.
- Consultancy: member numbers are replaced with HMAC pseudonyms under a key unique to this contract, held by the insurer's key service. Dates of birth become year of birth and postcodes become districts. The contract forbids re-identification and onward linkage. The insurer still treats the dataset as personal data, names the recipient in its privacy notice and records the separation measures; whether the data is personal for the consultancy depends on those measures.
- Test environment: a static masking job substitutes names, addresses and member numbers with synthetic values and shuffles diagnosis codes within age bands, with no mapping table kept. The job runs inside production, so no unmasked extract reaches the test network. Residual identifier scans run on every refresh.
- Published statistics: claims are aggregated by region and quarter, cells under the agreed threshold are suppressed, and a disclosure review signs off before each release. This is the only output labelled anonymous.
How to implement
- Inventory and label: list datasets described as masked, hashed, tokenised or anonymised and record the technique, reversibility and holders of any secret.
- Correct the labels: reclassify anything reversible or linkable as personal data in the record of processing; this often brings data back into scope for retention and subject rights.
- Separate the secrets: move keys and lookup tables into a separate trust domain and scope the service identities that can reach them.
- Define domains: issue distinct keys per recipient or purpose so datasets cannot be joined without authorisation.
- Assess anonymous releases: run a documented singling out, linkability and inference assessment and a motivated intruder test before any release labelled anonymous.
- Pilot and roll back: trial new masking or pseudonymisation rules on a copy, compare analytic results with the source, and keep the previous rule set ready so a broken job can be reverted without exposing raw data.
- Review: re-assess labels when recipients, attributes or public auxiliary data change, and at least annually for published datasets.
Detection and measurement
- Label accuracy: share of datasets whose label (masked, pseudonymised, anonymous) matches a documented reversibility and risk assessment.
- Secret separation: number of identities with access to both pseudonymised data and its secret, trending to zero outside break-glass roles.
- Detokenise activity: volume of re-identification and detokenise calls per identity, with alerts on spikes or new callers.
- Residual identifiers: findings from automated scans of lower environments and released datasets for direct identifiers.
- Release reviews: share of anonymous releases with a completed assessment and a scheduled re-review date.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| GDPR | Art. 4(5), Recital 26, Art. 6(4)(e), 11, 25, 32(1)(a), 89 | Definitions, legal status and credited safeguards |
| NIST SP 800-53 Rev 5 | SI-19 De-identification; SI-19(4) Removal, Masking, Encryption, Hashing, or Replacement of Direct Identifiers; SI-19(6) Differential Privacy | Techniques and governance for de-identified data |
| NIST SP 800-53 Rev 5 | SA-3(2) Use of Live or Operational Data; PT-3 Personally Identifiable Information Processing Purposes | Test data and purpose limitation |
| NIST CSF 2.0 | PR.DS-01 data at rest; ID.AM-07 data inventories; GV.OC-03 legal and privacy requirements | Protection, inventory and legal context |
| ISO/IEC 27001:2022 | Annex A 8.11 Data masking | Masking policy aligned with access control and legal requirements |
Common failure patterns
- "Hashed, therefore anonymous": unsalted hashes of emails or phone numbers shared as anonymous data, then reversed by dictionary.
- Key next to the data: the tokenisation key or lookup table stored in the same warehouse or readable by the same service principal as the pseudonymised tables.
- One pseudonym everywhere: the same deterministic key used for every recipient, so separate releases can be joined back into a profile.
- Quasi-identifiers left in clear: names masked but full date of birth, postcode and gender retained, which together single out most people.
- Misreading EDPS v SRB: a controller drops transparency or security duties because the recipient "cannot identify anyone", when the ruling assesses the controller from its own position.
- Release and forget: a dataset judged anonymous years ago is never re-assessed as new public data appears.
Practitioner checklist
- Stop using "anonymised" for any dataset that is reversible or linkable by anyone, including you.
- Record reversibility, secret holders and the pseudonymisation domain for every transformed dataset.
- Keep pseudonymisation secrets in a separate trust domain with separate administrators and logging.
- Issue distinct keys per recipient or purpose and forbid re-identification by contract.
- Scope tokenise and detokenise permissions for service accounts and agents separately.
- Run singling out, linkability and inference assessments before any anonymous release.
- Keep transparency duties for recipients of pseudonymised data regardless of their position.
- Mask test data in the pipeline so no unmasked extract reaches lower environments.
- Re-assess anonymous and pseudonymised labels on a schedule and when context changes.
Standards and references
- EUR-Lex: Regulation (EU) 2016/679, General Data Protection Regulation
- EDPB: Guidelines 01/2025 on Pseudonymisation
- Court of Justice of the EU: Press release on Case C-413/23 P EDPS v SRB
- Article 29 Working Party: Opinion 05/2014 on Anonymisation Techniques
- ICO: Anonymisation guidance
- ICO: Introduction to anonymisation
- NIST: SP 800-188 De-Identifying Government Datasets
Related NHI Mgmt Group resources: Pseudonymisation Techniques Guide · Anonymisation and Re-identification Risk Guide · Tokenisation and Data Masking Guide · GDPR Compliance Guide for Security Teams. This guide summarises GDPR and UK GDPR positions on masking, pseudonymisation and anonymisation and is not legal advice.