Privilege is a top concern in every kind and size of case. Inadvertent disclosure of privileged information can lead to privilege waiver. In the worst case scenario, the judge could even find subject matter waiver and order disclosure of related documents as well.
Most producing parties would prefer to treat their privileged material like a state secret: neither confirming nor denying its existence. However, the courts have recognized the competing interest of the requesting party to know what’s being withheld and why.
Federal Rule of Civil Procedure 26(b)(5) and corollary state rules require producing parties to 1) make an express claim of privilege and 2) disclose information sufficient to assess the claim. The privilege log is the customary means of complying with this requirement.
Privilege logs must be comprehensive and accurate. The log entries must provide enough detail to demonstrate the basis of the claim without disclosing the substance of the privileged communication or work product.
Accurate and cost-effective logs can be achieved with early planning, database optimization, and good workflows. Follow these seven steps to build your best privilege log ever.
1. Choose the best privilege log type for your case.
The first step is selecting the optimal privilege log type.
a. Standard – The standard approach was developed from the traditional privilege log format of the paper discovery era. Metadata is used for objective fields, but manually cleaned up after export to Excel. Reviewers code the subject-matter descriptions and privilege type. The standard log format is universally accepted by courts.
b. Automated – Automated logs that leave metadata as-is after export are becoming more common. Some litigants go a step further and agree to provide subject-matter descriptions only upon request for specific documents. Automated logs offer real cost savings for datasets with a large number of privileged documents.
c. Category – The federal rules provide a little-used option to describe document groups by category instead of document-by-document entries. This can be an economical choice for individual clients and small companies, especially if the bulk of relevant privileged documents relates to the lawsuit.
2. Check the local rules.
Remember to check the local rules. While many courts leave the issue to the parties, some have significant privilege log requirements. For example, New York state courts strongly promote category logs through local rules. By contrast, the Seventh Circuit’s influential Electronic Discovery Pilot Program endorses automated logs “providing as much objective metadata as is reasonably available” along with the privilege being asserted.
In a more minor key, my home court, the Southern District of Indiana’s Uniform Case Management Plan, has a specific privilege log requirement in the clawback provision. The Western District of Washington’s Model Agreement re: Discovery of ESI is a good resource if you’re drafting a discovery plan from scratch.
3. Negotiate favorable terms in the discovery plan.
Negotiating privilege log issues during the initial meet and confer avoids wasteful discovery disputes and log do-overs. Along with log type, key topics for discussion include:
a. Email threads – Ideally, you can log each email thread as a single entry. Populate the entry with the metadata from the top email; then, log any additional thread participants in a separate field.
b. Partially privileged documents – You should indicate on the log when a document has been produced in redacted form. In Relativity, this can be done by including the “Production::Has Redactions” field.
c. Log timing – Consider producing a master privilege log after you’ve completed principal production. Rolling logs are administratively inefficient. Worse, they often must be corrected based on newly discovered information.
d. Name legend – A name legend is a list of author, sender, and recipient names with their affiliation and status (e.g., lawyer, paralegal, client). Exchanging this information with the logs is helpful for both sides.
4. Plan for name normalization.
Normalization refers to writing a person’s name the same way each time it appears on the log. For example, you would globally substitute “Smith, Jane” for variants like:
- jsmith@acmecompany.com
- Jane Smith
- janey@acmemail.com
- J Smith
- Jane R. Smith
Normalizing names is optional but highly recommended. It forestalls questions and challenges based on name confusion, and gives your log a more professional appearance (not a bad thing if it winds up on the judge’s desk).
Relativity’s new name normalization feature works for privilege log normalization, among its other benefits. QPrivAlert by QDiscovery supports name normalization by identifying name variants. QPrivAlert, which is fully integrated into our workflow using Relativity Processing, enables early identification of potentially privileged communications, and expedites privilege review by recognizing communication patterns. Excel plug-ins can also be used for normalization outside the database.
5. Write subject-matter descriptions as you review.
As a new associate, I was taught to review first and write subject-matter descriptions at the end of a project. With data volumes exploding year over year, I soon adopted the practice of writing descriptions as I went. Reviewing each privileged document twice—first to make the privilege call and a second time to write a description—has become an unaffordable luxury.
Technology can speed the writing process. Anyone who’s ever looked at a privilege log knows there’s enormous repetition in subject-matter descriptions. You can minimize manual data entry by creating a custom database field with a drop-down menu of common descriptions and/or starting phrases. This has the added benefit of reducing inconsistencies in descriptions, always a prime target for objections.
6. Use privilege-specific QC strategies.
Three essential privilege-specific QC strategies are:
a. Verify split calls in email threads and families – Email threading has been a boon for privilege review by eliminating inconsistent tagging by multiple reviewers. (If you aren’t already using email threading on every case, it’s time to start.) However, it’s still good practice to QC split calls on email threads in addition to family groups. Logging documents within a family as separate entries makes it easier to deal with split calls on the log.
b. Check redacted documents – Are there redacted documents that aren’t tagged as privileged? Have all documents tagged as needing redaction been redacted? Does the log entry describe the privileged text (not the non-privileged portion)?
c. Review email domain list – Have your service provider generate an email domain list for the privileged set and review it for third-party domains. You may find some obviously non-privileged domains; others may need to be verified. This is a quick and easy way to avoid the embarrassment of claiming privilege on a communication with the opposing party.
7. Assign control numbers in the database.
Assigning control numbers inside the database is the last step before exporting the privilege log data to Excel for final review and editing. There are competing schools of thought on privilege numbers versus Bates numbers; each approach has its pros and cons. The essential point is to assign control numbers pre-export to create a global numbering system. When you receive the inevitable challenge to a privilege claim or request for more detail, you’ll be able to quickly find the document both on the log and in the database using the control number.
Privilege logs must be approached strategically in the age of enormous data volumes. If not, they will eat up time and money better spent litigating the merits. This seven-step process covers planning, setup, review, and QC. With end-to-end collaboration and a good workflow, you can take the pain out of privilege logs.
