Reviewing documents for privilege is a common part of ediscovery; it's important to make sure that privileged or sensitive documents don't get unintentionally shared. Everlaw has several built-in tools to support a smooth privilege review, from case configuration all the way through sharing a production.
This article guides you through some best practices and tips for using these built-in tools for your privilege review. It describes how to move through your case:
- Set up your privilege codes
- Configure your production settings early to identify the proper documents to withhold
- Use search to identify privileged documents
- Make sure privilege codes are applied to the appropriate documents
Depending on your needs, you and your team can use all or just a few of the tools and practices described here to define your own best practices for a privilege review.
This article does not describe tools for redacting sensitive or privileged content. For information about redaction, see our Redaction article.
Requirements
Many of the tools described in this article require Project Admin permissions to set up.
You can find information about permissions for specific tools in the linked articles that discuss each tool.
Step 0: Before you start: Determine privilege criteria
Before you start configuring your Everlaw case for a privilege review, make sure you have clear criteria for what counts as privileged for a document.
Decisions to make:
- The different types of privilege relevant to your case
- The criteria for meeting each type of privilege
- How you will share the criteria with your team
Tip
Create a Storybuilder Draft that includes your privilege criteria and examples of documents that meet each one. Then, you can share this Draft with View-only permissions with the review team. Learn more in our Storybuilder Drafts article.
Step 1: Create privilege codes
Once you have planned out how your team will designate documents as privileged, you can configure the codes for them to apply to documents. To create codes, go to Project Management > Project Settings > Codes.
Decisions to make:
- What code(s) applied to a document indicate that the document is privileged
- Whether you will create freeform code categories, which allow users to add their own value for the code
- Whether you will use coding rules to structure the privilege review
- Which user groups have access to the privilege codes
Learn more about creating codes in our Administer Codes for Review article.
Below are some more useful tools for creating codes.
Tip
Once you create the codes, you can copy them to a new project when you create future databases or projects. Learn more in our Projects article.
Add pre-configured codes using the Code Wizard
In Project Management > Project Settings > General > Production Tools, Everlaw includes a wizard to add common coding categories and codes.
When you're ready to create the codes, use Everlaw's Code Wizard to create:
- A Privilege category with Privileged and Potentially Privileged codes
- A Privilege Type category with Attorney Client, Work Product, and Other codes
When you add these codes from the Code Wizard, you can edit them, delete them, or add additional codes within either category. This lets you personalize the privilege codes to your specific project.
If you don't use the Code Wizard, you can also create your own codes from scratch from the Codes tab in Project Settings.
Learn more about production tools in our Production Tools and Redaction Stamps article.
Create Freeform codes
Along with these standard codes, you can create a freeform coding category to allow your users space to add more specific details about privilege that you can't necessarily predict. If required, you can include this information in a privilege log. For example, users can fill in values like "Email to outside counsel re: legal strategy" or "Draft motion for summary judgment."
Use a freeform code when you need to write and share detailed descriptions for why a document is privileged.
Learn more about freeform codes in our article about creating codes.
Create Coding rules
There are two types of coding rules you can configure to enforce clean coding practices:
-
Conditional rule: Use a conditional rule to link two codes/categories together. This is often used to link privilege and privilege type codes together —you can require that if a user codes a document as Privilege: Privileged, they must also choose a code from the Privilege type category, or apply a freeform code to describe the privilege.
- Auto-code: Set up an auto-code rule to propagate codes to contextually related documents. This is most often used to mark entire attachment families as privileged if a single document within the family is coded as privileged.
Learn more about coding rules in our Use Coding Rules to Structure Review article.
Step 2: Configure your production
Everlaw recommends setting up your production protocol as soon as your data is loaded and your codes are created. This often saves time and stress as a production deadline approaches, and the protocol can be re-used for rolling productions.
There are four main steps for creating a production protocol that are relevant to privilege reviews: defining your production criteria, setting up custom quality control (QC) checks, setting up withholding rules, and creating a privilege log.
Learn more about creating a production protocol in our Create a Production Protocol article.
Create Production criteria
Your production criteria specifies the documents that you want to produce. To make use of Everlaw's privilege log, you should build your query to identify the production documents to include privileged documents. That way, you can set up a withholding rule to make sure the contents and metadata of the documents don't get produced, but that a Bates number is assigned to include the required information in your privilege log.
If you don't want to create a placeholder/slipsheet or assign Bates numbers to your privileged documents, you can create a production criteria that excludes them and separately export a CSV of any information that you're required to share from a results table. This isn't recommended because the pre-production control numbers (# prefix) are different than their produced version would be.
Add Custom QC checks
Everlaw has standard quality control (QC) checks built into the production process, but you are also able to create custom QC checks to meet the specific needs of your project. For example, if your review requires that every document getting produced needs to have a code from the privilege category applied (whether identifying the document as Privileged or Not Privileged), you can set up a custom QC check that will automatically identify any documents within your production criteria that don't have a code from this category applied.
Then, when you are ready to produce, Everlaw automatically detects any documents that don't meet your custom criteria, and allows you to take action before completing the production.
Learn more in our Pre-Production QC Checks article.
Set up a Withholding rule
Assuming that you have included your privileged documents with your production criteria, it's important to make sure Everlaw knows what documents should be held back from being produced and instead replaced with a placeholder/slipsheet. Each withheld document is represented in the production with a single-page Bates-stamped PDF displaying your customized withholding language.
The Withheld or Privileged Rules step of creating a production protocol is where you tell Everlaw what documents to withhold from production, and what language should be on the placeholder for the withheld documents.
The rule includes two parts:
-
Build a query to identify the privileged documents to be withheld. This should be a query for documents with the Privilege code applied.
Note
If you are withholding complete attachment families, make sure you group the query by attachments. This makes sure to bring in any attachment family members that should be withheld, but somehow missed having the Privilege code applied to them.
- Write the language to display on the placeholder image. The language is often something straightforward, like "Withheld for Privilege," but you can customize it to be whatever you want.
Configure a privilege log
A privilege log, typically in the form of a spreadsheet, is often a required part of a production. A privilege log shares information about the documents without revealing privileged content. On Everlaw you can create a privilege log along with your production, or create a multi-production privilege log that combines multiple productions in one log.
Create a single-production privilege log
On the Additional options step of creating a protocol, you can enable the privilege log.
By default, the privilege log only includes the documents that meet the criteria for your withholding rule, though you can customize this to also include redacted documents or all documents. Additionally, you can choose which fields are included in the privilege log. These fields you include are typically negotiated in advance.
Once you have configured your privilege log, it will automatically populate when you run a production. Then, you can share it along with the production, or choose to share it on its own.
Create a multi-production privilege log
If you are doing a rolling production, you can create a multi-production privilege log to put information about all the privileged documents across your productions into one log.
To learn more about creating one, see our Multi-Production Privilege Logs article.
Step 3: Search for privileged communications
Once you have set up your codes, you or a reviewer can run searches to identify documents that are likely to be privileged due to involvement of an attorney or other individual privy to privileged communications.
To find any email communications that people with privileged communications were involved in, use the Parties term and select all the emails connected to the relevant individuals:
- To identify specific individuals, select individual entities from the dropdown
- To cast a broader net, select any email domains that are connected to the relevant law firms/organizations with privileged communications. Make sure that your selections are connected with Any of. This identifies emails involving anyone using an email address from a selected email domain(s).
If your documents don't have email metadata information, you can instead use a Contents search to look for text that includes the relevant domains, such as a search for documents with the contents "@toplawfirm.com."
If your documents include chat data, you can use the Chat contributors metadata term to similarly identify chats involving any individuals with privileged communications.
Learn more about searching emails in our Search Emails article.
[Optional] Step 4: Apply codes to related documents
In many privilege reviews, when one document is identified as privileged, the entire attachment family or email thread is also supposed to be withheld. If this is the case for your review, you can get this done in several ways. This section describes several approaches for withholding complete attachment families/email threads, with tips for each. The approach you take is up to you, depending on your needs and the structure of your review.
Autocode rule
One way to withhold complete attachment families/email threads is to configure auto-code rules, as described in an earlier section. Once a privilege code is applied to one document, the code is automatically propagated to any other documents in the selected context, such as attachment families.
Auto-code rules help guarantee that the appropriate documents are coded without manually applying the codes, but take care when you implement the rule:
- If you only want codes to propagate from parents to children, then make sure you only review and apply codes to the emails (parents), and not the attachments. That way, codes always flow from parents to their attachments, and not the other way.
- For mutually exclusive codes, changing the code applied to one document can change the coding on other documents. For example, if an auto-code rule for the privilege category is configured for an email thread, the privilege code applied to one email is propagated to all documents in the entire email thread.
Later, if a different email in that thread has its coding changed from Privileged to Not Privileged, then the Not Privileged code propagates to all the documents in the thread. Since the code is mutually exclusive, this also removes the Privileged code from all the documents in the thread.
In this scenario, changing the code from Privileged to Not Privileged for one email changes the coding for the entire thread from Privileged to Not privileged. It's important to structure your review so that reviewers know to take care when changing the codes applied to documents.
Group results and batch-code
Once you have finished your review, you can use Everlaw's document grouping and batch-coding tools to gather privileged documents together with their attachment families/email threads and apply the Privilege code to all the documents in the search.
To do so, search for documents coded Privilege: Privileged (or whatever code you are using for privilege). Use Search Settings to group documents by attachments, and do not remove any documents.
From the results table, use Batch > Modify to apply the Privilege code to all the documents.
As with auto-code rules, you should structure your review so that privilege codes flow as intended. If you do not want a privileged attachment to lead to the parent email being marked as privileged, it's best to make sure your initial privilege review doesn't include any attachments.
To avoid propagating codes from attachments to emails, search for privileged attachments prior to doing the batch-coding. Once you identify any attachments coded as privileged, you can decide how you want to handle them: you can remove the Privilege code if it was applied in error, or do a closer review of the parent emails to determine the appropriate coding for the entire attachment family.
The search for attachments coded as privileged requires combining three terms and using grouping and removal options in search settings:
- Use the Attachment Group Size term to identify any documents with an attachment group size of 1 or greater. This excludes standalone documents.
- Use the Coded term to search for Privilege: Privileged documents.
- Make sure the terms are connected using the AND logical operator.
- Select Search Settings to open the Search Settings dialog. Under 3. Group, group your documents by attachment
- Under 4. Remove, select Parents.
- Select Save to close the dialog.
Your search should look like this:
Any documents in this search are attachments that had the Privilege code applied to them.
Learn more about search settings in our Deduplicate, Sample, Group, and Remove Search Hits Via "Search settings" article.
Learn more about batch modifications in our Batch Modify article.
Code from the context panel
When you're reviewing a document, the context panel is a tool to see and review documents related to the one you are reviewing. When you find a privileged document, you can use the context panel to apply the code to all the documents in the appropriate context at once.
Learn more about coding from the context panel in our Context Panel: View and Batch Code Related Documents in Review Window article.
Withholding rule
When you set up your production protocol, you create a withholding rule to create placeholders for privileged documents. When you do so, set up your rule to include the relevant related documents by grouping your query, such as grouping by attachments to pull in attachment family members of documents that have been coded privileged.
This is not recommended as your only means of determining privilege; if a document is being withheld it is best to affirmatively apply review work to that document to let everyone who views it know that it is privileged. However, grouping documents in your withholding rule can be a good backup to make sure that all the documents you do intend to withhold actually get withheld, even if some missed their coding during review.
[Optional] Step 5: Leverage Everlaw AI
For large-scale review, leveraging AI tools can save time and find you the right documents with less manual review.
Predictive coding
Predictive coding is included with all Everlaw projects at no additional cost. A predictive coding model learns from the coding decisions your team has made and identifies additional, similar documents that should likely receive the same codes.
So, if your team is consistently applying the Privilege code to documents with certain key terms or involving specific individuals, the predictive coding model will identify additional documents with those same characteristics that should likely also be coded as privileged.
Learn more about Predictive Coding in our A Beginner's Guide to Predictive Coding article.
Coding suggestions
For projects with Everlaw AI Assistant enabled, Coding Suggestions can use your coding criteria to suggest which codes should apply to a document or to an entire document set. For a privilege review, you can pull together the documents that are likely to be privileged, and run coding suggestions in a batch to identify the documents that match your criteria for privilege.
Learn more about Coding Suggestions in our Coding Suggestions (Everlaw AI Assistant) article.