Legal Redaction Workflow

Is Your Acrobat Redaction Workflow Actually Safe?

Most litigation paralegals use Acrobat to redact documents before filing. Most don't realise there are gaps in the workflow, and when those gaps matter, the consequences land on the filer.

If you've been redacting court filings using Adobe Acrobat, you're in good company. It's the default tool at most firms, and for most tasks, Acrobat is perfectly fine.

But redaction isn't most tasks.

Redacting a document for court filing is one of the few things you do where being almost right is the same as being completely wrong. A client's Social Security number that's visually hidden but technically recoverable isn't protected. It's exposed. And under FRCP 5.2, the responsibility for that falls on the filer, not the software vendor, not the clerk's office, not the attorney.

This post explains exactly how Acrobat redaction can fail, why it keeps happening even to careful people, and what secure redaction actually looks like.


The two very different things Acrobat calls "redaction"

Here's the root of the problem. Adobe Acrobat has two separate workflows that both look like redaction but produce completely different results.

Marking for redaction places a black rectangle over text as an annotation. It looks redacted on screen. It is not redacted. The original text is still fully present in the document underneath the visual overlay. Anyone who opens the file in a PDF editor, selects that black rectangle, and deletes it will see the original text immediately.

Applying redaction actually removes the underlying text from the document and replaces it with a permanent black mark. This is the step that makes redaction real.

The problem is that these two steps are separated in Acrobat's workflow, and it is entirely possible, and surprisingly easy, to save and file a document after the first step without completing the second. The document looks correct. The text is not gone.

Why This Keeps Happening

In Acrobat, the file can look finished after visual black boxes are placed. The secure step is separate, so deadline pressure turns a workflow gap into a filing risk.

The US District Court for the Northern District of Alabama explicitly warns about this on their guidance page for e-filers: graphic tools that black out or cover text "can still be removed by anyone to reveal the text underneath." They demonstrate it with an interactive example on their own website.

The Manafort filing: what a real failure looks like

In 2019, attorneys for Paul Manafort filed a court document with what appeared to be properly redacted sections. The redactions were applied using black boxes, but the underlying text layer had not been removed. Anyone who copied the blacked-out sections and pasted them into a text editor could read the original content.

Within hours of the filing becoming public, journalists had done exactly that.

This wasn't a technical edge case. It was a straightforward failure of the most common redaction workflow used by legal professionals every day. Acrobat's annotation layer covered the text visually. The text was never deleted.

The sanitisation step most people skip

Even when redactions are applied correctly, PDFs can still contain hidden information: metadata, comments, form data, hidden layers, that you may not want to disclose. That's why sanitising matters, and why skipping it is a risk even when the redaction itself was done right.

Acrobat has a separate "Sanitize Document" function designed to remove hidden data: metadata, incremental save history, form field values, comments, and other elements that persist in the PDF structure after redaction. Adobe's own guidance explicitly recommends running this step after applying redactions.

Most people don't run it. It's a separate step, it's not in the main redaction workflow, and nothing in the interface warns you when you skip it.

Think of it this way: Adobe keeps a "memory" of your edits so you can undo them. If you don't clear that memory through sanitisation, a technically capable person can effectively undo your redaction work after the document has been filed. The black boxes look correct. The history is still there.

What can survive without sanitisation
  • Document metadata - author name, creation date, software used, revision history
  • Incremental saves - PDFs can store edit history internally; in workflows where sanitisation is skipped, prior versions of the document may persist within the file structure and remain accessible with the right tools
  • Form field cached values - auto-fill data that persists even after the visible content is removed
  • Comments and annotations - review notes that may reference the content being redacted

Many SME firms don't have a compliant redaction tool at all

Before any of the workflow issues above become relevant, there's a more fundamental question: which version of Acrobat does your firm actually run?

Acrobat Standard does not include a dedicated redaction tool. Not a limited one, none. If your firm is on Standard licences, the Apply Redactions function doesn't exist. Any black box your team is placing over sensitive text is an annotation layer sitting on top of the original content. The text underneath is intact and recoverable.

Small and mid-sized firms are significantly more likely to run Standard licences. It's cheaper, and redaction often isn't mentioned in the purchase decision. The assumption is that Acrobat is Acrobat. It isn't.

Before you read any further: confirm which version your firm is licensed for. If it's Standard, your current redaction workflow is annotation-based regardless of how careful your team is being.

Acrobat Pro does include proper redaction, and when used correctly with the sanitise step included, it produces genuinely secure output. The problem is that "used correctly" requires knowing about the two-step workflow, remembering to run sanitisation, and doing this consistently under deadline pressure across every document that gets filed.

Human error in a multi-step manual process is not a flaw in the person. It's a flaw in the process.

What FRCP 5.2 actually requires

Federal Rule of Civil Procedure 5.2 mandates that parties redact specific categories of personal identifying information from all documents filed in federal civil proceedings:

The rule applies to all filings: pleadings, motions, exhibits, transcripts, and discovery materials. And critically, the clerk's office will not review your documents for compliance. If your redaction fails and the information becomes publicly accessible on the electronic docket, that's on the filer.

Courts have sanctioned attorneys for redaction failures. Documents have been struck and required refiling. In cases involving sensitive client data, the reputational consequences extend well beyond the procedural ones.

The approach that eliminates PDF-layer recovery risk entirely

The failures above share a common root: they all involve modifying an existing PDF. The original document structure is preserved, and sensitive data can survive in layers, metadata, or history that the redaction process didn't reach.

There is one approach that eliminates this entire class of structural risk: stop modifying the existing PDF and instead destroy it entirely, rendering each page to an image and assembling a completely new PDF from those images. The original document ceases to exist. There is no text layer, no metadata, no incremental history. There is nothing in the output file except pixels.

This is the approach the NSA's "Redacting with Confidence" guidance recommends for sensitive documents. It removes the structural attack surface entirely, because it doesn't try to clean the existing document, it replaces it. Acrobat Pro with sanitisation, used correctly, is genuinely secure; the problem is that "used correctly" is doing a lot of work in that sentence.

The tradeoff is that the output PDF is image-based rather than text-based, meaning it isn't searchable. For a court filing where the whole point is that the redacted information should be permanently unrecoverable, that's not a tradeoff, it's the correct outcome. If your specific court requires a searchable PDF, OCR can be applied as a separate step after redaction is complete.

Process Design Principle

Secure redaction should be correct by default. A workflow that depends on remembering multiple hidden steps under filing deadlines will eventually fail.

What this means for your workflow

If you're currently using Acrobat for court filing redaction, the questions worth asking are:

If the answer to any of those is uncertain, your current redaction workflow has risk in it. Not theoretical risk, the kind of risk that produced the Manafort filing failure and dozens of court filing errors that have led to sanctions and refilings.

The good news is that the problem is solvable. Secure redaction doesn't require a complicated workflow or enterprise software. It requires a tool that handles the process correctly by design, so that human error in a multi-step process isn't what stands between your client's data and the public docket.

Need a court-filing redaction workflow that removes PDF-layer recovery risk?

PromptSafe PDF renders each page to an image before assembling the output document, permanently destroying the original PDF structure. Nothing is uploaded to a server.