Anonymisation and Re-identification Risk Guide: Testing Identifiability and Making Release Decisions

Most datasets described as "anonymised" are only stripped of names, and the remaining combinations of dates, locations and attributes are often enough to single people out or link them back to other records. Data protection law only stops applying when the risk of identification is sufficiently remote, judged against the means reasonably likely to be used, and that judgement depends on who receives the data and how. This guide is about making that judgement well: how to find quasi-identifiers, measure re-identification risk, run a motivated intruder test, match techniques to the release model, and document a defensible release decision. It is written for privacy engineers, data protection officers, data platform owners and security teams who approve data sharing. The Privacy-Enhancing Technologies Guide covers the wider PET toolbox; this guide goes deeper on the risk assessment and release decision.

Key takeaways

• Anonymous is a conclusion, not a technique. It is the outcome of a risk assessment about specific data, a specific recipient and a specific environment, and it can change over time.
• Pseudonymised data is still personal data. Replacing names with codes or hashes leaves singling out and linkage possible, and the ICO and the WP29 opinion both treat it that way.
• The release model sets the bar. Public release needs the strongest treatment because control is lost; a controlled environment with contracts and access controls can safely hold richer data.
• Test like an attacker. A motivated intruder test, using the public sources and background knowledge a competent person could obtain, is the practical proof that a release is safe.
• Write the decision down and revisit it. New datasets, new recipients, new purposes and new techniques are all triggers to reassess.

The legal line: when data stops being personal

Recital 26 of the GDPR (and UK GDPR) says data protection principles apply to information about an identified or identifiable person, that identifiability is judged by the means reasonably likely to be used, taking account of cost, time and available technology, and that anonymous information falls outside the law. Pseudonymisation, defined in Article 4(5) as processing so that data can no longer be attributed to a person without additional information kept separately, reduces risk but does not take data outside the law.

• Anonymisation is processing: the ICO is explicit that turning personal data into anonymous information is itself processing personal data, so it needs a lawful basis, a defined purpose and transparency.
• Relative, not absolute: the ICO notes that the same dataset may be anonymous in one organisation's hands and personal data in another's, because identifiability depends on what other information each party holds or can reach.
• Zero risk is not required: the ICO's test is whether identification is reasonably likely in the circumstances, and an educated guess without a reasonable basis does not amount to identification.
• Terminology: the ICO avoids the term "de-identified" because UK data protection law does not define it; HIPAA, by contrast, defines de-identification precisely. Say which regime you are working under.
• Re-identification can be a crime: in the UK, section 171 of the Data Protection Act 2018 makes it an offence knowingly or recklessly to re-identify de-identified personal data without the consent of the controller that de-identified it, with defences that include effectiveness testing under section 172. See the UK GDPR and Data Protection Act 2018 Guide.

The ICO's anonymisation guidance was marked as under review after the Data (Use and Access) Act 2025 when checked on 27 October 2026, so confirm the current version before relying on specific wording.

HIPAA de-identification

For US health data, 45 CFR 164.514(b) gives two routes. Safe Harbor removes 18 identifier types of the individual and of relatives, employers and household members, keeps only the first three digits of a ZIP code where that area has more than 20,000 people, keeps only the year of dates, groups ages over 89 as 90 or older, and requires no actual knowledge that the remainder could identify someone. Expert Determination requires a qualified expert to determine and document that the risk an anticipated recipient could identify someone is very small; HHS sets no numeric threshold and a determination may be time-limited. Re-identification codes are allowed under 164.514(c) if they are not derived from individual information and the mechanism is not disclosed.

Spectrum of identifiability and the three tests

The ICO describes identifiability as a spectrum with a blurred middle band where judgement is needed. WP29 Opinion 05/2014 gave the three questions that are still the standard way to assess where a dataset sits:

Direct identifiers, quasi-identifiers and sensitive attributes

• Direct identifiers: name, email, phone, national ID, account and device numbers, IP addresses, photos. These must go or be replaced, but removing them is only the start.
• Quasi-identifiers: attributes that are harmless alone but identifying in combination, and likely to be known to an intruder: date of birth, sex, postcode, occupation, ethnicity, dates of events (admission, hire, transaction), rare conditions, timestamps and location traces.
• Sensitive attributes: the values the data is released for (diagnosis, salary, offence) whose disclosure causes harm. Inference risk concerns these.
• Free text and unstructured data: notes, comments, transcripts, images and audio hide identifiers that structured tools miss. HHS notes free text must be checked under HIPAA, and the ICO says qualitative data usually needs human review, redaction and blurring.
• Longitudinal and location data: sequences of events or places are highly distinctive. A handful of time-stamped locations can be unique to one person even when every value is coarse.

Measuring re-identification risk

Risk measurement gives the assessment numbers rather than adjectives. Use the measure that fits the attack you are worried about.

Attack models: practitioners commonly distinguish three. A prosecutor attack targets a specific person known to be in the data (the highest risk per individual); a journalist attack targets anyone who can be re-identified to show the release failed; a marketer attack tries to re-identify as many records as possible, so average risk matters. Public releases should be judged against the journalist model at least; releases to a controlled environment where the recipient might know people in the data (an employer, an insurer) need the prosecutor model.

Techniques and what they leave behind

WP29 concluded that each technique it examined fails to meet the criteria for effective anonymisation with certainty on its own, so combine them and assess the result. Its assessment of residual risk:

• Generalisation: age bands instead of dates of birth, postcode district instead of full postcode, month instead of date. Choose granularity from the analysis need, not from what the source system holds.
• Suppression: remove outlier records or cells that remain unique after generalisation, and record how many were removed because suppression biases results.
• Randomisation: noise, swapping or synthetic data. The ICO warns that too little noise leaves data identifiable and too much makes it useless. See the Synthetic Data Risk Guide.
• Masking: removing direct identifiers is necessary but, as the ICO says, not effective on its own.
• Keyed hashing for linkage codes: an unkeyed hash of an email or national ID can be reversed by hashing a list of candidates. If linkage is needed, use a keyed function with the key held by a separate party, and treat the output as pseudonymised data. See the Pseudonymisation Techniques Guide and the Tokenisation and Data Masking Guide.

Release models and the release decision

The ICO ties the strength of anonymisation to the release environment, and NIST SP 800-188 lists the main sharing models for government data. The environment is part of the control set.

Decision guidance: if the analysis needs detailed records about rare groups, do not try to anonymise for open release: use an enclave or a query interface. If the purpose is published statistics, release aggregates with small cell suppression rather than microdata. If a vendor needs data for testing, ask whether synthetic data meets the need before sharing any real records. Small vs large organisations: a small organisation sharing occasional extracts should default to aggregates or a contract-controlled release with a short documented assessment; a large data holder releasing regularly should run a standing disclosure review board, as NIST SP 800-188 suggests, use risk measurement tools and keep a register of releases.

Running a motivated intruder test

The ICO's motivated intruder is reasonably competent, has ordinary resources such as the internet, libraries and public records, and uses investigative techniques. They may be a journalist, an estranged partner, a stalker or a researcher; more sensitive data justifies assuming a more capable intruder.

1. Define the intruder: write down who would want to identify people in this data, what they might already know (a colleague, a neighbour, a relative) and what the data is worth to them.
2. Assemble auxiliary data: electoral rolls, company registers, social media, news reports, property records, earlier releases from the same organisation, and data the recipient already holds.
3. Attempt linkage: on a copy in a controlled environment, try to match unique or rare records to named people, and try to infer sensitive attributes for known individuals.
4. Use the right testers: the ICO says testing can be in-house, by a third party or both, and that complex data may need specialist or ethical hacking skills. Testers should not be the people who prepared the data.
5. Record the evidence: what was tried, what succeeded, and the confidence of any match. Distinguish a confident match from a guess.
6. Remediate and retest: generalise or suppress further, or change the release model, then repeat until no reasonable match succeeds.

Implementation and governance

1. Purpose and lawful basis: document why the data is being released and the lawful basis for the anonymisation itself. Run a DPIA for large-scale or sensitive releases.
2. Data inventory: classify every field as direct identifier, quasi-identifier, sensitive attribute or other, including free text and metadata.
3. Choose the release model before choosing techniques, because it decides the risk threshold.
4. Apply and measure: transform the data, measure k, uniqueness and diversity on the quasi-identifiers, and compare with the threshold you set.
5. Intruder test and approval: run the test, then have an approver independent of the requester sign off the release with the evidence attached.
6. Protect the keys and source: keep linkage keys and the original data separate from the release, with access limited to named roles.
7. Review: reassess on the triggers the ICO lists (new attacks, new datasets, new recipients, changed purpose) and on a schedule; withdraw or replace a release if risk has risen. Rolling back an open release is rarely possible, which is why the bar for open publication is highest.

Where identity fits

Identifiability is controlled as much by access as by transformation. In an enclave or a pseudonymised internal dataset, the controls that keep risk remote are identity controls: who can query, who can export, who holds the linkage key, and which service accounts run the pipelines. A data pipeline service account that can read both the pseudonymised table and the key table removes the separation the assessment relied on. Review these accounts as part of each release review, and see the Data Classification Guide for labelling source and released datasets.

Detection and measurement

• Release register: every external release with its model, assessment, approver, recipients and review date.
• Enclave and query logs: exports, output requests, unusual query patterns such as many narrow queries that could difference out individuals.
• Key access logs: every access to linkage keys and source data, alerted when outside approved roles.

Framework mapping

Common failure patterns

• Names removed, dates kept: full dates of birth, admission or transaction dates and postcodes left intact, so most records stay unique.
• Unkeyed hashes as "anonymous IDs": hashed emails or phone numbers that anyone can reverse by hashing a candidate list.
• Ignoring the recipient's own data: releasing to a partner that already holds a customer list on the same people, which turns the release back into personal data in their hands.
• One-off assessment: a dataset approved years ago stays published while new public sources make linkage easy.
• Free text left in: comment fields and notes carrying names, job titles and places.
• Repeated releases: several individually safe extracts of the same population that can be differenced or joined to reveal individuals.

Practitioner checklist

• Record the purpose, lawful basis and release model before any transformation work starts.
• Classify every field, including free text and metadata, as direct identifier, quasi-identifier or sensitive attribute.
• Set a measurable threshold (for example a minimum class size) appropriate to the release model.
• Generalise and suppress quasi-identifiers, and measure k, uniqueness and diversity on the result.
• Run a motivated intruder test with testers independent of the data preparers.
• Use keyed functions for any linkage codes and hold keys with a separate party or role.
• Prefer enclaves, query interfaces or aggregates when detailed records about rare groups are needed.
• Bind licensed recipients to no-re-identification, no-linkage and deletion terms.
• Keep a release register and reassess on new datasets, recipients, purposes and techniques.

Standards and references

• ICO: Anonymisation guidance
• EUR-Lex: Regulation (EU) 2016/679 (GDPR), Recital 26 and Article 4(5)
• Article 29 Working Party: Opinion 05/2014 on Anonymisation Techniques
• NIST: SP 800-188 De-Identifying Government Datasets
• HHS: Guidance on De-identification of Protected Health Information
• legislation.gov.uk: Data Protection Act 2018, section 171

Related NHI Mgmt Group resources: Privacy-Enhancing Technologies Guide · Pseudonymisation Techniques Guide · Differential Privacy Guide · GDPR Compliance Guide for Security Teams