All of the recent talk about privileged documents has been about the importance of clawback agreements. While important, it is more important to not produce privileged documents in the first place. How to avoid the inadvertent production of privileged documents in the eDiscovery context is the subject of this article.
Pre Document Review Phase
It is sometimes known at the time that documents are received from the client that they are privileged. Keep these documents separate from the rest of the collection. Save them in their own “Privileged Documents” folder on the network. When forwarding them to a paralegal or litigation support professional for processing and importing into a document review database do so in an email that does not contain any non-privileged documents. Include instructions that these documents need to be tagged as privileged and\or placed in a privileged group or folder in the review database. Once the documents are in the review database confirm for yourself that they were tagged and foldered appropriately. Enter a note in your calendar as a reminder to do this.
Document Review Phase
Most of the time client documents have not been pre-identified as privileged. That means that privileged documents need to be identified during the document review process. To assist in this determination documents can be flagged as potentially privileged before the review begins. These flags will alert the reviewer that a document may be privileged. The first step is usually to create a list of privileged search terms. This list is then searched against the database. The results can be tagged as “Potentially Privileged” and reviewed separately from the rest of the population. The tags can be changed as the documents are being reviewed.
Further, some review tools allow you to highlight the search hits in the document viewer. The reviewer can scan the document for the highlighted word or words and more quickly and accurately determine whether it should be tagged as privileged. Applying one or more of these techniques will make it less likely that a privileged document will be missed during the review process.
Steps can also be taken during document productions to prevent the inadvertent release of privileged documents. Some review tools allow you to apply production restrictions to a database. You can apply these restrictions to documents tagged as privileged. If you then try to include a privileged document in your production you will receive a warning.
Also, never, never, never use the same Bates numbering scheme for privileged documents that you are using for production documents. Instead, use a different Bates numbering convention. Obvious ones are those that have a prefix of “PRIV” or “PRIVILEGED”. This number needs to be branded onto the images of the privileged documents so that if they are printed to paper or exported from the database it will appear on the document. Assigning a privileged Bates numbering scheme to privileged documents will make it obvious to everyone that the documents are privileged.
Further, do not enter the beginning and ending privileged Bates numbers into the same fields as the production Bates numbers. Instead, create two new fields called something in the nature of BegPriv and EndPriv and populate these fields with the beginning and ending privileged numbers. The empty production Bates number fields and the populated Privileged Bates number fields will provide visual clues that the documents were not produced and are privileged. Also, the privileged documents are less likely to appear in searches that are predicated at least in part on documents having a value in the production Bates number fields.
Documents that are redacted for privilege reasons are a special case. The production, not privileged, Bates numbering scheme can be used and these numbers can populate the beginning and ending production Bates number fields. These values should also be copied into the BegPriv and EndPriv fields. Not only will this indicate that the documents were redacted for privileged reasons but it will be easier to include them in a privileged log as all of the Bates numbers are in the same fields.
Post Production Phase
After a document production there are various ways to segregate the privileged documents from the rest of the population and prevent them from being inadvertently released. One common approach is to move them into a separate database. While effective, it can be costly. The client may be charged for this second database. Also, even if the cost to the client is small there is additional administrative overhead to creating a second database that the hosting party may not want to incur.
There are effective ways to isolate and protect privileged documents while keeping them in the same database as the rest of the collection. You can prevent the documents from coming up in searches of the database by not including them in the general search index. If the documents do not appear in searches there is less of a chance that they will be inadvertently released to the wrong parties. If the privileged documents need to be searched, you can create a separate index that includes all of the documents in the database and name it “Includes Privileged Documents”.
Measures can also be taken to protect against the inadvertent removal of privilege tags . The privileged tags can be copied to a second read-only field named “Privileged” or “Privileged Lock”. The read-only property will not allow the user to remove the privilege designation from the field. This second field will retain the privilege designation even if it is later removed from the original field.
Clawback agreements should be executed as part of your litigation strategy. The more important strategy, however, is to prevent the release of privilege documents in the first place. Applying the above suggestions should help accomplish this.
View This Blog