When someone makes a subject access request — a SAR, or DSAR — you have to give them the personal data you hold about them, and only about them. Everyone else's personal data caught up in the same emails, notes and files has to come out first.
That is the whole difficulty of a SAR. It isn't bulk redaction, where you strip every name from a document. It's selective: the requester's own data must survive intact, including things they won't enjoy reading, while third parties have to be removed — and removed consistently enough that they can't be reconstructed from what's left.
This guide covers what to redact, what you must not redact, and the mistakes that turn a well-intentioned response into a data breach of its own.
General guidance, not legal advice. The ICO's guidance on the right of access is the authority, and complex requests are worth taking advice on.
SAR, DSAR, subject access request
The three terms mean the same thing. Subject access request is the language of the legislation and of the ICO, and SAR is its usual abbreviation. DSAR — data subject access request — is widespread in industry, and is arguably the more precise form, since UK GDPR calls the individual the data subject.
Nothing turns on which you use. This guide uses SAR and DSAR interchangeably, because your colleagues, your policies and your suppliers will too.
The deadline you're working to
Under UK GDPR you must respond without undue delay, and at the latest within one month of receiving the request. That month runs from receipt, not from when the request reaches the right desk.
You can extend by a further two months where the request is complex or where an individual has made several requests — but you must tell the requester within the original month, and explain why.
The deadline matters here because redaction is usually the slowest part of the job. A request that surfaces four thousand emails is not a search problem, it's a review problem, and organisations routinely discover this in week three.
Why you redact at all
Article 15(4) of the UK GDPR says the right to obtain a copy "shall not adversely affect the rights and freedoms of others." Schedule 2, Part 3 of the Data Protection Act 2018 develops this into the third-party exemption: you don't have to disclose information that identifies another living individual.
Two things follow that people often miss.
It's an exemption, not an instruction. You aren't obliged to redact third-party data in every case — you're permitted to withhold it. If it's reasonable to disclose without consent, you may.
It only covers other people's personal data. It isn't a general licence to remove anything awkward, commercially sensitive or unflattering. Those need a different exemption, or they stay in.
What has to come out
- Names of other individuals — colleagues, customers, complainants, family members
- Contact details belonging to others — email addresses, phone numbers, home addresses
- Identifiers — staff numbers, National Insurance numbers, account numbers, case references tied to another person
- Opinions expressed about other people, where those opinions are their personal data
- Anything that identifies a third party indirectly — see below, this is where most failures happen
What must stay in
This is the half that gets forgotten, and it produces more complaints to the ICO than over-disclosure does.
Opinions about the requester are the requester's personal data. A manager's blunt appraisal, a note calling them difficult, an internal email questioning their judgement — if it's about them, it's theirs, and they're entitled to it. Removing it because it's embarrassing for the organisation is not a lawful redaction.
The author of a comment about the requester is often disclosable. A manager writing about a member of staff is acting in a professional capacity, and it's frequently reasonable to disclose who wrote what without their consent. Redacting every author by reflex is over-redaction, and it tends to be obvious to the requester — which is usually what escalates a routine request into a complaint.
Information that is merely commercially inconvenient stays. Trade secrets and legally privileged material have their own exemptions. General embarrassment does not.
The reasonableness test
Where third-party data is involved, you have a choice: seek that person's consent, or decide whether it's reasonable to disclose without it. The factors to weigh include:
- the type of information, and how sensitive it is
- any duty of confidentiality owed to the third party
- whether you have taken steps to seek consent
- whether the third party is capable of giving consent
- whether they have expressly refused
Some cases resolve quickly. A colleague named in a routine work email, acting in their professional role, is usually disclosable. A whistleblower, or someone who gave information in confidence, usually is not — the duty of confidentiality weighs heavily and redaction is the safer course.
Record your reasoning as you go. If the response is challenged months later, "we judged it reasonable at the time" is much stronger with a contemporaneous note than without one.
Where organisations get caught out
Inconsistent redaction
If you black out a name on page four but leave it on page forty, you haven't redacted it. Worse, the requester can now map the redaction to the name and read the redacted passage with confidence.
Consistency has to hold across the entire response, not each document individually. That's genuinely hard by hand across hundreds of files, and it's the single most common way SAR redaction fails.
Indirect identification
Removing a name doesn't help if what remains points to one person. "The Finance Director" identifies someone precisely in a company with one Finance Director. So does "the woman who joined in March", or a job title plus a location.
Ask of every redaction: could the requester work out who this is from what's left? They know the organisation. They often know exactly who was involved. Their context is much richer than yours when you're reviewing at speed.
Email chains
A single forwarded thread can carry dozens of third parties — in the To and Cc lines, in quoted replies, in signature blocks, in the metadata beneath the visible text. Reviewing the top message and moving on misses most of them.
Attachments
Spreadsheets with hidden columns or additional sheets, documents with tracked changes and comments still live, PDFs carrying author names in their properties. All routinely reviewed on screen without anyone opening the parts that don't display by default.
Redaction that doesn't actually redact
Drawing a black rectangle over text in a PDF leaves the text in the file, fully extractable by anyone who receives it. The page looks convincing and the data is still there. This has caused real disclosure incidents, and it's covered in detail in why drawing a black box isn't redaction. The working process — including metadata, filenames and hidden content — is in how to redact a PDF and what still leaks after you redact a PDF.
How to redact a SAR response
- Scope it early. Establish what you hold and roughly how much of it exists in the first days, not the third week. The extension has to be claimed within the month, and you can only claim it if you know you need it.
- Clarify if the request is broad. You may ask the requester to specify what they're looking for. This is not a delaying tactic if done promptly and in good faith, and it often reduces the volume dramatically.
- Build a list of third parties before you start redacting. Names, variants, nicknames, initials, email addresses. Working from a list is what makes consistency achievable.
- Redact against the list, then review for indirect identification separately. They're different tasks and they catch different things. Doing them in one pass means doing both badly.
- Check metadata and hidden content before release — document properties, tracked changes, comments, hidden rows and sheets.
- Verify the output. Open the finished files, select the text, copy it, and read what actually comes out.
- Keep a note of your reasoning on anything you withheld and why.
Verifying before you send
Don't trust how the response looks. Test it:
- Select all the text in each finished document and paste it somewhere plain. Anything you meant to remove that reappears is still in the file.
- Search the full response for each name on your third-party list. One hit is one too many.
- Check document properties for author names and original filenames.
- Read a sample as the requester would, knowing what they know. Can you identify anyone from what's left?
The last check is the one people skip, and it's the one that catches indirect identification.
Getting the volume down
Most of what makes a SAR painful is scale. Twenty documents is an afternoon; four thousand emails is a project, and the failure mode isn't usually a wrong judgement call — it's fatigue on page three hundred.
Automated detection helps with the mechanical part: finding every occurrence of a name, an email address, a phone number or a reference number across a large set of files, consistently, without the misses that come from reviewing at speed. It won't make the reasonableness judgements for you, and it shouldn't — those need someone who understands the context.
What it changes is where your attention goes. Reviewing what a tool has found is a different task from finding it all yourself, and it's the part where human judgement actually adds something.
If you want that mechanical pass done for you, eleyed's SAR redaction service sets out what it removes, what it deliberately leaves to you, and what a bundle costs.
A freedom of information release is a different job with a different default — the information goes out unless an exemption applies. That redaction problem is covered in FOI redaction: what UK public authorities must remove before releasing records.