DSAR Redaction: What to Remove Before You Release the File

A subject access request obliges you to hand over someone's data. It does not oblige you to hand over everyone else's.

An employee submits a subject access request. You have one month. You pull their personnel file, their manager's notes, eighteen months of email, and a grievance investigation report.

Then you actually read it. The grievance report names the colleague who complained. The manager's notes quote a second employee's appraisal. Three emails contain a customer's home address. One attachment is another employee's sick note.

You are legally required to disclose the requester's personal data. You are simultaneously required not to disclose everyone else's. Those two obligations meet in the same PDF, and resolving them is what DSAR redaction actually is.

Most teams get this wrong in one of two ways: they redact in a manner that can be trivially undone, or they upload the entire bundle — every name in it — to a free online PDF tool in order to redact it. The second mistake is a personal data breach committed during the process of complying with data protection law.

Why a DSAR Requires Redaction at All

Article 15 of the GDPR gives a data subject the right to obtain a copy of the personal data an organisation holds about them. That right is not unlimited.

Article 15(4) states that the right to obtain a copy "shall not adversely affect the rights and freedoms of others." Recital 63 expands on this, noting that the right of access should not adversely affect the rights or freedoms of others, including trade secrets and intellectual property.

In practice this means a DSAR response usually contains three categories of content:

The deadline is the pressure. Article 12(3) requires a response without undue delay and within one month, extendable by two further months where requests are complex or numerous. Teams routinely spend most of that window locating documents and leave the redaction to the final days — which is exactly when mistakes are made.

What Actually Has to Come Out

Third-party personal data is broader than most people assume. It is not only names. Anything that identifies a living individual, directly or in combination with other information you are disclosing, is in scope.

Direct identifiers

• Names of colleagues, complainants, witnesses, customers and family members
• Personal email addresses and direct telephone numbers
• Home addresses and postcodes
• National insurance, social security and other government reference numbers
• Employee and payroll ID numbers belonging to other staff
• Bank account, IBAN and card details

The ones that get missed

• Email headers. A redacted email body means nothing if the To, From and CC lines are untouched.
• Signature blocks and footers carrying a third party's direct line and mobile.
• Document metadata — author fields, tracked changes and comment attributions naming reviewers.
• Handwriting and initials on scanned forms.
• Job titles in small teams. "The Regional Finance Manager raised a concern" identifies one person as surely as a name does.

That last category is the judgement-heavy one, and it is why fully automated redaction is a bad idea for DSARs. A pattern matcher can find every email address in a bundle in seconds. It cannot know that "the only part-time analyst on the team" is an identifier in your organisation. A human has to make that call — the tool's job is to make sure the human is looking at every candidate.

The Two Ways DSAR Redaction Fails

Failure one: the redaction can be undone

Drawing a black rectangle in a standard PDF editor does not remove text. It adds a drawing instruction that paints over text which remains fully intact in the file — recoverable by selecting and copying it, or by running pdftotext against the document.

A DSAR response is sent to someone who, by definition, is already interested enough in your records to have made a formal request. Handing them a file whose redactions can be lifted with a copy-paste is the worst possible audience for that mistake.

We covered the mechanism of this failure in detail in The Black Box Flaw. The short version: only rasterization — flattening each page to an image and rebuilding the PDF from those images — actually destroys the underlying text.

Failure two: you upload the bundle to redact it

This one is specific to data protection work, and it is uncomfortable.

To redact a DSAR bundle with a typical free online PDF tool, you must first upload it. That bundle contains the personal data of the requester and every third party whose data you were about to remove. You have transmitted all of it to a processor you have not assessed, under terms you have not negotiated, possibly outside your jurisdiction.

The questions that follow are not comfortable ones for a compliance function:

• Is that vendor a processor under Article 28, and where is the data processing agreement?
• Was this an international transfer, and on what safeguard?
• Does your Record of Processing Activities list this tool?
• If that vendor is breached, are you notifying every third party in the bundle?

Under Article 83(5), infringements of data subject rights and of the basic principles of processing sit in the higher penalty tier — up to €20 million or 4% of total worldwide annual turnover, whichever is higher. Creating a transfer you cannot document, in the course of servicing an access request, is a genuinely poor place to end up.

A Defensible DSAR Redaction Workflow

"Defensible" here means: if the ICO or a supervisory authority asks how you produced the response, you can describe every step and none of them involves a system you cannot account for.

1. Assemble the bundle and freeze it. Work from a fixed copy so what you disclose matches what you logged.
2. Keep the unredacted original. You may need to justify a specific redaction later. Store it under your normal retention controls; never send it.
3. Redact on a machine you control. If the tool requires an upload, the tool is part of your processing chain. RedactLocal runs entirely inside your browser tab, so the bundle never reaches a server.
4. Scan for structured identifiers first. Email addresses, phone numbers, national ID and account numbers follow predictable formats and should be caught mechanically rather than by eye.
5. Review every match by hand. Confirm each one in context. Some third-party data is disclosable; some innocuous-looking text is identifying. Only you know which.
6. Read the bundle for contextual identifiers. The pass that no tool can do for you: job titles, team sizes, distinctive incidents.
7. Flatten the output. Export so the redacted text is destroyed, not covered.
8. Verify before sending. Run pdftotext over the finished file, or search it for a name you know you removed. If it appears, do not send it.
9. Log your reasoning. Record which exemptions you relied on and why. This is the artefact that makes the response defensible months later.

Where RedactLocal Fits

RedactLocal was built for steps three through eight. It is a PDF redactor that runs entirely in the browser — there is no upload endpoint, because there is no backend that accepts files.

Nothing leaves the tab

Your bundle is read into memory by the browser's own file API, parsed and rendered locally, and exported by your browser's download mechanism. You can verify this in about ten seconds: open the tool, disconnect from the internet, and redact a document. It keeps working, because there is nowhere for the file to go.

Structured identifiers found, never auto-removed

The scanner sweeps the bundle for email addresses, phone numbers, national ID formats, tax IDs, IBANs, card numbers and account references. Every hit is presented with the line of text surrounding it, and nothing is blacked out until you confirm it. That review step is deliberate — a tool that silently over-redacts produces a response that is unusable, and one that silently under-redacts produces a breach.

Redactions are destroyed, then verified

On export, every page is rasterized and the redaction boxes are burned into the pixels. The new PDF is assembled from images alone, so there is no text layer left to recover. The file is then re-opened and inspected before the download appears, reporting the flattened page count alongside the number of selectable characters, text operators, font objects and annotations it found. On a correct export those counts are zero.

Whole bundles at once

DSAR responses are rarely one document. You can queue the bundle, scan every file in one pass, work through them individually, and export the set as a single archive. Each redaction can carry a stamp — PRIVACY ACT, PII REDACTED, or your own reference code — burned into the black box so the reader knows the basis on which material was withheld.

What This Does Not Do

Two limits you should know before relying on any of the above.

Scanned documents are not scanned for patterns. The identifier search reads a PDF's text layer. If a document is an image-only scan — a photographed sick note, a faxed form — there is no text to match against. RedactLocal reports those pages by number and tells you to review them by eye rather than reporting them as clean. Manual redaction and flattened export work normally on them.

The site loads page analytics. Loading redactlocal.org records a page view, as most websites do. It has no access to your documents, which never leave your tab's memory. We state this plainly because a tool asking you to trust its handling of data you cannot see should be candid about the data you can.