Someone Else’s E-Discovery Nightmare

(Ogilvy Renault LLP)

As a commercial litigator, I have dealt with cases having large volumes of documentary production and e-discovery. But I decided that I would share the thoughts of some individuals currently in the trenches instead of blogging about a personal e-discovery experience or trying to come up with any words of wisdom (which we all know, in the e-discovery realm, means something that I learned from my own mistake or a corporation’s well-publicized mistake following a U.S. judgment).

An e-discovery project is underway in my office that I affectionately think of as “someone else’s nightmare”. The case involves both U.S. and Canadian regulatory and criminal investigations and, as these things tend to go, shareholder class action litigation. Of course, all of these various players want all of the company’s documents, and no less than all, and they want them immediately. Once in awhile, my colleagues on the file consult with me about specific e-discovery issues which arise – I give my two cents, and I then bow out and let them deal with my two cents in the context of a morass that I can, happily, ignore.

Here are some questions to and answers from my colleagues living the nightmare:

Q1. How have you managed the time demands placed upon you by powerful authorities like the U.S. Department of Justice?

A1. I have been honest. I recently advised that I could deliver the data immediately as requested, but that might bring down the entire Department of Justice with the viruses that are currently infecting the data, or they could wait a few days while we dewormed the data. They agreed to wait a few days.

Q2. Didn’t your forensic services provider deworm the data for you?

A2. The data was dewormed several times before we received it: by the client, by our forensic service provider and our data processor, and we also dewormed it. However, that did not prevent the reappearance in the data set of the famous 2001 “Anna Kournikova” and “I love you” viruses when we uploaded the data to our servers! Déjà vu all over again.

Q3. What is the one thing you wish you were able to instruct the forensic services provider at the beginning of the engagement?

A3. Do NOT strip attachments from emails. Privilege review is a dreadful when the links with attachments are broken. Unfortunately, we had no input into the early processing of the data, and a forensic application was applied which stripped attachments from emails and assigned random unique identifying numbers to each record different than the hash values contained within the original .pst set. It was quite a headache reassembling this stuff.

Q4. With regard to privilege, is there anything that corporate counsel could do on an ongoing basis with the foresight that their e-mail communications could be subject to e-discovery down the road?

A4. When corporate counsel and transactional lawyers are in the throes of a transaction, they forward sensitive information via e-mails to various parties, such as auditors and bankers, without regard to privilege issues. Much of the time, I will see draft documents prepared by counsel for review by clients that are then forwarded to underwriters, bankers, auditors and other parties. This makes sense within the context of the transaction world. Although the effect of these transmissions is to get the deal done effectively, it creates the risk of waiving privilege in legal advice that may be contained within the document and associated e-mails – or opening up this argument to regulators and other authorities or plaintiffs in class proceedings so they can try to get access to these e-mails and draft documents. I do see examples of privilege loss in my e-discovery reviews, particularly since the transmission of forwarded emails beyond a tight group of people is so easy.

Q5. How do you manage the process in a large e-discovery project?

A5. I wish that all parties with an interest in the electronic data could develop a protocol for managing, processing and reviewing the data before we begin a project. However, there’s not yet any process or framework in place to do this every time, particularly when regulators and law enforcement personnel are involved or become involved at different times. I have had regulators or law enforcement personnel request delivery of the information in a different format and according to different protocols than is being developed and would be expected in the civil litigation context. Most often, this is because regulators or law enforcement personnel have access to and use different computer systems and applications than civil litigators. And, these systems and applications often cannot talk to each other.

I have found that different recipients of the data can take different positions about culling data by means of deduplication processes or culling for spam or other material unlikely to be relevant. Different recipients have also had different priorities about what data should be reviewed first. This has created quite a traffic-control problem for us here.

When reviewing and processing electronic data that will be transmitted to different jurisdictions, the different laws relating to privilege and relevance makes review and coding of the information tricky, particularly when it comes to privilege calls. The pressure is on when failing to separately mark a document that would not be considered privileged in Canada but could lead to subject matter waiver over an entire privileged data set in the United States!

Q6. How do you manage the volume of data?

A6. As best we can, and by segmentation, segmentation and segmentation. On one large project, we have divided up the data into a couple dozen smaller databases by custodian and by year, but even so, these databases can run into the tens of thousands of electronic documents. One project can occupy a lot of server space.
We often have several people working in a database at once to get some traction in the review process. However, the major document management programs (like Summation and Concordance) are “flat”, and too many coders working in one database at a time can crash, slow-down or disable the system. We recently ran into a situation where the volume of data being processed crashed our server, without warning. Fortunately, we didn’t lose too much data, but the crash did set us back a few hours. We also have a law clerk who is packing and blazing our Summation databases daily – she’d say it was on a full-time basis!

Q7. How do you achieve consistency in your coding?

A7. We have a lot of meetings with all the coders to talk about coding and to bring issues forward on a daily basis. Did I mention we have a lot of meetings? We also do a lot of keyword searching across data sets to try to ensure coding consistency.

Q8. Are there any spooky things about this project that keep you up at night?

A8. You mean apart from scheduling how we process too much data in a too short period of time, worms and viruses, crashing servers and the risk of inconsistent coding leading to loss or waiver of privilege across jurisdictions? Tricky legal questions like how to code system-generated virus neutralization messages, e-mail read receipts, and e-mail delivery status notices within a privilege review. I’m not kidding! The Wigmore criteria for identifying the existence of a privilege were not crafted with these routine electronic messages in mind. We’ve had some really great legal debates about whether a read receipt generated by an e-mail sent to a lawyer actually gives rise to an appropriate claim of privilege.

Now you, like me, can be glad that this is someone else’s nightmare…and learn from it.