How to Redact a DSAR Response: Third-Party and Exempt Data

To redact a DSAR response, you remove any personal data that belongs to someone other than the requester, along with material that is exempt or legally privileged, before you disclose the rest. An access request covers the requester's own personal data, not other people's, so third-party names, other customers' details, and internal information about colleagues generally have to be redacted, and a human should confirm what stays and what goes.

This is general information, not legal advice. Below we cover what to redact, how to do it consistently, and why a person should always control the final call.

Why redaction is necessary

The right of access lets a person see the data you hold about them. It does not give them a window into other people's data. Because personal data is messy, records about the requester routinely contain information about others: a support ticket that names a second customer, an email thread that copies a colleague, a note that references a third party. Disclosing that information without redaction can breach the other person's privacy and turn a routine response into a data breach. Careful redaction is what lets you disclose the requester's data without exposing anyone else's.

What to redact

Redaction falls into a few recurring categories. Working through them systematically is more reliable than eyeballing each document.

Not every mention of another person is automatically redacted. In some cases disclosure is reasonable, for example where the other person has consented or where their identity is already known to the requester and revealing it does not harm them. This is a judgment call, which is exactly why a person, not a script, should make it. For the withholding categories beyond third-party data, see the DSAR exemptions guide.

How to redact consistently

The goal is a disclosure that is complete for the requester and clean of everyone else's data. A repeatable approach helps.

1. Work from a manifest. Start from a structured list of what discovery found, so you can see every record that needs review rather than hunting through raw exports. This is where automated personal data discovery pays off.
2. Flag as you scope. Mark items that contain third-party or exempt data during manifest review, so redaction is targeted rather than a last-minute sweep.
3. Redact the content, not just the visible layer. A true redaction removes the underlying data, not just a black box drawn over it. Make sure the information cannot be recovered from the file.
4. Be consistent across records. If a third party is redacted in one document, redact them everywhere they appear, or you undermine the protection.
5. Record what you removed and why. Keep a note of each redaction category so you can justify it if questioned, without revealing the redacted content itself.

Redaction mistakes that cause breaches

• Reversible redactions. A black rectangle over text in a document that still contains the underlying words is not a redaction. Anyone can lift it.
• Metadata leaks. Names and details can hide in file metadata, tracked changes, or hidden columns. Check beyond the visible page.
• Inconsistent treatment. Redacting a third party in one file but leaving them named in another defeats the purpose.
• Over-redaction. Blacking out the requester's own data because it sits near someone else's makes the response incomplete. Redact narrowly.

Keep a human in control

Automation can surface likely third-party mentions and speed up the work, but the decision about what to disclose should rest with a person. Some redactions are clear; others depend on context that only a reviewer can weigh. A human review gate before delivery is what keeps you in control of the disclosure, and it is the safeguard against both accidental leaks and unnecessary withholding. Redaction sits inside the wider DSAR process, right before approval and delivery.

Redaction across different file types

The same principles apply whatever format the data is in, but the practical steps differ. Documents and PDFs need the underlying text removed, not just visually covered. Spreadsheets can hide data in filtered rows, hidden columns, or formula references, so check beyond what is on screen. Emails often carry third-party data in signatures, quoted threads, and CC lines. Chat and ticket logs interleave multiple people's messages, so redacting a conversation cleanly takes care. The common thread is that a surface-level pass is not enough: you have to remove the data itself, everywhere it appears, in a way that cannot be reversed.

This is another reason to work from a manifest rather than opening files one by one. A structured list of what discovery found, grouped by system and category, lets you apply the same redaction decision consistently across every place a third party shows up, instead of catching them in one export and missing them in another.

When I respond to a DSAR, should I redact third party info?

Yes, where the third party is identifiable and disclosing them would not be reasonable. Redact rather than withhold wherever you can, because the requester is entitled to everything in the record that is about them. The test is not whether another name appears. It is whether that person is identifiable from what you send and whether disclosing that detail is reasonable given their expectations and any duty of confidentiality you owe them.

Three practical distinctions decide almost every case. A member of your staff acting in a professional capacity is usually disclosable: the agent who handled a ticket, the account manager who wrote the note, the reviewer who approved a refund. A private individual who is not the requester usually is not: another customer copied on a thread, a family member named in a complaint, a neighbor mentioned in a dispute. And an opinion someone recorded about the requester is the requester's personal data even though somebody else wrote it, so the content is disclosable even where the author's identity may not be.

Write your decisions down as you go. When a person challenges a redaction months later, the question you will be asked is why, and a short line recording the basis for each category of redaction answers it in seconds. Reconstructing it from memory does not.

Do third party company names get redacted?

Usually not. A company name is not personal data, so the default is to leave it in. The exceptions are narrow but real: a sole trader or single-person business whose name identifies an individual, a company name that is the person's own name, and a case where naming the company would make an otherwise unidentifiable individual identifiable, such as a complaint that names one employee's employer alongside their role.

Redacting every company name by default causes a specific, avoidable problem. Vendor, partner and processor names are often the most useful part of an access response, because they tell the requester who else has their data and let them exercise rights downstream. Strip them out and the response reads as evasive while giving no additional protection to anyone. If your redaction policy has a blanket rule about company names, it is worth revisiting.

Example of redaction of third-party data in a DSAR response

Take a support ticket thread where the requester complained about a delivery. The raw thread contains the requester's own messages, replies from two of your agents, an internal note discussing a neighboring address where the parcel was left, and a forwarded email from the courier naming the driver.

A correctly redacted version keeps the requester's messages in full, keeps both agents' replies with their names intact because they were acting professionally, keeps the internal note's substance about the requester while removing the neighbor's name and house number, keeps the courier company name because a company is not a person, and removes the driver's name because they are a private individual identifiable in the record and their involvement is incidental to the requester's own data.

Then there is a fourth step people forget. The metadata. The exported file's properties, the ticket's participant list, the email headers in the forwarded message and the file name itself can each carry a name that was carefully removed from the body. Check the container, not just the content, and flatten the file so the removal cannot be undone by anyone who opens it in the right tool.

Personal information redaction during a third-party audit

Redaction comes up in a second, different situation that gets confused with the first: an auditor, a customer's security team or a regulator asks to inspect records that happen to contain personal data. The obligation runs the opposite way. In a DSAR you are disclosing to the person the data is about, so their own data stays in and everyone else's comes out. In an audit you are disclosing to a party the data is not about, so the default is that identifying detail comes out for everyone, including the person the record concerns.

Two rules keep this clean. First, work from a copy, never the source system, and never grant an auditor standing access to production data as a shortcut around redaction. Second, decide whether the auditor needs identity at all. Most audit questions are about process and controls rather than about people, and a sample of records with names, contact details and identifiers replaced by consistent placeholders answers them while keeping the data set out of scope for a disclosure you did not intend to make. Where the auditor genuinely needs identified records, that is a disclosure to a third party and it needs a lawful basis and a contract, not a redaction policy.

Where redaction fits in the response

By the time you redact, you have already discovered the data, compiled a manifest, and scoped the request. Redaction is the last shaping step before the response is drafted and sent, and it is the one most likely to cause a breach if rushed. Leaving time for it is why discovery should start early, as covered in the DSAR response deadline guide.

Want redaction that is targeted and auditable instead of a manual sweep? Obtainer compiles a manifest, surfaces likely third-party data for review, and holds everything at an approval gate. The redaction step keeps a person in control of exactly what gets disclosed before anything leaves your systems.