Third-Party Data in DSARs: When and How to Redact Information

The Third-Party Problem

Every DSAR response involves a balancing act. The data subject has a right to receive their personal data. But their data rarely exists in isolation. It is tangled up with other people's data — in email threads, shared documents, meeting notes, CRM records, complaint logs, and HR files. The names, opinions, contact details, and personal information of colleagues, customers, family members, and business contacts appear alongside the requester's own data.

You cannot simply hand over everything. Disclosing one person's personal data in response to another person's DSAR would violate the third party's own data protection rights. But you also cannot use the presence of third-party data as an excuse to withhold the requester's information entirely. The law requires you to find the middle ground: provide the data subject's personal data while protecting other people's privacy.

This guide covers when third-party data appears, what the law says about disclosure and redaction, practical techniques for different document types, and how to document your decisions.

For the broader overview of DSAR exemptions, see our DSAR exemptions guide.

When Third-Party Data Appears

Third-party data shows up in almost every DSAR response that involves more than basic account information. Common scenarios include:

Email Correspondence

Email threads are the most common source of third-party data. A thread between the data subject and your support team might CC other customers, mention colleagues by name, or include forwarded messages from third parties. The data subject is entitled to their own data in the thread — but not to other people's personal information that happens to appear alongside it.

HR and Employment Records

Employee DSARs frequently involve third-party data. Performance reviews contain the opinions of managers and peers. Grievance records name other employees. Recruitment files may reference other candidates. Disciplinary records often involve witnesses whose identity may need to be protected.

Customer Complaints and Case Files

If the data subject complained about another person (or was the subject of a complaint by another person), the complaint file will contain both parties' personal data. Releasing the identity of a complainant or witness without their consent can be problematic, particularly in sensitive contexts.

Shared Documents and Notes

CRM notes, meeting minutes, project files, and shared documents frequently reference multiple individuals. A meeting note might summarize a discussion involving the data subject and five colleagues, with opinions and comments attributed to each.

Medical and Health Records

Occupational health reports, absence records, and welfare notes may contain information about family members or other individuals who are connected to the data subject's health situation.

The Legal Framework

GDPR and UK GDPR

The GDPR addresses third-party data in Recital 63, which states that the right of access "should not adversely affect the rights and freedoms of others, including trade secrets or intellectual property and in particular the copyright protecting the software." More specifically, Article 15(4) provides that the right to obtain a copy of personal data "shall not adversely affect the rights and freedoms of others."

The UK Data Protection Act 2018 (Schedule 2, Part 3, Paragraph 16) provides further detail. It states that a controller is not obligated to comply with a subject access request to the extent that doing so would involve disclosing information relating to another individual who can be identified from that information, unless:

• The other individual has consented to the disclosure, or
• It is reasonable in all the circumstances to comply without the other individual's consent

When determining what is reasonable, the DPA 2018 directs you to consider:

• The type of information that would be disclosed
• Any duty of confidentiality owed to the other individual
• Any steps taken to seek consent from the other individual
• Whether the other individual is capable of giving consent
• Any express refusal of consent by the other individual

CCPA

The CCPA does not have the same explicit third-party redaction framework as the GDPR. However, the CCPA's requirement to provide personal information "collected about that consumer" (Cal. Civ. Code § 1798.100) means you disclose the requesting consumer's data, not other people's data. Additionally, the CCPA prohibits disclosure of personal information that would create a "substantial, articulable, and unreasonable risk" to the security of that information or the consumer's account.

In practice, CCPA responses also require reviewing for and handling third-party information, even though the legal framing is different from the GDPR.

What to Redact

Always Redact

• Names and contact details of other customers who appear in correspondence, complaint records, or shared files
• Personal opinions about identifiable third parties expressed in notes, reviews, or reports (unless the opinion is about the data subject and attributable to a staff member acting in a professional capacity)
• Sensitive personal data of third parties — health information, financial details, racial or ethnic origin, religious beliefs, or other special category data belonging to someone other than the data subject
• Confidential source information — the identity of whistleblowers, anonymous complainants, or confidential informants
• Information about minors — details about children who are not the data subject, particularly in education, social work, or family contexts

Generally Do Not Need to Redact

• Names of your own staff who dealt with the data subject in a professional capacity. The ICO has confirmed that disclosing the names of employees who interacted with the data subject in a business context is generally reasonable. An employee who sent a customer service email does not have a reasonable expectation that their name will be withheld from the customer they emailed.
• Information the data subject already has. If the data subject sent an email to a named third party, they already know that person's name and email address. Redacting information the requester already possesses is unnecessary (though you should still consider whether the context reveals new information about the third party).
• Business information that is not personal data. Company names, product names, pricing, and policy terms are not personal data and do not need to be redacted.
• Professional role references. Referring to "your account manager" or "the HR advisor" without a name does not require redaction because it does not identify a specific individual (though as noted above, naming the staff member is usually fine).

Judgment Calls

Some situations require balancing the data subject's right of access against the third party's right to privacy. These include:

• Opinions expressed by colleagues about the data subject. The data subject has a right to know what is said about them, but the person who expressed the opinion may have expected confidentiality. Consider the context: a formal performance review is expected to be disclosed; a private rant in an internal email may not be.
• Family members referenced in records. A data subject's HR file might mention their spouse's health condition as the reason for a leave request. The spouse's health data is their personal data, not the data subject's. Redact it unless consent has been obtained or disclosure is clearly reasonable.
• Public figures and professionals. If the third party is a public figure (a politician, a regulator, a journalist) or is acting in a professional capacity (a doctor, a solicitor), there is generally a lower expectation of privacy regarding their professional interactions. This does not eliminate the obligation to consider their rights, but the balance may tip toward disclosure.

Practical Redaction Techniques

PDF Redaction

PDF is the most common format for delivering DSAR responses, and most redaction is done in PDF format.

Using Adobe Acrobat Pro:

1. Open the document in Acrobat Pro
2. Go to Tools > Redact
3. Select the text or areas to redact
4. Apply redaction (this permanently removes the underlying text)
5. Save the redacted document

Critical warning: Simply drawing a black box over text in a PDF does not redact it. The text underneath remains in the file and can be extracted by anyone with a PDF editor. You must use a proper redaction tool that removes the underlying content. Adobe Acrobat's "Redact" tool does this correctly. A black highlight or a drawn rectangle does not.

Alternative PDF tools: PDF-XChange Editor, Foxit PhantomPDF, and several open-source tools also offer proper redaction functionality. Verify that whichever tool you use actually removes the underlying data rather than just covering it visually.

Email Redaction

Emails present a particular challenge because of threading, headers, and attachments.

Approach 1: Print to PDF and redact. Convert the email thread to PDF, then apply PDF redaction as described above. This is the most common and reliable method.

Approach 2: Copy, redact, and reformat. Copy the email content into a document, manually remove third-party information, and save as PDF. This works well for individual emails but becomes labor-intensive for long threads.

Approach 3: Screenshot and redact. For short emails, a screenshot with redacted areas can work, but it is not scalable and may lose metadata.

Regardless of approach, ensure that:

• Email headers (To, From, CC, BCC fields) are reviewed for third-party data
• Forwarded content within threads is checked for third-party information
• Attachments are reviewed and redacted separately
• Signature blocks of third parties are reviewed (they may contain phone numbers, addresses, and other personal data)

Document Redaction (Word, Excel, Google Docs)

For office documents:

1. Never redact in the original format and send the editable file. Someone with the original can undo your changes, view revision history, or recover deleted content.
2. Convert to PDF first, then apply proper PDF redaction.
3. Before converting, check for tracked changes, comments, and metadata that may contain third-party information. Use the "Inspect Document" feature (in Microsoft Word) or equivalent to remove hidden data.

Spreadsheet Redaction

Spreadsheets require extra care:

• Delete rows or cells containing third-party data (do not just hide them — hidden rows and columns are trivially unhidden by the recipient)
• Remove any formulas that reference other sheets or cells containing third-party data
• Check for comments, notes, and cell history
• Convert to PDF for delivery, or deliver as a new, clean spreadsheet with only the relevant data

Documenting Your Decisions

Every redaction decision should be documented. You do not need a lengthy legal memo for each one, but you do need a record that shows:

• What was redacted — a description of the type of information removed (e.g., "Name and email address of a third-party customer mentioned in a support email thread")
• Why it was redacted — the legal basis (e.g., "Third-party personal data — disclosure would adversely affect the rights of the third party under Article 15(4) / DPA 2018 Schedule 2, Part 3, Paragraph 16")
• Whether consent was sought — if you attempted to obtain consent from the third party, note the outcome
• The balancing test — for judgment calls, briefly note the factors you considered and the conclusion you reached

This documentation serves two purposes: it demonstrates compliance if the data subject complains to the regulator, and it creates an institutional record that helps you handle similar situations consistently in the future.

Communicating Redactions to the Data Subject

Your DSAR response should inform the data subject that some information has been withheld or redacted, and explain why in general terms. You do not need to identify the specific third parties whose data was redacted (doing so would defeat the purpose), but you should:

• State that some information has been redacted because it contains the personal data of other identifiable individuals
• Explain the legal basis for the redaction
• Inform the data subject of their right to complain to the supervisory authority (the ICO in the UK, the relevant DPA in the EU) if they believe the redaction was unjustified

Do not simply send a heavily redacted document without explanation. A response that is 70% black bars with no explanation will (rightly) generate a complaint.

Common Mistakes

Over-redacting. Removing entire documents because they contain a single mention of a third party. The correct approach is to redact the third-party information and provide the rest.

Under-redacting. Failing to check email headers, document metadata, and revision history for third-party information. The visible text may be clean, but hidden data can contain names, email addresses, and tracked changes by third parties.

Fake redaction. Using black highlighting, text coloring, or image overlays instead of proper redaction that removes the underlying data. This is a data breach waiting to happen.

Inconsistent decisions. Redacting a colleague's name in one document but leaving it visible in another, without a clear reason for the difference. Consistency matters, both for compliance and for credibility if challenged.

Not documenting. Making redaction decisions on the fly without any record. If the data subject complains six months later, you need to be able to explain what you did and why.

For detailed guidance on the email-specific challenges of DSAR redaction, see our guide on DSARs and email.

References

• GDPR: Article 15(4), Recital 63. GDPR Article 15 | Recital 63
• UK Data Protection Act 2018: Schedule 2, Part 3, Paragraph 16. Full text on legislation.gov.uk
• ICO Guidance: Right of access — third party information. ICO right of access guidance
• CCPA: Cal. Civ. Code § 1798.100. Full text

Related Guides

• What to Include in a SAR Response — full response requirements
• DSAR Exemptions — all available exemptions
• DSARs and Email: Searching Inboxes — the email-specific challenge

Master the Redaction Process

Our DSAR Compliance Guide includes redaction checklists, decision templates, and worked examples designed to help you handle third-party data confidently and consistently across every DSAR response.

Read the DSAR Compliance Guide