Masking, redaction and pseudonymisation solve different problems

The first question when transforming personal data is whether anyone should be able to recover the original. The next is whether separate records should remain linkable. These decisions are more useful than choosing whichever operation a library calls “anonymisation”.

A masked display, a redacted document and a tokenised dataset can all reduce exposure. They provide different properties. Selecting one requires a purpose, an intended audience and a view of what additional information that audience could obtain.

Masking changes what an audience sees

Masking commonly hides part or all of a value in a particular representation. A customer service screen might show only the final characters of a reference so an operator can distinguish accounts.

This can reduce unnecessary viewing. It does not necessarily change the underlying stored value, remove it from an API response or prevent another role from seeing it. A masked screen with an unprotected export is a display control with a different export path.

UIDAI’s masked Aadhaar description is a concrete example: the first eight digits are obscured and the last four are shown. That description should not be expanded into a claim that a document containing other personal details is anonymous.

Redaction removes selected content from an output

Redaction is appropriate when an audience should not receive particular material. The important acceptance test is whether the delivered output actually excludes the content through the paths available to that audience.

For a document, drawing a dark rectangle over text may be insufficient if the original text remains accessible underneath. For structured data, dropping a visible column may leave the same value in a nested object. The implementation needs to match the output format.

Redaction can also remove too much. A support transcript without names may still be useful; one with every location, date and product reference removed may no longer explain the problem. Define which information the recipient needs before transforming it.

Pseudonymisation preserves a controlled relationship

Pseudonymisation replaces an identity-bearing value with another representation while allowing some form of linking or restoration under controlled conditions. The exact properties depend on the design.

A hypothetical analytics team might replace a customer identifier with a stable token so it can count repeat visits. The token supports linkage across records. A separate mapping could permit authorised restoration when the workflow requires it.

That capability is also a risk boundary. Someone who gains the mapping, a suitable key or enough auxiliary information may reconnect records to people. NIST’s de-identification guidance explains why pseudonyms, quasi-identifiers and the sharing environment must be considered in disclosure-risk assessment.

A hash should not be assumed anonymous because it looks random. Predictable inputs may be tested against candidate values, and stable outputs can support linkage. The protection depends on the construction, access and threat model.

Tool names do not settle the privacy outcome

Presidio’s anonymiser component supports operations including replacement, redaction, masking, hashing and encryption. Those operations have different recovery and linkage properties. The component’s name does not prove that every output is anonymous.

NIST treats de-identification as a process involving data, risk and the release context. Removing direct identifiers can still leave combinations of attributes that identify someone. A rare role, precise location and unusual event may be revealing even when the name field has disappeared.

For that reason, reserve an anonymity claim for a substantiated assessment of the actual output and context. A narrower statement such as “names replaced in this support export” is often both more accurate and easier to verify.

Work backwards from the recipient’s job

Consider three proposed outputs from the same hypothetical retailer:

• An operator screen needs a short account suffix for conversation handling.
• A training example needs the complaint’s sequence without the customer’s identity.
• A restricted reconciliation process needs to connect transactions across systems.

The screen may use masking, the training example may use redaction and generalisation, and reconciliation may use controlled pseudonyms. None of these choices automatically solves the requirements of the other two.

Before implementation, document whether restoration is permitted, whether linkage is necessary, which copies retain originals and who can access the transformation mechanism. Then test the delivered output from the recipient’s perspective.

A useful review asks whether the necessary task still works, whether unnecessary identifying detail remains and whether recovery capabilities are confined to the intended roles. Choose the operation that meets those conditions, and describe the result in terms of the protection actually demonstrated.