SAR Third-Party Data Redaction: A UK Employer's Guide

When responding to a subject access request, almost every employer runs into the same problem: the data about the requester is mixed up with data about other people. An email thread names colleagues. A disciplinary file includes witness statements. A performance review mentions a client.

You cannot simply hand all of it over. UK GDPR gives the requester a right to their data — not to other people's. This guide explains when to redact, how much to redact, and the mistakes that get employers into trouble with the ICO.

This guide covers third-party data handling in SAR responses under UK GDPR and the Data Protection Act 2018. It is not legal advice.

The legal basis for redacting third-party data

UK GDPR Article 15(4) provides directly:

"The right to obtain a copy referred to in paragraph 3 shall not adversely affect the rights and freedoms of others."

This is the permission to redact — and in many cases the obligation to do so. Disclosing an email that names a colleague as a witness to misconduct could seriously affect their welfare and safety. Article 15(4) requires you to balance the requester's right against others' rights.

The ICO's right of access guidance elaborates: you should consider whether it is reasonable to disclose the third party's data without consent, taking into account all the circumstances, the type of information, and whether the individual has consented or would be likely to consent.

What counts as "third-party data"

Third-party data in a SAR context is any information that identifies or could identify another individual. In a typical employee SAR, this includes:

Names and contact details of colleagues in emails
Identifying details in performance notes ("the line manager [NAME] recommended...")
Witness statements with personal details
References given about or by named individuals
Occupational health information about someone other than the requester
Opinions about other employees from manager correspondence

The key test is identifiability — not just name, but any combination of details that allows the requester (who knows the workplace) to identify the person. Even "a senior female colleague in finance" may identify someone in a small team.

When you can and cannot withhold

Can withhold without consent:

Identifiable details of colleagues where disclosure would cause them harm (e.g., a whistleblower who reported the requester's conduct)
Witness statements where naming the witness could lead to retaliation
Data whose disclosure would breach another individual's reasonable expectation of privacy

Cannot withhold merely because:

Another person's name appears in a document (a name alone, in a routine context, is not a strong enough reason to withhold an otherwise relevant document)
The third party would prefer the document not be shared
The document contains opinions about the requester by a named manager (the opinions are about the requester — they are subject to the SAR)

The "reasonable in all the circumstances" test:

UK GDPR Article 15(4) is not a blanket permission to withhold third-party data. The ICO's right of access guidance requires you to consider:

The type of information involved
Whether the third party has consented or would be likely to consent
Any duty of confidence owed to the third party
Whether it is possible to provide the requester's data without revealing the third party's identity (i.e., whether redaction would allow disclosure)

Partial redaction versus full withholding

Partial redaction is almost always preferable to full withholding. If an email contains both personal data about the requester and identifying information about a third party, the right approach is usually:

Provide the email
Redact the third party's identifiable details

Full withholding is only justified where the document is fundamentally about the third party rather than the requester, or where even a redacted version would allow identification of the third party.

Example: An email thread about the requester's performance review includes comments from their line manager and another manager named in the thread. The requester's personal data (the performance comments about them) must be disclosed. The other manager's name can be redacted. The comments the managers made about the requester are not the other manager's personal data — they are the requester's.

How to redact — practical approach

What redaction means: Replace identifying text with a neutral marker. "[REDACTED]" or "[THIRD PARTY]" in text documents. Black bars in PDF. Do not use white text on white background (readable when pasted into Word) or thin grey bars (visible under zoom).

What level of detail to redact: Only what is necessary to prevent identification. If a colleague is mentioned only as "your line manager at the time," and you have only had one line manager in the relevant period, simply removing the name is insufficient — the role description may identify them. Redact both.

Consistency: If you have redacted Person A's name in one document, redact it in all documents. Inconsistent redaction leaves the requester able to piece together identities across the response.

Log redactions: For each document where you have redacted third-party data, note:

What was redacted
Why (the third-party protection justification)
Whether you considered whether consent was possible or the person would likely consent

This log is part of your audit trail. The ICO expects to see reasoning, not just redacted text.

Consent as an alternative

If the third party consents to disclosure of their data, you do not need to redact. This is practical in two situations:

Named witnesses in a disciplinary hearing who are happy for their contribution to be known
Colleagues named in reference to genuinely routine matters who confirm they have no objection

Obtaining consent takes time and may not be possible within the SAR response deadline. It is also not always appropriate to ask — asking a whistleblower whether they consent to being identified may in itself be a problem. Do not make consent the default approach; reserve it for cases where it is realistic and proportionate.

Common redaction mistakes

Blanket redaction of all third-party names. Some employers redact every mention of another person, including names in routine correspondence ("meeting scheduled by [REDACTED]"). This is disproportionate and leaves the response looking like it is concealing more than it is. Redact where there is a genuine reason to protect — not by default.

Failing to redact identifiable characteristics. Removing a name but leaving "the only female director" or "the HR manager who joined in November" means the person is still identifiable in a small team. Think about identification from context, not just from the raw text.

Not logging why you redacted. The ICO does not just review whether you disclosed — it reviews whether your decisions were reasonable. An ICO complaint following a response with unexplained redactions puts you in a much weaker position than one with documented reasoning.

Using exemptions instead of redaction. Some employers reach for DPA 2018 exemptions (legal privilege, management forecasts) to withhold documents that contain third-party data, when the right approach was to provide the document with the third-party data redacted. Exemptions apply to documents you are not obliged to disclose at all — not to documents you should disclose but with some parts removed.

Connecting to the full SAR response process

Third-party redaction is a step within the broader SAR response process. For the complete workflow — from receipt to dispatch — see How to Respond to a Subject Access Request from an Employee. For guidance on applying DPA 2018 exemptions alongside redaction decisions, see SAR Exemptions Explained.

The SAR redaction guide provides additional worked examples for specific document types (emails, disciplinary notes, references).

Sources

This guide provides general information about handling third-party data in subject access requests under UK GDPR. It is not a substitute for legal advice.