---
title: "Redaction vs Anonymization vs Pseudonymization"
description: "Four words that get used interchangeably and mean four different things, with four different legal consequences. Here is what each one actually does to your data, which regulation defines it, and which one your tool is really performing."
canonical_url: https://omitsys.com/blog/redaction-vs-anonymization-vs-pseudonymization/
author: "Ranjan Singh"
date: 2026-08-23
published: false
---

## In short

Redaction removes information from a document so a version can be released without it. Anonymization breaks the link to the person permanently, which puts the data outside the GDPR entirely under Recital 26. Pseudonymization replaces an identifier with a token and keeps the mapping separately under GDPR Article 4(5), and pseudonymized data is still personal data with every obligation attached. De-identification is the HIPAA term, met either by removing all eighteen Safe Harbor identifiers or through Expert Determination, both at 45 CFR 164.514(b).

Four words turn up in the same sentence constantly, usually as if they were synonyms: redaction, anonymization, pseudonymization, de-identification. They are not synonyms. Each describes a different operation on the data, two of them are defined terms in law, and picking the wrong one is how a team ends up believing a dataset is out of scope when a regulator would say it never left scope at all.

## Redaction removes, if it really removes

Redaction is the oldest and the narrowest. It means removing information from a document so that a version can be released without it. A redacted document is still the document: same pages, same paragraphs, same argument, with specific values taken out. Nothing is put back in their place except, at most, a marker showing something was there.

That last part is where redaction goes wrong in practice, and it is worth being blunt about it, because "redacted" in most people's hands means "covered". [A black rectangle drawn over a line of a PDF](/blog/how-to-unredact-a-pdf/) is not a redaction. The characters are still in the file's content stream, sitting under a shape, and a copy and paste into a text editor brings them straight back. This is the failure behind nearly every recovered-redaction news story, and it is a property of how the file format works rather than carelessness by the person who did it. The test for whether a redaction is real is not whether you can see the value. It is whether the value is still in the bytes.

## Anonymization is a one-way door

Anonymization is the strongest claim of the four, and the one made most casually. It means the link between the data and the person has been broken permanently, by anyone, including the party who broke it. There is no key, no lookup table, no reversal. Under the GDPR that has a specific consequence: Recital 26 puts anonymous information outside the scope of the regulation entirely. Data that is genuinely anonymous is no longer personal data, and the rules stop applying to it.

Which is exactly why the bar is high, and why most datasets that get called anonymized are not. The test is not whether you removed the names. It is whether the person can be singled out again by any means reasonably likely to be used, including by combining your dataset with another one. Age, postcode and date of an appointment carry no names at all and still identify a large share of a population. If a re-identification attack would work, the data is pseudonymous at best, and the regulation still applies.

## Pseudonymization keeps the key

Pseudonymization is the middle position, and unlike the other three it has a definition you can cite. GDPR Article 4(5) describes processing personal data so that it can no longer be attributed to a specific person without the use of additional information, where that additional information is kept separately and protected. The definition is really about the key: replace the identifier with a token, keep the mapping somewhere else, and control who can reach it.

The consequence people miss is that pseudonymized data is still personal data. It stays in scope, the obligations still attach, and a data subject request still has to be answered. Recital 26 says so directly. Pseudonymization is a security measure that reduces risk and is credited as such under Article 32, not an exit from the regulation. Treating a token as if it were anonymity is the single most common category error in this whole area.

## De-identification, and PII against PHI

De-identification is largely the American word for the same territory, and in one context it comes with a test rather than a standard. HIPAA gives two routes at 45 CFR 164.514(b). [Safe Harbor lists eighteen identifiers](/blog/18-hipaa-identifiers/), from names and geographic subdivisions smaller than a state down to device serial numbers, and requires all eighteen to be removed, plus no actual knowledge that what remains could still identify someone. Expert Determination instead has a qualified person certify that the re-identification risk is very small, and document how they reached that. Meet either and the data stops being protected health information.

That also settles a related pair of terms. [PII](/blog/what-is-pii/) is the general category of information that identifies a person. PHI is the narrower HIPAA category: identifying information tied to health, care or payment for care, held by a covered entity or its business associate. Every piece of PHI is PII. Most PII is not PHI, and the eighteen-identifier list applies only to the second.

## Which one your tool actually performs

So which one does a tool actually perform. This is the question worth asking any vendor, and the honest answer is usually per field rather than per product, because a real document needs different treatments in different places. In Omit the choice is explicit: every entity type maps to one of nine operators. LABEL replaces the value with its type. BLACKBOX covers it in block glyphs. MASK keeps a fixed number of characters and hides the rest, which is what a rule asking for the last four digits requires. HASH produces a stable one-way digest, so the same value matches itself across documents without being readable. KEEP deliberately leaves a value alone. YEAR_ONLY reduces a date of birth to its year and INITIALS reduces a name to initials, both shapes that exist because a court rule asks for them. NUMBER produces numbered placeholders within a single run.

The ninth is PSEUDONYMIZE, and it is the one that maps to the legal term. It swaps the real value for a format-preserving fake one, so a name still reads as a name and a document stays coherent for whoever has to work with it. Where the vault is switched on, the mapping is written to an encrypted local store, which is the "additional information kept separately" that Article 4(5) is describing, and re-identification is a deliberate, authorized action against that store rather than a side effect of holding the file. Where the vault is off, nothing is written down and the substitution is not reversible by anyone, including us.

## How to choose

The practical way to choose is to work backwards from what the output has to survive. If a document must be published and never reversed, use removal and make sure it is real removal rather than a covering shape. If a dataset has to stay analytically useful and you are willing to keep the obligations that come with personal data, pseudonymize and protect the key properly. If a rule names a specific residual, like a year of birth or four trailing digits, use the operator that produces exactly that and no more, because over-removal is its own failure. And if you plan to claim a dataset is anonymous and therefore out of scope, treat that as a claim you have to be able to defend against a re-identification attempt, not a label you get to apply because the name column is gone.