Re-Identification Attack

How Re-Identification Happens

Re-identification attacks usually exploit the fact that “anonymous” records often still contain patterns that are unique enough to narrow a person down when combined with outside data. Location trails, timestamps, rare attributes and repeated behaviours are especially useful because they shrink the candidate set quickly.

The attack is rarely a single magical match. More often, it is a linkage process that starts with quasi-identifiers and ends with a confident association to a named individual, household, device or account. That is why anonymisation has to be judged as a release property, not just a field-removal exercise.

Why De-Identified Data Still Becomes Personal Data Again

Re-identification risk exists because anonymity is contextual. A dataset that seems safe in isolation can become identifying once it is cross-referenced with other public, commercial or internal sources. This is one reason organisations should treat claims of “de-identified” or “pseudonymised” data cautiously, and, where relevant, use the guidance in Anonymisation and Re-identification Risk Guide and Pseudonymisation Techniques Guide.

For privacy engineering, the key issue is not whether direct identifiers were removed, but whether the remaining data can still support singling out, linkability or inference. Once that is possible, the practical privacy outcome changes even if the dataset still looks “anonymous” at first glance.

Where the Attack Surface Comes From

Re-identification becomes more likely when datasets contain stable patterns, repeated events or rare combinations that can be matched against external sources. High-resolution location data, transaction timing, small populations, unusual attributes and rich event histories all increase the attack surface.

Data releases also become riskier when multiple tables, exports or logs can be joined together later. A record that cannot identify a person on its own may still become identifying once combined with another release, a broker dataset or a published observation about the same person.

Controls That Reduce Re-Identification Risk

Controls work best when they are chosen before release, not after a dataset has already spread. That usually means assessing whether the data should be anonymised, pseudonymised, aggregated, masked or withheld, then testing whether the residual data still resists linkage under realistic external knowledge.

Practical safeguards include limiting quasi-identifiers, suppressing rare values, reducing precision, separating lookup material from released data, and testing releases against a motivated intruder model. Where stronger privacy protection is needed, organisations may also use techniques described in Privacy-Enhancing Technologies Guide or Synthetic Data Risk Guide.

Risk and Threat Considerations

Re-identification is dangerous because it can turn an apparently low-risk dataset into personal data again, exposing individuals to privacy loss, profiling, discrimination or unwanted disclosure. The same linkage methods can also undermine promises made to customers, patients or employees about how their data was protected.

Failure mechanism: The attacker combines quasi-identifiers, auxiliary data and repeatable patterns to narrow the field until a record can be matched with high confidence to a real person.

Impact: Data that was thought to be anonymous can become identifiable again, which can trigger privacy breaches, regulatory exposure and loss of trust in the release process.

Practitioner Guidance

What to watch for: Any release that depends on removing names alone is usually too weak. If a dataset includes fine-grained location, rare events, small cohorts or persistent identifiers, it deserves a formal re-identification review before publication or sharing.

Governance implication: Owners should define who can approve data release, what re-identification tests are required, and when a dataset must be treated as personal data despite having no direct identifiers. That decision should be documented so future reuse does not quietly expand the risk.

Related resources from NHI Mgmt Group

• Why do quasi-identifiers create more re-identification risk than direct identifiers alone?
• What breaks when detection rules are changed without re-testing them against attack scenarios?
• How should organisations manage personal data when pseudonymization does not eliminate re-identification risk?
• What happens when re-identification risk is not monitored across processing flows?