BASALT · JOURNAL

A redaction workflow for law firms that survives review

2026-08-06 · pdf redaction for law firms

Most redaction incidents at law firms are not engine failures. The tool removed what it was told to remove. The failure was upstream or downstream: the wrong copy went out, a page was skipped, marks were placed but never applied, or the privilege log did not match the file that was produced.

A workflow fixes those. This is a sequence that holds up under review, with the reasoning for each step, aimed at a production of a few hundred to a few thousand pages handled inside a firm rather than by a vendor.

Establish one source set and hash it

Before anything is marked, decide which set of files is the production source and record a hash of each one. shasum -a 256 over the intake directory, saved as a manifest, takes seconds.

This exists to answer two questions later: was the file we produced derived from the file we collected, and did the source change during review. It also removes the most common catastrophic failure, which is producing the pre-redaction copy because two files with similar names sat in the same folder. If the produced file's provenance can be traced by hash back to a source in the manifest, that mistake becomes visible instead of silent.

Keep the source set read-only. Every derived artifact goes to a separate directory.

Normalize before you mark, not after

Two normalization steps belong before review, because doing them afterward invalidates work already done.

OCR any scanned or image-only pages. A page with no text layer cannot be searched, which means a keyword sweep for privileged terms will silently miss it. OCR first, then review, then redact both the image and the text layer together. Marking an un-OCR'd page and adding OCR later produces a searchable text layer generated from the pre-redaction image if the OCR was run against the wrong artifact.

Fix page order, orientation, and splits. Reordering or splitting after marks are placed risks marks landing on the wrong page. Do the organizing pass first and freeze the pagination.

Endorse Bates numbers before redacting

Bates numbers are sequential unique identifiers applied to every page of a production so that any page can be cited unambiguously. Apply them before redaction, not after.

The reason is the privilege log. Every entry in the log has to point at a Bates range, and every redaction has to be locatable by the receiving party using the same reference. If you redact first and endorse second, the marks and the numbers are created in separate passes and nothing in your process guarantees they agree. If you endorse first, every mark you place is placed on a page that already has its permanent identifier, and the log can be generated directly from the marks.

Endorse into the margin, not over content, and keep the number in the page content stream rather than as an annotation, so it cannot be deleted downstream. The mechanics, including the page geometry traps, are in Bates numbering on a Mac.

Confidentiality designations under a protective order are a separate endorsement from the Bates number. Keep them separate so a change in designation does not force a renumber.

Mark with reason codes, every time

Every mark should carry a reason at the moment it is placed. A small controlled vocabulary is enough for most productions:

• Attorney-client privilege
• Work product
• Personally identifiable information
• Protected health information
• Confidential under protective order

Two things follow from this discipline. First, a reviewer who has to name the basis before moving on catches their own over-redaction, because "I do not have a code for this" usually means it should not be redacted. Second, the privilege log becomes a byproduct of the review rather than a second, separately reconstructed document. That is the whole argument in building a privilege log from the redactions you already made.

Set the vocabulary once at the start of the matter and do not let reviewers improvise new codes. Mapping ad hoc codes to log bases at the end is where inconsistency enters.

Redact by removal, and know what your tool does

Everything above is process. This step is the one place where the tool's internals decide whether the production is safe.

A correct redaction excises the glyph runs that intersect the mark from the page content stream, re-emits the surviving text in place so the page still renders correctly, destroys and re-encodes the pixels of any image the mark crosses, removes the corresponding runs from any invisible OCR text layer, and strips metadata, XMP packets, attachments, hidden optional content groups, and stale page thumbnails. Then it writes the whole document as a single generation, so there is no earlier revision left in the bytes.

If your tool draws a rectangle, the text is still in the file and copy-pastes out. If your tool saves incrementally, the pre-redaction state is recoverable by parsing the earlier revision. Both failures produce a file that looks completely correct on screen. How redactions fail walks through the mechanisms.

Ask your vendor or your tool one question: after redaction, does the removed text exist anywhere in the output bytes. There is a correct answer and it is short.

Verify the artifact you are about to send

The verification must run on the produced file, not on the editor state that produced it.

The minimum pass: open the output with a parser that did not write it, extract all text, and search for the strings that were redacted. Export the images and look at them. Dump the objects uncompressed and read the annotation values, form field values, layer names, and metadata. Confirm the Bates sequence is continuous with no gaps or duplicates across the volume.

Then hash the produced file and record the hash in the production log next to the source hash. That pairing is your proof of what left the building. If a dispute arises later about what was produced, a recorded hash settles it without argument. Verifying a PDF redaction has the commands; the checklist before filing has the shorter version for court submissions.

Two people, two roles

The reviewer who places marks should not be the person who signs off on the production. Not because reviewers are unreliable, but because the two tasks look for different things. The reviewer asks "should this be redacted." The signer asks "is the file correct": right document set, right Bates range, log matches marks, verification passed, hash recorded.

For small productions the second role takes ten minutes. It catches the wrong-file-sent failure, which no engine can prevent.

Keep the working copies out of reach

Derived artifacts accumulate: the OCR'd intermediate, the endorsed copy, the marked working file, the produced file. Only the last one leaves.

Put produced files in their own directory, named by volume, and do not keep anything else there. Attach files to outbound mail from that directory only. Every "we sent the unredacted version" incident is a file-picker error, and the cheapest fix is a directory where the wrong file cannot be selected because it is not there.

Finally, consider where the documents are processed. A privileged document uploaded to a general-purpose web converter has been disclosed to a third party regardless of that service's policies, and the copy you upload is by definition the unredacted one. Local processing is the default posture for privileged material, and cloud PDF tools covers why.