What Counts as a Redaction? A Plain-English Guide to Redacting Emails for SARs and FOI Requests

If you handle subject access requests or FOI requests, you will spend a lot of your week turning raw email archives into something you can safely send out. Redaction is the step that makes that possible. But "redaction" gets used loosely, and a loose definition is exactly what gets organisations into trouble. This guide breaks down what a defensible redaction email actually is - what to remove, what to keep, and how to prove you made the right call.

What a redaction actually is

A redaction is the permanent removal of specific information from a document before it is disclosed. That is the whole job, and every word in that sentence matters.

Permanent means permanent. Blacking out a name with a highlighter, drawing a shape over text in a PDF, or cropping a screenshot does not redact anything - the underlying characters are still sitting there for anyone who copies the text or strips the overlay. A proper redaction removes the data itself, so the person receiving the file cannot recover it.

Specific means you remove the least you can. Redaction is a scalpel, not a shredder. Under both the UK GDPR and the Freedom of Information Act 2000, you disclose as much as you can and withhold only what you must. An email that arrives 90% readable and 10% masked is a good outcome. An email that arrives as a solid black page is not.

Redaction is not an exemption

This is the confusion that causes most of the avoidable complaints.

An exemption or exception is a legal decision: you have decided that a particular piece of information - say, the identity of a whistleblower, or a third party's medical detail - should not be released. A redaction is the mechanical act of carrying that decision out.

You make the legal call first, on a case-by-case basis, then use redaction to remove the information that call covers. Too often teams jump straight to masking and let the technology decide what qualifies, which is how redactions end up either too wide (you withhold too much and look obstructive) or too narrow (a personal detail slips through).

What to remove

In practice, emails and PDF bundles for SAR and FOI responses usually contain the same handful of things that need to come out:

• Other people's personal data. The requester is entitled to their own information, not the personal data of colleagues, students, parents or complainants who appear in the same thread.
• Names, and anything that identifies them. A name is the obvious one, but job titles, email addresses, phone numbers, staff numbers and even distinctive combinations of details can identify someone just as clearly.
• Special category data. Health details, ethnicity, religious beliefs, sexual orientation, trade union membership and similar data carry a higher bar and need particular care.
• Information covered by a specific exemption. Legal privilege, commercial confidentiality, ongoing investigations and law-enforcement material all have their own tests.

The trap with email specifically is that the same person appears in dozens of messages. If you redact a name in one email but miss it in the forwarded copy eight messages later, the redaction has failed in substance even though it succeeded on the page you were looking at.

What to keep

Beginners often over-redact, and that creates its own risk. A response that is mostly black blocks looks evasive, invites an internal review or an ICO complaint, and often forces you to redo the whole thing.

Keep everything that does not fall into one of the categories above - including the familiar everyday content that makes the email chain readable. Names of the requester themselves stay in. So does the substance of the discussion, dates, and the reasons given for decisions, unless a specific exemption covers them.

The test is simple: if releasing this piece of information would not breach anyone's rights or a specific exemption, it stays in.

Every decision needs to be logged

Here is the part that separates a defensible redaction from a hopeful one. A redaction is only as good as your ability to explain it later.

For each removal, you should be able to say what was removed, and why, and who decided. If a requester challenges your response - and they can, through an internal review or a complaint to the Information Commissioner's Office - "we redacted some names" is not an answer. You need a record.

In practice that means an audit trail that runs alongside the disclosure: which documents were processed, which redactions were applied, and the reason behind each one. Build that record as you work, not afterwards from memory. Reconstructing it weeks later is where defensibility falls apart.

Where manual redaction breaks down

Most teams start by opening each email and masking by hand. It works for one short thread. It stops working the moment a request lands with 200 emails and a handful of attached PDFs.

The problems are predictable:

• The same name gets missed in repeated copies. Same person, same document, different page - and one of them gets overlooked.
• Nothing is logged. Manual masking leaves no dependable record of what was taken out or why.
• Formatting leaks the information back. Text layered over shapes, metadata in the file properties, tracked changes that were never accepted.
• It takes days. Time that a small information-governance team does not have.

How RedactBox handles it

RedactBox is built for exactly this workflow. You import the email archive or PDF bundle, and the platform triages, redacts and exports the set as a single defensible response.

Two things matter most for a compliance team. The first is consistency: when you redact a name, RedactBox applies it across every document that name appears in - so redact each name once, and it lands in all 18 documents, not just the one on screen. The second is proof: every redaction is logged, so the audit trail for your response is built as you go rather than scrambled together after a challenge arrives.

It is deliberately mid-range in cost and scope. You get the archive-wide redaction and the complete record of decisions that enterprise eDiscovery tools provide, without the price tag or the weeks of setup that come with them. For a multi-academy trust, a council team or an HR function, that is the difference between a process you can run in-house and one you have to outsource.

Start with the next request

If you are new to redaction, do not try to redesign your whole disclosure process at once. Take your next SAR or FOI request and work through it with the four questions above: what must come out, what can stay, why did I decide that, and how am I recording it.

Do it consistently and the redactions stop being a risky judgement call and become a routine, documented step in a process you can stand behind. Every redaction logged, every email accounted for - that is what makes a disclosure defensible.