Redacting Third-Party Data From a Subject Access Request Response

By the SladdPDF team · Published August 26, 2026 · Updated August 26, 2026

Almost every real subject access request (SAR/DSAR) pulls back a file where the requester's data is tangled up with someone else's — a colleague named in an HR complaint, a manager's comment in an email thread, a caller's number in a support log. The law does not let you refuse the request because of that. It expects you to separate the two, disclose the requester's own data, and redact what belongs to the third party. Getting that balance wrong in either direction — oversharing a colleague's disciplinary history, or hiding behind "third-party data" to withhold everything — is one of the most common ways SAR responses go wrong.

Why does a SAR response always seem to involve other people's data?

A subject access request asks an organisation to hand over the personal data it holds about one specific person. In practice, that data rarely lives in a file of its own. An HR investigation names witnesses and the person accused. A customer service thread quotes an agent's private notes about the caller. An email chain about a contract dispute copies in three colleagues who each add their own opinion. The requester's data and other people's data sit in the same document, often the same sentence.

That overlap is the whole reason third-party redaction exists as its own discipline inside SAR handling. Organisations that get it wrong tend to fail in one of two directions: they hand over unredacted internal commentary about colleagues, or they refuse to disclose an entire file because "someone else is mentioned in it." Both are non-compliant, and both are avoidable with the right test applied document by document.

The legal test: Article 15(4) and the rights of others

Article 15 GDPR gives a data subject the right to obtain a copy of their personal data. Article 15(4) then limits that copy right: it "shall not adversely affect the rights and freedoms of others." Recital 63 adds that this should not be read as a reason to refuse to provide any information to the requester at all — it is a scoping rule, not an escape hatch.

In the UK, the same balance is built into UK GDPR and the Data Protection Act 2018, which lists factors a controller must weigh before disclosing a third party's data without their consent: any duty of confidentiality owed to that person, the steps taken to seek their consent, whether they are capable of giving consent, and any express refusal of consent they have given.

Redact, don't refuse: what the EDPB actually says

The European Data Protection Board's Guidelines 01/2022 on the right of access address this directly. Where a controller decides that complying with a request would adversely affect someone else's rights, the Guidelines say the controller should first try to reconcile the conflict — commonly by removing or redacting the third party's information — rather than jump to withholding. The EDPB states plainly that the result of weighing Article 15(4) "should not be a refusal to provide all information to the data subject": at most, it should mean leaving out or making illegible the specific parts of a document that would cause the harm.

That single sentence resolves most of the disputes that come up in practice. If a manager's email about a requester also contains a throwaway remark identifying another employee's health condition, the fix is to redact that remark — not to withhold the whole email from the requester whose data it primarily concerns.

The three-step balancing test

The UK ICO's detailed subject access guidance sets out a practical sequence for deciding what to do with a passage that touches a third party. It runs, in outline:

1. Does it actually identify someone else? Check whether the information genuinely identifies a third party, or whether it can be anonymised — for example, by replacing a name with "a colleague" — while still answering the request.
2. Has the third party consented? If you can reasonably ask, and they agree, disclosure is straightforward. Consent does not need to be sought if it is not reasonable to do so, or if the third party has already refused.
3. If there is no consent, is disclosure reasonable in the circumstances? Weigh any duty of confidentiality to the third party, whether the information was provided in confidence, the steps already taken to obtain consent, whether the third party is capable of consenting, and any express refusal. There is no blanket rule — each passage is judged on its own facts.

Redaction is usually how step three plays out once the balance tips toward "not reasonable to disclose that person's details in full": the document still goes to the requester, with the third party's identifying details removed rather than the whole page withheld.

What the courts have said: Dawson-Damer and Ittihadieh

Two 2017 Court of Appeal decisions, handed down three weeks apart, are still the reference point for how far a controller can go in withholding or narrowing a subject access response.

In Dawson-Damer v Taylor Wessing LLP [2017] EWCA Civ 74, a law firm refused to search for and disclose data on the grounds of legal professional privilege and disproportionate effort. The Court of Appeal held that a controller relying on disproportionate effort has to show real evidence that the search would be disproportionate — a general assertion that the archive is large is not enough — and that legal professional privilege has to be established properly, not assumed.

In Ittihadieh v 5-11 Cheyne Gardens RTM Co Ltd [2017] EWCA Civ 121, decided alongside Deer v University of Oxford, the court considered subject access to files that mixed the requester's data with other residents' or staff members' data — the same "mixed personal data" problem organisations face in HR files and complaint logs today.

Read together, both cases push the same way: a controller cannot lean on vague generalities — "it involves other people," "it would take too long" — to avoid disclosure. It has to actually do the work of separating out what belongs to the requester, and redaction is the practical tool for doing that without breaching someone else's rights.

The stakes are not theoretical. The ICO's own published data-security incident figures track "failure to redact" as a distinct, recurring category of reportable incident — data disclosed with no redaction at all, or with redaction that did not actually work. It sits among the more common non-cyber incident types organisations report, alongside data sent to the wrong recipient.

What typically needs redacting in a real SAR bundle

The right-hand column is a starting point, not a rulebook — the three-step test above still has to be applied to each specific passage, because context changes the answer. A colleague's name might be fine to disclose in one email and need redacting in the next, depending on what is said next to it.

Common mistakes: over-redaction, under-redaction, and mosaic identification

Under-redaction is the more visible failure: sending an unredacted file that names a whistleblower, a complainant, or a colleague's medical condition. It is the direct cause of the "failure to redact" incidents that organisations report to the ICO, and it can turn a routine SAR response into a data breach in its own right.

Over-redaction is the quieter, more common failure: blacking out anything that mentions a name other than the requester's, including passages that are really about the requester and only incidentally name someone else. The EDPB's guidance is aimed squarely at this — the goal is the narrowest redaction that protects the third party, not the broadest one that is easiest to justify.

Mosaic identification catches redactors who stop at removing a name. If a document still says "the finance director, who joined in March and works from the Bristol office, raised a concern about X" — and there is only one person that description fits — the paragraph still identifies them even with their name gone. A thorough redaction removes the combination of details that narrows the field to one person, not just the label.

A step-by-step redaction workflow

1. Collect everything in scope first. Search the systems that plausibly hold the requester's data before deciding what to redact — you cannot apply the balancing test to documents you have not found.
2. Sort by document, not by SAR. Go through each file and mark passages that mention a third party.
3. Apply the three-step test to each passage. Identify → consent → reasonableness, as above, rather than one blanket rule for the whole bundle.
4. Redact the narrowest unit that protects the third party. A name, a phrase, a paragraph — not the whole page, unless the whole page is genuinely about them.
5. Check for mosaic identification. Re-read the redacted version as an outsider: does any surviving detail still point to one specific person?
6. Delete, then flatten — do not just draw over. A black box drawn on top of text in a PDF leaves the original text in the file, recoverable with a simple copy-paste. Redaction has to remove the content, then rasterise the page so nothing is left to extract.
7. Strip metadata. Author names, tracked changes, and document properties can name the same third parties the body text protects.
8. Test the export. Open the file you are about to send, select all, copy, and paste into a plain text editor. If a redacted name appears, the redaction did not work.
9. Log the reasoning. Keep a short note of why each significant redaction was made — it is the record that shows the balancing test was actually applied if the requester complains or the ICO asks.

If you want to run steps 6, 7 and 8 in one pass, you can redact a PDF in your browser with SladdPDF: draw over what should disappear, switch on Secure mode so each page is rasterised on export, and tick the metadata-removal option before you send the file. Everything runs locally in JavaScript and WebAssembly — the document itself is never uploaded, which matters when the file you are redacting is the same one a data subject is asking you to protect. For the mechanics of why an overlay box is not enough, see our guide to why a black box is not redaction, and for the wider compliance picture see our practical guide to GDPR redaction.

Pre-release checklist

Run this against the finished response before it goes out.

1. Every third-party passage has been through the three-step test — not redacted by reflex, not disclosed by default.
2. Redactions are the narrowest unit that protects the third party, not the whole surrounding paragraph or page.
3. Surviving text has been checked for mosaic identification — job titles, dates and locations that could still single someone out.
4. The export has been copy-paste tested and no redacted content comes out.
5. Metadata, tracked changes and document properties have been stripped or checked for third-party names.
6. The reasoning for significant redactions is logged in case the requester or the ICO asks about it later.
7. The one-month statutory clock has been tracked, with any extension for complexity communicated to the requester within the first month, per Article 12(3).