Can anonymized test data still identify real people?

Yes. Removing names and emails does not make a dataset anonymous, because combinations of ordinary fields, such as birth date, postcode and job title, can single out one person. Check how unique records are on those combinations before you treat a masked dataset as safe, or generate synthetic data instead.

Definitions

• Direct identifier: a field that names a person on its own, such as a full name, an email address or a national identifier.
• Quasi identifier: a field that does not identify anyone alone but can when combined with others, such as postcode, birth date, gender, employer or device type.
• Re-identification: linking a supposedly anonymous record back to a person, often by joining it with another dataset.
• k anonymity: a property where each combination of quasi identifiers appears in at least k records, so nobody is unique.

NIST's publication SP 800-188 on de-identifying government datasets covers these ideas. It defines de-identification as any process of removing the association between a set of identifying data and the data subject, and its subject tags include direct identifiers, quasi identifiers, k anonymity, pseudonymization, re-identification, differential privacy and synthetic data.

Why this matters for test environments

Teams often mask the obvious columns and call the result anonymised. Then the dataset is shared with a contractor, stored on laptops and kept for years. If records are unique on a few columns, anyone with outside knowledge, such as a colleague, a public profile or another breach, can pick out a person.

The UK ICO states that pseudonymised data is in scope of data protection law and that pseudonymisation is not a way of transforming personal data so that the law no longer applies. Masked data with weak protection falls in that zone. This is general information, not legal advice.

A quick uniqueness check

1. Choose likely quasi identifiers. Birth date, postcode, gender, job title, employer, account creation date, plan and city are common ones.
2. Group and count. Group rows by combinations of two, then three, of those columns, and count rows per group.
3. Look at the small groups. Groups of size one are unique people. Count how many records sit in groups below your threshold, such as five.
4. Reduce precision. Replace birth date with birth year, postcode with its first part, exact timestamps with dates, and ages with bands.
5. Suppress outliers. Remove or generalise records in tiny groups, such as the only 94 year old in a region.
6. Repeat the count until few records fall under the threshold, or choose synthetic data.

Here is a sketch of the counting query:

SELECT birth_year, postcode_area, job_title, COUNT(*) AS n
FROM masked_users
GROUP BY birth_year, postcode_area, job_title
HAVING COUNT(*) < 5
ORDER BY n;

Also consider

• Free text fields often contain names and details that column rules miss.
• Timestamps and sequences can reveal when someone joined or acted, which links to external events.
• Rare values such as unusual job titles or small employers act as identifiers.
• Linkage over time. Releasing two masked extracts with the same pseudonyms lets someone track a person across both.

When to choose synthetic data

If tests do not need real distributions, generated data avoids the whole question. If they do, generate from measured aggregates rather than from record level data.

Quick check

Sources

• NIST SP 800-188, De-Identifying Government Datasets: Techniques and Governance
• ICO guidance on pseudonymisation

Last reviewed: 19 October 2026.