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.

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.