Anonymisation vs Pseudonymisation vs Redaction

Anonymisation, pseudonymisation and redaction are not three names for the same thing — they sit on a spectrum of re-identification risk, and only one of them (done properly) takes data outside the scope of privacy law entirely. If you're deciding how to handle a dataset for analytics, sharing or retention, the right question is not "should we de-identify this" but "which of these three techniques matches the risk and the use case," because picking the wrong one either destroys the data's usefulness or leaves it exposed.

Why the distinction changes your obligations

This distinction shows up constantly in AI and analytics projects, where teams want to reuse "de-identified" data for model training or reporting and assume that removing a name column is enough. It usually isn't. Each technique carries a different regulatory consequence:

• Genuinely anonymised data is no longer personal data. Retention limits, rights requests and breach-notification duties generally fall away, because there is no individual left to protect.
• Pseudonymised data is still personal data. The identifiers are hidden, not gone, and a separate key or mapping table can restore them. Every obligation that applies to identifiable data still applies here.
• Redacted data typically means specific fields or text have been removed or masked in a document or record, often for a specific disclosure (like a subject access response or a public records release). It's a technique, not a standalone risk category — the redacted document might still be personal data if other identifying information remains.

Confusing these categories is one of the most common and consequential mistakes in data handling, especially when a team wants to claim a dataset is "anonymous" to justify sharing it more freely than it should be.

A framework for choosing the right technique

1. Define the use case first. Are you sharing data externally, training a model, responding to a subject access request, or archiving for legal hold? Each points toward a different technique.
2. Assess re-identification risk against the specific release, not in the abstract. A dataset that looks anonymous in isolation can become re-identifiable when combined with other available datasets — postcode plus birth date plus gender is a classic quasi-identifier combination that can uniquely identify people even without a name.
3. Match the technique to the risk tolerance of the use case.

• If the data must remain fully useful for internal operations but the direct identifiers need protecting in transit or storage, pseudonymise, and protect the re-identification key separately (different access controls, different system).
• If the data is being released externally or retained indefinitely with no legitimate need to re-identify anyone, aim for anonymisation, and test it — don't just assume removing obvious fields is sufficient.
• If you're producing a specific document for a specific disclosure (a court filing, a subject access response, an internal investigation report), redact the fields that are out of scope for that particular disclosure.

1. Document your assessment. Write down what technique you used, why, and what residual risk you accepted. This record matters if anyone later challenges whether a dataset was really anonymous.
2. Re-test periodically. Techniques and external data availability change. Data that was safely anonymous five years ago may be re-identifiable today because of a newly public dataset it can be cross-referenced against.
3. Build this into your intake process, not as an afterthought. If you're formalising a broader inventory of what data you hold and how it flows, the data inventory & RoPA starter kit is a useful place to record de-identification decisions alongside the underlying processing activity.

A worked example

A hospital group wants to share ten years of patient visit records with a university research team studying treatment outcomes. The initial dataset includes patient name, date of birth, postcode, admission dates, diagnosis codes and treating physician.

• The team first considers simple redaction — deleting the name column — and calls the result "anonymous." It isn't: postcode, date of birth and admission date together can often re-identify a specific patient, especially in a rural area with a small population.
• Recognising this, the privacy lead reframes the approach. For the research use case, they generalise postcode to a broader region, convert exact dates of birth to age bands, and generalise admission dates to month/year. They also run a re-identification risk test against a sample using data available to a motivated attacker (public obituaries, local news) before releasing it. This gets the dataset to a genuinely low risk of re-identification appropriate for external sharing.
• Separately, the hospital's internal analytics team needs patient-level detail preserved for longitudinal tracking, but wants identifiers out of day-to-day dashboards. For that use case, the hospital pseudonymises: names and IDs are replaced with a token, and the mapping table is stored in a restricted system with its own access controls and audit logging. The hospital treats the pseudonymised dataset as personal data throughout — it stays inside retention schedules and remains in scope for subject access requests.
• When a single patient submits an access request, the response document is redacted to remove any other patients' names that appear in shared clinical notes, since the requester is only entitled to their own data.

Three techniques, three purposes, in the same organisation, applied deliberately rather than interchangeably.

Common failure modes

• Calling pseudonymised data "anonymous" in a privacy notice or vendor contract — this misstates your actual obligations and can mislead individuals about their rights.
• Assuming removing names is sufficient anonymisation without testing against quasi-identifiers (postcode, birth date, rare diagnosis, device ID, transaction timestamp).
• Treating anonymisation as a one-time action rather than an assessment tied to a specific release and a specific point in time — re-identification risk can increase as more external data becomes available.
• Redacting a document for one purpose (e.g., a subject access response) and then reusing the same redacted version for a different, broader release without reassessing what's still identifiable.
• Storing the pseudonymisation key in the same system, with the same access rights, as the pseudonymised data itself — this defeats much of the security benefit.
• Skipping documentation of the risk assessment, leaving no record of why a dataset was judged safe to share.

Do this next

• Audit any dataset in your organisation currently labelled "anonymised" and confirm whether it was actually tested against quasi-identifier re-identification risk, or just had names removed.
• Separate your pseudonymisation keys from the data they unlock, with distinct access controls.
• Build a lightweight decision record template — use case, technique chosen, residual risk, reviewer — and require it before any dataset is released externally.
• Review your current AI or analytics projects for “anonymous” training data claims that haven't actually been tested; the AI privacy risk checklist is a useful starting point for that review.
• If you're building or refreshing these skills across a team, our AI Privacy and Data Readiness course covers de-identification techniques and testing methods in more depth.
• Not sure where your program stands on data minimisation and de-identification practice generally? Run the free assessment to identify priority gaps.

The right technique depends heavily on your specific data, release context and applicable law — treat this as a starting framework, and get a technical and legal review before relying on any de-identification approach for a high-stakes release.