GDPR Document Redaction: A Practical Guide

By the SladdPDF team · Published August 23, 2026 · Updated August 23, 2026

GDPR redaction means permanently removing personal data from a document before you share, publish or release it, so that only what the recipient is entitled to see remains. It is how you deliver data minimisation on a real file, and how you answer a subject access request without exposing third parties. Done thoroughly it can take a document outside the GDPR altogether — but only if the result is genuinely anonymous under Recital 26, not merely covered by a black rectangle.

What is GDPR redaction?

GDPR redaction is the practice of permanently removing personal data from a document before it leaves your control. The word appears nowhere in the Regulation — “redaction” is not a legal term in EU data protection law. It is simply the practical way to meet obligations the Regulation does impose: process no more personal data than the purpose requires, and do not damage the rights of people who never asked for anything.

Three situations account for most redaction work:

• Disclosure to a third party — a contract sent to an auditor, an incident report handed to an insurer, an HR file passed to external counsel.
• Publication — tender documents, meeting papers, public registers: anything posted to a website, where the audience is everyone, forever.
• Subject access — giving people the copy of their own data they are entitled to, when it sits in files full of other people.

Different legal drivers, one shared technical requirement: what you decided to withhold must actually be gone from the file you hand over. That is where most organisations fail.

Why data minimisation makes redaction a duty

Article 5(1)(c) requires that personal data be “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed” — the data minimisation principle. Sharing a document is itself processing, so the principle applies to the copy you send, not just the data you collected.

That reframes the question every time a file goes out. It is not “may I send this document?” but “which parts does this recipient actually need?” The answer is almost never “all of it”: a buyer in due diligence needs to see that employment contracts exist and on what terms, not every employee’s national identity number and home address.

Minimisation also settles internal disagreements, because it does not require anyone to claim harm: you need not show that disclosing a colleague’s phone number would hurt them, only that the number is not necessary. Keep a short record of what you removed and why.

How do you redact a subject access response?

You give the requester their own personal data and redact other people’s, because Article 15(4) states that “the right to obtain a copy referred to in paragraph 3 shall not adversely affect the rights and freedoms of others.” Recital 63 explains that those rights and freedoms include trade secrets and intellectual property, in particular the copyright protecting software — and, in practice, the privacy of everyone else in the file.

What that limitation is not is a reason to refuse. The European Data Protection Board’s Guidelines 01/2022 on the right of access take the position that where compliance would adversely affect others, the controller should first try to reconcile the competing rights — for example by removing or redacting the third-party information — and that the result should not be a refusal to provide all information to the data subject.

In practice that means removing the names, contact details and personal circumstances of individuals who appear incidentally — colleagues copied on an email, other customers in a shared spreadsheet, a neighbour named in a complaint — plus anything that would expose a confidential source. What stays in is the requester’s own data, including unflattering opinions about them.

The hard cases are mixed data: a manager’s note about the requester is personal data of both people at once. There is no mechanical rule, only a balancing decision — can the substance be released while the author’s identity is withheld? Document the reasoning.

Watch the format, too. Access responses are assembled from exports — email archives converted to PDF, spreadsheets pulled from an HR system — which carry material invisible on the page: comments, tracked changes, hidden rows, metadata.

Anonymisation or pseudonymisation?

Truly anonymous data falls outside the GDPR entirely; pseudonymised data does not. Recital 26 is explicit: the principles of data protection “should not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable.”

Recital 26 also supplies the test: account must be taken of “all the means reasonably likely to be used” to identify the person, weighing cost, time and available technology. That is a realistic-adversary standard rather than proof of impossibility — but for a document it is a high bar.

Pseudonymisation is the weaker cousin. Article 4(5) defines it as processing personal data so that they “can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures” preventing attribution. Recital 26 then says the quiet part out loud: pseudonymised data that could be attributed to someone using additional information counts as information on an identifiable person. It is personal data, and the whole Regulation applies.

In EDPS v SRB (Case C-413/23 P, 4 September 2025) the Court of Justice added nuance: pseudonymised data is not automatically personal data for every party — it depends on whether that recipient can reasonably re-identify individuals, judged on the technical, organisational and legal circumstances. Anonymity therefore depends on who receives the document and what they realistically know; open publication has the least forgiving audience of all.

Which is why removing names is rarely enough. “The warehouse supervisor dismissed on 4 March after the incident in Bergen” names nobody and identifies one person to any colleague. Catching only direct identifiers yields pseudonymised data at best.

Why an overlay is not anonymisation

A black rectangle drawn over a name in a PDF is a graphic sitting on top of an intact text layer — the name is still in the file, recoverable with select all, copy, paste. Nothing has been anonymised or minimised. You have disclosed the personal data while believing you withheld it: a breach with a false sense of security attached.

The failure mode is not hypothetical, and not confined to PDFs. In October 2024 the UK Information Commissioner’s Office fined the Police Service of Northern Ireland £750,000 under the UK GDPR after a spreadsheet published in response to a freedom of information request still contained the original source worksheet: surname, initials, rank, grade, department and location of post for all 9,483 officers and staff. The visible worksheet tabs had been deleted; the underlying data had not, and quality assurance missed it. The ICO said the penalty would have been £5.6 million had it not applied its public sector approach.

Only two techniques actually remove content from a PDF. True redaction deletes the underlying text objects instead of covering them. Rasterisation converts each page to a flat image after the marks are applied, so no text layer survives — blunt (the output is no longer searchable) but verifiable.

Neither is complete alone. A PDF also carries metadata — title, author, creating software, hidden tags — in fields no page displays, and those leak names routinely, so removing the metadata belongs in the same pass. Then verify: open the export, select all, copy, paste into a text editor and search for the redacted names. If any appear, the file is not ready to leave.

Does an online redaction tool become your processor?

Yes — uploading a document containing personal data to an online redaction service makes that vendor a processor acting on your behalf, which brings Article 28 into play. Article 28(3) requires that processing by a processor “shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller” and that sets out the subject matter and duration of the processing, its nature and purpose, the type of personal data and the categories of data subjects, and the obligations and rights of the controller.

The contract must be in writing, including electronic form, and cover a defined set of terms: the processor acts only on documented instructions, imposes confidentiality on its personnel, assists with data subject rights, deletes or returns the data when the service ends, and allows audits. A free web tool with a drag-and-drop box offers none of this — clicking “I accept the terms” is not an Article 28 agreement.

Before uploading to any hosted tool, answer three questions:

• Is a data processing agreement actually offered, with the Article 28(3) terms — or only a consumer terms-of-service page?
• Where is the file stored and processed, for how long, and can you get confirmation of deletion?
• Who are the sub-processors, and what is retained for “service improvement” or model training?

There is a simpler route: never create the processing relationship. A redaction tool that runs inside the browser never receives the document — no transfer, no processor, no DPA, and no third-party copy to appear in someone else’s breach notification. That is the architectural case for no-upload PDF tools.

A GDPR redaction workflow

A defensible GDPR redaction process has seven steps, none of which involves uploading the document to a stranger:

1. Fix the purpose and the recipient first — you cannot decide what is necessary until you know what for.
2. Work on a copy, so you can show what you started from.
3. Decide the standard. A controlled disclosure containing personal data is a normal, lawful outcome; genuine anonymity is a far higher bar.
4. Mark every instance, then do a second pass. Personal data hides in headers, footers, signature blocks, table cells and appendices.
5. Look past the visible page: comments, tracked changes, hidden rows, embedded attachments, and the invisible OCR layer on scans.
6. Export with a method that destroys data rather than covering it, and strip the metadata in the same pass.
7. Verify, then record the decision. Copy-paste test the export, and note what you removed and why.

You can run the whole workflow in SladdPDF, a free browser-based PDF redaction tool. It processes files locally with JavaScript and WebAssembly — the PDF is never uploaded, and it keeps working offline once the page has loaded. Secure mode rasterises each page on export, destroying the underlying text, layers and hidden objects; metadata removal is a checkbox in the same dialogue. The step-by-step guide covers the mechanics.

Two honest caveats. The free version exports at standard resolution; print-quality 300 DPI export needs a Pro licence — there is no page limit. And fast mode draws vector overlays rather than flattening the page — quicker, but the tool warns that underlying text may in some cases still be extractable, so secure mode is the right choice for personal data. For completeness, sladdpdf.com uses Vercel Web Analytics for aggregate, cookieless visit statistics; the accurate claim is the narrower one — your PDF never leaves your device.

Redaction is a control, not a compliance certificate — but when a file goes out with someone else’s name on it, careful GDPR redaction is the difference between a routine release and a breach notification.

This article is general guidance, not legal advice.