The following is Part III in a multi-part series on how to draft and leverage an ESI protocol in any litigation. Part I of our series discussed the When, How and Why in planning for and creating your ESI protocol. Part II addressed the Key Components of an ESI Protocol.
In conjunction with this series, eDiscovery Assistant has created a new section in Checklists and Forms titled ESI Protocols that will include new content with each part of this series.
You don’t know a good thing until it’s gone. Hindsight is 20/20. If only . . .
There are many different sayings to express regret in not planning properly for producing or receiving ESI in litigation. The one, surefire way to avoid that regret is to get a good ESI protocol in place that considers all of the aspects of ESI issues in a case. You know this, and we’ve been writing about it for weeks.
But I read you, you’re not convinced or you don’t know the real value of why you need to spend time drafting one, and you’re not even sure you know what to include in it. (See Part II of our series for the answer to that question.) Just this week I’ve heard from in-house lawyers that their uber-sophisticated large firms aren’t using ESI protocols in a complex trademark dispute.
Why not? Could it be that they don’t get the value?
So, as I sat down to write this week, I reflected on all the issues that we see with data we receive whether subject to an ESI protocol, or not, or from a third party who doesn’t feel the need to comply with a protocol that is in place. And what occurred to me is that to know WHY you need a protocol, you need to understand WHAT you are missing out on for your client when you don’t have one. In collaboration with Joy Murao, CEO of Practice Aligned Resources in Los Angeles, we’ve identified ten situations that we see regularly in receiving data, how those could have been prevented with a solid ESI protocol to enforce with the court, and what it costs your client each time one of these things happens.
As you read this list, give thought to the data you are currently trying to wrangle for depositions, what you want to show at trial, or what data you need to prove your case. Notice that I said data, not documents. Data about the document (think metadata about a social media post—who authored it, when it was published, who commented, what they said) is sometimes as, or more important than the document itself.
Here it is, the list of the top ten situations you can avoid with a good ESI protocol:
- You need to search text of the documents, but you receive unsearchable pdfs or a production with no text. Simply put, no text = no search. Your protocol has to provide for the production of a text file with images. (Of course, if you’re receiving native data, that isn’t an issue, but if you are, you likely don’t need to worry about this situation.) Can you OCR the documents to create text? Sure you can, but you’ll have to pay someone to do it, either by the hour for PM time, or by the document. You also slow down your ability to start reviewing the documents because you can’t sort them effectively until you can search across them.
- You receive inconsistent production formats. This one happens ALL THE TIME. Even with a protocol, parties will produce documents one way (think TIFF images and a load file) and another way the next time (non-searchable pdfs). They’ll then argue that you have a reasonably useable format and you don’t think the court will grant much relief, but it seriously impedes your ability to use the documents effectively (see no.1). We’ve seen productions from third parties in HTML format—no images, no nothing else—that are forwarded from counsel months later and there’s no time to go back to the third party. Those documents are barely useable. Your protocol needs to have a production format section that addresses format for each type of document (think bulk categories and exceptions, like spreadsheets and PowerPoints, social media, images, etc.) that allows you to take a party to court to enforce the production format. Lack of consistency in format adds thousands of dollars in costs to your case, and will keep you from being able to leverage data. You can’t see the formulas in a spreadsheet if the spreadsheet is images or in pdf format.
- You receive data with a created date newer than the modified date. This is a doozy and one we see a lot. You need to ensure metadata is not altered during collection so you receive the same data that the other side has. Your protocol needs to state that the created date is a metadata field to be provided and that data will be collected in a way that preserves the metadata in tact. Too many times data is dragged and dropped into a folder for collection, and that process changes the created date to the date its moved. You’ve just spoliated data. The fix is to require the other side to re-collect, re-process and re-produce the data a second time. That sounds like fun, and something the other side will immediately agree to, right? You can protect your client with language in your protocol that lets you go to the court as needed or that ensures the other side will do it right the first time.
- Your production includes images or social media posts, but you receive only images with no metadata. What you have are just images, and images can’t be OCR’d. That means you have to manually identify and code text or metadata about each one to be able to use them effectively in sorting, adding them to trial exhibit lists, etc. Instead, request specific file types and metadata fields for both images and social media (they are different) and discuss how they are collected. For images, be sure to get the native file path so you can know where the image came from. If it’s not attached to an email or other document, you want to know what else could live where that image lived in case you want it.
- You need to redact documents or you want to identify redacted documents. Redaction for reasons other than privilege is becoming much more of an issue as documents showing irrelevant business information are implicated in discovery. I usually want to see all the redacted documents, but unless I asked for a metadata field populated for redactions, the only way to find them is to go through them one by one.
- You need to sort by the Confidentiality designations. This goes hand in hand with the redactions. I’m pretty keen to see what documents are marked “Highly Confidential—Attorneys’ Eyes Only” and make sure that all confidential documents should actually BE confidential. Your protocol needs to include metadata for confidentiality designations and the right language from the protective order populating that field.
- You need to know the original file path of the document. You find the smoking gun document in your collection, but you have no metadata—no custodian, file path or other identifying data—to know where it came from. We use file path all the time to track where a document lived, and that allows us to know what witnesses to use the document with during depositions. Include it as a metadata field in your protocol. You’ll be able to use it in so many ways.
- You need a consistent process and timing to produce privilege logs. FRCP 26 provides what needs to be included in a privilege log but not format or timing (although some judges do have local rules on privilege logs). Articulating the fields and timing of the privilege log give you a written order to point to when you haven’t received a log, or when you doubt whether privilege applies to certain documents.
- You need a court order for a basis for sanctions. FRCP 37(b) requires a party to show a violation of a court order to get sanctions under that section and guess what, the judge signed off on the Order you added to your ESI protocol. Viola. You just saved yourself a motion to compel, and moved right to sanctions for failure to abide by it.
- You inadvertently produce information. Yes, the number one reason you need an ESI protocol with an FRE 502(d) order or a sufficient clawback is when you inadvertently produce privileged information. With the Chinese fire drill way discovery usually happens, this very situation has been addressed by a specific rule of evidence. Use it to protect your client and incorporate it into a protocol.
This list could be much longer than ten—in fact, we came up with dozens of scenarios that allow you to control costs and your ability to use data better for your cases by having a solid protocol that anticipates what you need and ensures that all parties provide it. Refer back to our Part II in this series for what those key components are. Remember that not every protocol has to be complicated, but since every case includes ESI, every case should have some protocol.
Part IV of our series next week will address metadata fields to include in your protocol.