Redaction vs. pseudonymization: which keeps your spreadsheet useful?

What redaction, masking, removal, and aliasing each preserve, and how to choose

You have a spreadsheet you want to run through an AI tool (interview notes, a research repository, a usage log) and it contains names, emails, and other values that should not travel with it. Four techniques can take those values out, and they are often discussed as if they were interchangeable, though each one preserves something different. The right choice depends on what the copy still has to answer after the values are gone.

Four techniques, one decision

Working definitions, since the terms blur easily:

• Redaction replaces a value with a fixed token — [REDACTED], a black bar, an X. Every redacted value looks identical afterwards.
• Masking hides part of a value while keeping its shape: some characters stay visible, the rest are starred out.
• Removal deletes the value outright, leaving an empty cell.
• Pseudonymization replaces each value with an alias such as PERSON_001, applied consistently, with a mapping back to the original held somewhere.

One boundary matters more than the rest: pseudonymization is not anonymization. Under the GDPR, an aliased table is treated as personal data for whoever holds the mapping, because the mapping — and often the rest of the row — can lead back to the person. That is not an interpretation: Article 4(5) defines pseudonymisation as processing after which data "can no longer be attributed to a specific data subject without the use of additional information," and the Court of Justice held in EDPS v SRB (C-413/23 P, 4 September 2025) that for the party keeping that additional information the data remains personal (para. 76). Anonymization, which severs the link irreversibly, is a much higher bar, and none of these four techniques reaches it on its own. Pseudonymized data after EDPS v SRB: what changed in Europe works through what the judgment settled and what it left open.

The differences between the four show up as soon as you put them next to a real table.

What each technique does to a table

Here is a fragment of a UX research log, covering two study rounds, with one participant returning between them. All names are invented.

A researcher reading this sees the finding at a glance: the participant who failed task 3 in round 1 succeeded after the redesign. That before/after pair is the kind of evidence a usability study exists to produce.

Redact the file and the pair dissolves:

Rows one and three might be the same person improving, or two different people with different skills. The table can no longer say which. Aliasing keeps the names out and the connection in:

The property doing the work is consistency: the same original value maps to the same alias, across the whole file. [REDACTED] is a constant that collapses every identity into one; PERSON_001 is a variable that keeps identities distinct while detaching them from real people. In this demo the mapping behind that is three entries long; in a 20,000-row export the same rule does the same job on every row.

Redaction breaks the analyses that depend on rows sharing an entity. Repeat-entity counting ("how many participants returned for round 2?"), cohort comparison ("did returning participants rate the redesign differently than new ones?"), and journey reconstruction ("what did this participant's path look like across sessions?") all stop working, because each needs to know that two rows belong to the same person. Analyses that treat rows independently — counting how many notes mention the export button, summarizing themes across sessions — survive redaction intact.

Where redaction is the right choice

Aliasing is not the default for every file. Redaction fits better when linkage has no value, or would itself be a liability.

• One-way disclosure. A quote pulled into a slide deck, or a report excerpt shared outside the team, will never be joined back to other rows. There is nothing for consistency to preserve.
• No cross-row analysis. If the work is reading individual notes rather than comparing them (a single session summary, a one-off review), the repeat pattern is unused weight.
• Audit-facing copies. A reviewer checking that nothing personal remains is served better by an unambiguous [REDACTED] than by aliases they must verify were applied correctly.
• Values that must not survive in any form. Some values should not persist even as a pattern of repetition. For those, redaction or outright removal is the point, and preserving linkage would defeat it.

Where masking and removal fit

Masking earns its place when part of a value carries the signal. A phone number masked to +1 *** *** 0198 still shows the country code and enough trailing digits to spot duplicates without staying dialable; an IP address masked to 192.168.*.* still shows an internal-network origin. When the analysis needs the shape of a value rather than its linkability, masking is lighter than an alias and easier to read in context.

Removal is the smallest surface. When a column carries no analytical weight (a street address in a study about onboarding, say), an empty cell leaves nothing to reason about and nothing to leak.

Credentials are the clearest removal case. If an API key or access token is sitting in a notes column, aliasing it would preserve a relationship nobody needs; no analysis depends on knowing that two rows exposed the same secret. Data Alias treats detected credentials as remove-by-default and asks for an explicit confirmation before keeping one in the export.

What aliases keep — and what they leave behind

An aliased copy keeps more analytical structure than the other three techniques produce, and that is exactly why it deserves the closest read before it leaves your hands.

PERSON_001 is not an anonymity certificate. The alias removes the direct identifier, and everything else in the row still describes a person: an age next to a postcode, an unusual role, a sequence of events only one participant lived through. Whether the copy identifies someone depends on those remaining columns and on who reads them, not on the alias format. In the research log above, "the participant who abandoned task 3 in round 1" may be perfectly recognizable to anyone who sat in on the sessions.

Every technique in this comparison depends on the sensitive values being found first, and automatic detection misses some of them, especially in free text. What automatic PII detection misses in spreadsheets describes where.

Choosing a technique

Start from the analysis and work backwards. Each row below is a need the copy might have to serve; the technique follows from it, and each choice carries something you accept in return. Detected credentials sit outside this table: they stay remove-by-default, as covered in the masking and removal section.

For the wider toolbox — deletion, formulas, one-time scrubbers, and local pseudonymization compared on cost, upkeep, and detection — see Four ways to remove or pseudonymize PII in a spreadsheet.

The question that settles most cases sits in the first column: what must the data still answer once the identifiers are out? Ask it per column — does this one need to be linkable, partially visible, merely present, or absent — and the choice of technique follows.