DSAR Redaction: 6 Secure Steps for Safer Delivery

Under UK GDPR Article 15, the right of access covers the requester’s own personal data. Where a document also contains another person’s personal data, for example a colleague’s name in an email thread, a customer’s details in a case note, or an opinion about someone else, you need to separate the two before disclosure.

The ICO’s guidance on third-party information sets out a three-step test: can you comply without revealing who the third party is? If not, has the third party consented? If not, is it reasonable to disclose without their consent, weighing any duty of confidentiality and how identifiable they’d be? Redaction is how you satisfy the first step; the second and third steps only come into play when redaction alone can’t preserve both the requester’s right and the third party’s protection.

What needs to be redacted

1. Names and contact details belonging to colleagues, customers or other third parties.
2. Opinions and commentary that could identify a specific person, such as a manager’s private assessment of a colleague.
3. Special category data relating to someone other than the requester.
4. Internal references such as employee numbers or system IDs that could identify a third party indirectly.

Most teams redact the same way: download the documents, work through them by hand with a word processor or PDF tool, then compile the response. It holds up for a handful of straightforward requests, and breaks down as request volumes climb, which is exactly the direction they are heading across regulated sectors.

Inconsistent redaction is the most common failure: without a written standard, two reviewers make different calls on the same document, one redacts a job title, the other leaves it in, and the inconsistency is hard to defend if challenged. Metadata exposure is a technical failure: a black box drawn over text in a word processor doesn’t always remove the underlying text, which can sometimes still be selected, copied or extracted from the file. Scope creep happens under time pressure, when teams narrow a search without documenting why, turning an undocumented judgement call into a liability if the response is questioned later. And the absence of an audit trail compounds all three: a spreadsheet and a folder of PDFs doesn’t show the ICO how a redaction decision was reached.

The risk extends beyond regulatory exposure: disclosing a colleague’s personal data inside someone else’s DSAR response can trigger a separate complaint from that third party, turning one error into two incidents.

A repeatable workflow cuts both the risk of error and the time each response takes to review. Here’s a five-step approach that holds up across document types and team sizes.

Define your redaction standard before you start

Before anyone reviews a document, agree a shared definition of what gets redacted, in writing. At minimum it should cover which categories are always redacted (names, contact details, special category data), which need a judgement call (job titles, team names, indirect identifiers), and how to handle documents where the requester’s and a third party’s data can’t be separated. This standard becomes your audit evidence: if a decision is challenged, you can point to the policy that governed it.

Collect and catalogue documents centrally

Gather every in-scope document in one place before review starts. Documents scattered across inboxes, shared drives and case systems are where things get missed. A central record of what was collected, from which system and by whom, is the foundation of a response you can defend.

Review and redact systematically

Work through each document against your written standard, and note the category for every redaction made (third-party name, colleague contact detail, and so on) rather than leaving it undocumented. It takes longer upfront and saves far more time defending the decision later. Use redaction software that burns the redaction into the document rather than layering it on top: the ICO’s security guidance expects technical measures proportionate to the risk, and a cosmetic redaction does not meet that bar.

Quality-check before compilation

A second reviewer checking redacted documents is the control that catches the missed email address or the name left in a footnote. Build it into the workflow as a standard step, applied to every response. No exceptions for tight deadlines.

Document the decisions

Record what was withheld and why. If a document is excluded entirely because redaction would make it meaningless, document that decision and communicate it to the requester. Unexplained omissions are what invite challenges.

Redaction protects third parties. Secure delivery protects the requester, and it’s your responsibility either way. A DSAR response usually carries a significant volume of the requester’s own personal data, so sending it as an unprotected email attachment or an open shared-drive link falls short of the technical and organisational measures UK GDPR expects.

What secure delivery looks like in practice

For most organisations, the floor is a password-protected file with the password sent through a separate channel, by phone or a different email thread. Organisations handling DSARs regularly, or responses that carry particularly sensitive data, are better served by a secure delivery portal.

Encryption in transit and at rest

Encryption covers more than the delivery mechanism itself. In transit, that means HTTPS for portals and TLS for email where it’s configured; the ICO’s guidance on encryption and data transfer is explicit that unencrypted channels fall short of the expected standard. At rest, it means keeping the documents encrypted in a controlled location while they’re being reviewed and compiled. And access should be limited to the people directly working the case, which narrows the chance of inadvertent disclosure before the response even goes out.

Verify identity before delivery

Confirm you’re sending the response to the right person before it goes out. An email reply to the same thread the SAR arrived on is reasonable assurance; anything less certain warrants a check first. Sending someone else’s personal data to the wrong address is a breach in its own right, separate from anything that happens with the content.

Redaction and secure delivery are repeatable steps that need to work the same way across every request, every reviewer and every document type.

The teams that get this right share four things: a written redaction policy applied consistently across the whole team, a central case record tracking what was collected, reviewed, redacted and sent, a delivery standard that holds regardless of who’s handling the case, and an audit trail that can be produced quickly if a complaint lands.

Gracie AI Agents with Personas and Skills structures the DSAR workflow from intake through to secure delivery inside SureCloud’s Data Privacy Management module, logging every redaction decision and delivery step in an auditable record. SureCloud customers report a 50 to 65% reduction in manual evidence collection, and the same governed workflow that speeds up evidence collection is what makes redaction and delivery decisions defensible after the fact.