BASALT · JOURNAL

Building a privilege log from the redactions you already made

2026-08-06 · privilege log

A privilege log lists the material you withheld or redacted and the basis for withholding it. In most firms it is built twice: once implicitly, when a reviewer decides a passage is privileged and marks it, and again explicitly, days later, when someone reconstructs those decisions into a spreadsheet.

The second pass is where the log stops matching the production. Every redaction already encodes a decision, a location, and, if you asked for it, a reason. The log should fall out of that data rather than being rebuilt from memory.

What a privilege log has to contain

Requirements vary by jurisdiction, by court, and by whatever the parties agreed in a protocol, so treat this as the common core rather than a rule.

A document-by-document log typically carries, per entry: a document identifier, usually the Bates range or a control number; the date of the document; the author; the recipients, with cc and bcc distinguished; the document type, such as email, memorandum, or attachment; a description sufficient to let the other side assess the claim without disclosing the privileged content itself; the basis asserted; and whether the document was withheld in full or produced with redactions.

The description is the hard column and the only one a tool cannot generate. "Email reflecting legal advice regarding contract negotiation" tells the receiving party what kind of claim is being made. "Privileged" tells them nothing and invites a challenge. It has to be specific about the nature of the communication and silent about its substance.

Categorical logging, where similar documents are grouped and described as a category, is permitted in some contexts and by agreement in others. It changes the granularity of the entries, not the columns.

Redacted material belongs in the log too

A common gap: firms log documents withheld in full and treat redacted-but-produced documents as self-explaining, because the receiving party can see the black marks.

That is usually wrong, and it is certainly the weaker position. The receiving party can see that something was removed; they cannot see on what basis. If the protocol or the court requires the basis for each withholding, a redaction is a withholding. Logging redactions also forces internal consistency, because it makes over-redaction visible: a document with eleven marks and no coherent basis will not survive being written down.

Redacted entries need one extra column that fully-withheld entries do not: the specific pages, or page-and-region, where the redactions appear. The Bates number is what makes that reference possible, which is why the endorsement has to happen before the marking. See Bates numbering on a Mac for the mechanics and the law firm workflow for the ordering.

Capture the reason at the moment of the mark

This is the whole technique. If a reviewer selects a passage and immediately assigns a basis from a fixed list, the log's hardest structural work is already done when review ends.

A workable vocabulary is small:

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

Fix it at the start of the matter. Reviewers who can invent codes will invent codes, and reconciling twelve improvised labels into five log bases at the end of a production is exactly the manual step this approach exists to remove.

There is a second benefit that shows up in review quality. Requiring a basis before the mark is committed makes the reviewer articulate the claim. A passage that does not fit any code is usually a passage that should not be redacted, and the friction catches it at the point of decision rather than at the point of a motion to compel.

From marks to rows

The transformation is mechanical once each mark carries a page and a reason.

Group the marks by document. Within a document, group by basis. For each group, emit one row: the document's Bates range, the pages within that range carrying marks of this basis, the basis itself, and the count of marks. That gives you a complete skeleton of the log with every machine-knowable field populated and every human-knowable field left blank.

The blank columns are author, date, recipients, document type, and description. A person fills those in from the source document, and here is the part that trips people up: they must come from the source, not from the produced PDF. The produced file has had its metadata stripped, deliberately, because leaving an Info dictionary or XMP packet naming the custodian and the original file path in a production is its own disclosure. If your log-building process harvests author and date from the produced PDF, either your log is empty or your metadata stripping failed. Both are worth knowing about. Removing metadata from a PDF on a Mac covers what is in there.

Export the skeleton to CSV or XLSX so the rest of the work happens in a spreadsheet, where paralegals are fast and where sorting and filtering are free.

The consistency checks that matter

Once the log is generated from the marks rather than reconstructed alongside them, three checks become possible, and all three catch real errors.

Every marked page appears in the log. Trivially true if the log was generated from the marks, which is the point. If you are reconciling a hand-built log against a production, this check finds the pages someone forgot.

Every logged page has marks. Catches entries carried over from a previous draft, or from a document that was ultimately produced in full.

Every reason code maps to exactly one asserted basis. Catches vocabulary drift, especially across multiple reviewers or across weeks of review.

Add a fourth if you produce in volumes: the Bates ranges in the log fall inside the ranges actually produced. A log entry citing a number that was never issued is a correspondence-generating error, and it happens whenever a document is pulled from a production after the log was drafted.

Keep the log and the file in sync after changes

Productions change. A document gets clawed back, a redaction is challenged and lifted, a new custodian's files arrive as a supplemental volume.

The rule that keeps this manageable: the marks are the source of truth, and the log is regenerated, never hand-patched. Editing a spreadsheet row to reflect a lifted redaction, without changing the underlying marks, creates a document set and a log that disagree, and the disagreement is invisible until someone checks. Lift the mark, re-export, re-verify, and re-produce. It is a few minutes and it keeps the two artifacts derived from one state.

Record hashes of each produced file alongside the log revision it corresponds to. When a question arises months later about which version of a document a log entry describes, the hash answers it. That habit and the rest of the pre-production checks are collected in the redaction checklist before filing.