In January 2019, lawyers for Paul Manafort filed a court document with sensitive passages blacked out. Journalists copied the text, pasted it into a plain document, and read every word underneath within minutes. The filing was promptly pulled from public access and replaced.

Nothing exotic happened there. No forensic tooling, no clever exploit. Copy and paste. That is the uncomfortable center of document redaction: the failures are almost never sophisticated, and they are almost always public.

What are the best practices for document redaction in government agencies?

Use a tool that removes data from the document’s content layer rather than drawing over it, strip metadata and hidden content as a separate step, verify every file by extracting its text before release, and keep a human review in the loop. Then keep the unredacted original somewhere separate, because true redaction is permanent.

Why visual redaction keeps failing

A PDF is not a picture of a page. It is a container holding text, images, fonts, metadata, and often more besides. When someone draws a black rectangle over a paragraph, they have added an object to that container. They have not removed the paragraph.

The text stays exactly where it was, addressable and extractable. Which is why the copy-and-paste test works and why it has kept working for two decades.

This is not new guidance. In 2005 the NSA published “Redacting with Confidence: How to Safely Publish Sanitized Reports Converted from Word to PDF,” warning that blacking out text in Word and converting to PDF can be reversed and that sensitive metadata rides along into the PDF. Adobe published a technical note on the same problem the following year.

The warnings are old. The failures are current and recurring.

Seven practices that actually hold

1. Use true redaction tools, not annotation tools. Most PDF software ships both. The markup tools draw shapes. The redaction tools remove content. They sit next to each other in the interface and they do completely different things.
2. Treat metadata as a separate job. Author names, organization, software versions, revision history, and comments live outside the visible page. A clean-looking document can carry all of it. Sanitize as a distinct step and confirm it happened.
3. Check the places the page does not show you. Embedded thumbnails, attached source files, an OCR text layer behind a scanned image, form field values, bookmarks, and hidden spreadsheet rows can each hold a copy of what you just removed.
4. Run the extraction test on the final file. Select all, copy, paste into a plain text editor. If a redacted phrase appears, the redaction failed. Do this on the file you are about to release, not on a draft.
5. Keep a human in the review. Automated detection is good at patterned data like Social Security Numbers, dates, and email addresses. It is poor at implied disclosure, where no single field is sensitive per se but the combination identifies someone.
6. Separate the two questions. “Is it removed?” and “Did we remove the right things?” are different reviews. A file can pass the extraction test perfectly and still be a disclosure, because someone missed a passage entirely.
7. Preserve the original, separately and securely. Real redaction cannot be undone. Agencies that skip this step lose access to their own records.

The failure mode nobody tests for

Everything above addresses information that is still in the file. The harder problem is information that was never in the file to begin with.

Consider a dataset released with names removed but job title, office location, and hire date intact. No individual field identifies anyone. Together, in a small enough office, they identify exactly one person. No redaction tool flags this, because nothing sensitive is technically present.

This is where the human review earns its cost, and it is the part most redaction workflows skip because it is slower and harder to put on a checklist. Someone has to ask what a motivated reader could reconstruct, not just what the document says.

Building this into an agency workflow

The practices above only hold if they survive a busy week. A few structural points:

• Make the verification step mandatory and recorded. If verification depends on someone remembering, it will be skipped under deadline pressure. Log who verified each release.
• Separate the redactor from the verifier. The person who did the work is the worst person to check it, for the same reason writers miss their own typos.
• Standardize the tool. Redaction failures cluster around ad hoc methods, where someone used whatever software was open.
• Train on the failure, not the feature. Show people an actual failed redaction and let them recover the text themselves. The lesson lands in a way that a procedure document does not.
• Review the whole chain before public posting. Agencies release documents to requesters and to the open web through different paths. The web path usually gets less scrutiny and more readers.
  

Why volume changes the problem

A single document is a careful task. Ten thousand documents is a process, and processes fail differently.

At volume, the risk shifts from “someone used the wrong tool” to “the right tool was applied inconsistently.” A batch with mixed file types, scanned pages beside born-digital ones, or a template change halfway through will produce uneven results even when every individual step was correct.

This is the case for automation with a verification layer rather than automation alone. Automated processing gives consistency across the batch. Programmatic extraction testing gives proof. Human review gives judgment on the cases that pattern matching cannot reach. Removing any one of the three reintroduces the failure mode the other two were covering.

FAQ

Does printing and rescanning a document make redaction safe?

It removes the text layer, which handles the copy-and-paste failure. It also destroys searchability and accessibility, and it does nothing about whether you redacted the right passages. Modern redaction tools achieve the same removal without the loss.

Does flattening a PDF count as redaction?

No. Flattening merges layers for display. Depending on the tool, underlying text may survive. Flattening is a formatting operation, not a removal operation.

Who should verify a redaction?

Someone other than the person who performed it, using the released file rather than the working copy, with the result recorded.

Can automated redaction be trusted for PII?

For patterned identifiers, it performs well and more consistently than people do at volume. For contextual or implied disclosure, it should be treated as a first pass rather than a final answer.

Redaction failures are not a technology problem. The tools have been capable for years and the guidance has been public for longer. They are a process problem, and the fix is unglamorous: use tools that remove rather than cover, verify every file before it leaves, and let someone who did not do the work check it.