Anonymisation and pseudonymisation

What are anonymisation and pseudonymisation?

Anonymisation and pseudonymisation both reduce the chance that data can be linked back to a real person. The difference is the route back.

With pseudonymisation, you replace direct identifiers such as names, email addresses, customer numbers, or national numbers with codes. Somewhere, or through some method, the link can still be restored. With anonymisation, the data is changed so thoroughly that a person is not, or is no longer, identifiable by reasonably likely means.

A simple way to picture it: pseudonymisation puts the key in a separate safe. Anonymisation removes the key and makes sure the lock cannot realistically be forced through other clues.

Under GDPR this distinction matters a lot. Article 4(5) defines pseudonymisation as processing personal data so it can no longer be attributed to a specific person without additional information, provided that the additional information is kept separately and protected. Recital 26 says pseudonymised data that can still be attributed to a person should be treated as personal data. Truly anonymous information falls outside GDPR, but the act of anonymising personal data is still processing and needs a purpose and legal basis.

Anonymisation versus pseudonymisation

Legal status
Pseudonymised data remains personal data when a route back exists. GDPR still applies: purpose limitation, access control, retention, rights, security, and accountability. Anonymised data can fall outside GDPR, but only when re-identification is not reasonably likely.

Usefulness
Pseudonymised data keeps more analytical value. You can follow one customer over time, link records across tables, and handle requests such as deletion or correction. Anonymised data usually loses detail because you remove, group, blur, or aggregate values until the person can no longer be singled out.

Risk
Pseudonymisation lowers risk but does not remove it. If the key leaks, access rights are too broad, or the coded records can be linked with another dataset, people may still be identified. Anonymisation aims to remove that realistic route back, but it has to be tested against the context, not just against the columns you removed.

Typical use
Pseudonymisation is common for test data, analytics, research, and internal data sharing where record-level detail is still needed. Anonymisation is the better target for public statistics, external publication, and sharing data where the recipient does not need individual-level records.

When is data truly anonymous?

Data is not anonymous just because names are gone. Recital 26 asks whether someone is identifiable by means reasonably likely to be used, considering factors such as cost, time, available technology, and the wider context.

The older Article 29 Working Party anonymisation opinion gives three useful tests:

• Singling out
  Can one person still be isolated from the dataset, even without knowing their name?

• Linkability
  Can records about the same person be linked across rows, tables, releases, or outside datasets?

• Inference
  Can someone infer sensitive or identifying information about a person from the remaining data?

Small groups are a classic problem. A report that shows revenue by region and product category may be anonymous when each cell covers many customers. The same report may become personal data again if one cell contains a single customer or a rare combination of postcode, age, and purchase pattern.

Hashing is another common trap. A hashed email address or national number may look random, but if the possible input values are known or easy to guess, an attacker can hash candidate values and compare them. Hashing can be a useful pseudonymisation technique, but it should not be treated as automatic anonymisation.

Techniques in a data stack

Most real projects combine several techniques.

• Deletion
  Remove columns you do not need. This is often the strongest privacy move and the easiest to explain.

• Masking
  Replace values with dummy values, partial values, or placeholders. Useful for test systems where the format matters more than the real content.

• Coding
  Replace identifiers with generated codes and keep the mapping separately. This is usually pseudonymisation because the mapping can restore the link.

• Generalisation
  Make values coarser: age band instead of date of birth, province instead of full address, month instead of exact timestamp.

• Aggregation
  Publish totals, averages, or counts per group instead of individual rows. Check small cells and rare combinations carefully.

• Noise or perturbation
  Add controlled distortion so individual values are less revealing while the overall pattern stays useful. This needs careful testing, because too little noise does not protect enough and too much destroys the data's value.

No technique is magic. The result depends on the full dataset, the recipient, the available outside data, and who can access any keys or mappings.

Examples in test data, reporting and data sharing

Test data
A team copies production orders into a test database. Names and emails are replaced by customer codes. The lookup table is stored in a separate, tightly controlled environment. Developers can test repeat purchases and joins, but the dataset is still personal data because the key exists.

Reporting
A management dashboard shows monthly revenue by region and product category. If the report contains no individual rows and no tiny groups, it may be anonymous. If a filter lets someone drill down to one rare customer, one household, or one employee, the privacy assessment changes.

Data sharing
A company sends a supplier a dataset for analysis. If the supplier only needs trends, aggregation or real anonymisation is safer. If the supplier must reconcile individual cases, pseudonymisation may be more useful, but the data sharing agreement, access controls, retention period, and data lineage need to be clear.

Research or model development
Pseudonymised data can preserve enough detail for longitudinal analysis or model training. That is useful, but it also means GDPR obligations remain. Synthetic data can help in some cases, but it still needs a re-identification assessment before you treat it as anonymous.

What to watch out for with anonymisation and pseudonymisation

Pseudonymised is not anonymous
If additional information can re-identify someone, the data remains personal data. Treat the mapping, key, salt, or lookup table as highly sensitive.

The anonymisation step is still processing
You start from personal data. That means the act of anonymising it falls under GDPR, even if the final result no longer does.

Context can change
A dataset that looked anonymous years ago may become linkable when new public data appears or compute gets cheaper. Revisit high-value datasets instead of treating anonymisation as a one-time stamp.

Keys must be genuinely separate
A lookup table in the same database with the same access rights is not meaningful separation. Use separate storage, access rules, logging, and ownership.

Document the judgement
Record which fields were removed or changed, which outside data you considered, which re-identification tests you ran, and why the remaining risk is acceptable. This matters for internal trust and for any later discussion with a customer, auditor, or regulator.