Privilege logs pain anyone preparing them. In this post, I’ll outline the current needs, pain points, tricks, and tools that can transform the average Relativity user into a privilege log-building and -verifying master.
I'll cover:
Which common difficulties delivering privilege logs increase the risk of errors.
What existing tools (e.g., Excel macros) can mitigate those risks.
How curating metadata during review and building logs in a review platform reduces error.
Why name normalization is an essential aspect of consistent privilege logs.
Teams can only skip building a privilege log when documenting privilege is unnecessary for the case. Unfortunately, this only happens when parties produce all documents. Instead, parties usually spend lengthy cycles creating, reviewing, and revising “the document from hell, aka the privilege log.” Additionally, when counsel withholds or partially produces responsive documents containing different types of privileged data, a priv log becomes necessary.
The basis for declaring information privileged includes a number of factors. Privileged documents include client-attorney privilege, trade secrets, personal identifier information (PII), software credentials, etc. It is also safe to say, lawyers quite often withhold more than they should because it is easier to withhold entire documents or document sets than to accurately declare all the different types of privileged information and categorize and organize them into coherent, compliant narratives.
“Lawyers too often withhold documents that do not meet the strict conditions of a privileged document…” State Bar of Michigan
The challenges of creating privilege logs stem from what has largely been a manual and time-consuming process. Humans being human make mistakes. Reviewers come and go on cases, reducing a team’s overall familiarity with the matter. Different managers brief different reviewers with varied instructions. The understanding of matters changes over time as new information arises. What's more, the ever-increasing number of documents in caseloads only compounds problems by adding to the volume what needs to be reviewed.
Rectifying mistakes requires time-consuming, expensive work. Inconsistent privilege logs can inadvertently leak information about documents and case strategy to other parties. Fixing errors might require expensive clawbacks and reproduction, or revisiting the scope and limits of the documents to produce, at times, losing rights to any privilege. And then there’s the potential for ruining your reputation with clients. No one wants to deal with these issues, and you don’t have to.
“Preparing a privilege log sucks, but forfeiting attorney-client privilege sucks even more.” – David Lat, Above the Law
Thankfully, existing tools and techniques can reduce errors when creating and verifying privilege logs. Standardizing a procedure with preexisting text for the privilege basis is a great starting point. Lead attorneys use this text to tailor the bulk of a privilege log's narrative. Project managers can then export the standardized text and coding data to a CSV file format and use spreadsheet macros to quickly piece together the content into informative, cohesive narratives for each document. This approach keeps review attorneys moving forward on the case while maintaining a consistent, easy-to-analyze and modify privilege log.
Eliminate the need to repeatedly export and build privilege logs by creating and editing them directly in a review platform. Going back into a review platform, exporting data, and reassembling narratives wastes time. Tools that build the privilege logs in a review platform streamline the editing process. This also allows the team to stay focused on validating the privilege log and not decrease their productivity due to context switching.
Next, stop relying on people to manually manage templates and apply boilerplates to the right documents at the right time. Assemble the narratives automatically with a tool that decides which narrative text should be incorporated based on a document's coded privilege reasons, authors, recipients, or any other metadata. Such a tool also constructs the final privilege explanation for each document – replacing error-prone human tasks and subjectivity. That said, tweaks to language may occasionally be needed, so the "right" tool will also allow for manual adjustments and inputs.
For even better results, prevent errors in a privilege log by building and verifying it during document review. Showing reviewers a preview of what the "final" narrative will be as they code documents not only makes it easier to code, but also to quality check the priv log. If a coding choice creates a faulty priv log narrative, it can signify that the doc was coded improperly or that the story of the priv log is broader and more nuanced than initially thought.
Privilege log tools must also take advantage of entity extraction and name normalization. The same name, email address – or an otherwise agreed-upon identifier – must identify each entity in a privilege log. This increases the priv log's readability and improves the likelihood of catching irregularities before handing a production off to a third party. It is even better if a tool can indicate categories of entities – such as placing an asterisk after attorney names – when assembling the privilege log.
If your current solution doesn't solve all of these problems, I encourage you to check out the new release of Chronicle for Relativity. Chronicle uses custom rules to build privilege log explanations automatically within Relativity. Chronicle also includes features that improve the review process as well as allows users to make quick edits to a privilege log whenever needed – whether it's pre-, during, or post-review.