What lawyers want IT to understand about e-discovery
There are many reasons for an IT department to get involved with a legal team that needs access to company data. Legal teams need to collect and analyze corporate data in the contexts of litigation, compliance, and government investigations through a process known as e-discovery. E-discovery is often needed either because of a lawsuit or to prevent one from being necessary. However, the data may be needed for another purpose, such as an internal investigation or due diligence during an acquisition.
This process can also present a tangled web for the unwary, as a panel of legal professionals explained during OpenText Enterprise World. IT departments often are asked to participate, so it makes sense to understand what's being asked for.
Moderator Adam Kuhn is a lawyer as well as director of product marketing for OpenText's legal technology. The conference panelists came from both law firms and the corporate world. Robin Cardillo is a senior law clerk and team lead of litigations at Norton Rose Fulbright Canada in Toronto; James Vinson is director of e-data client services at Morgan, Lewis & Bockius in Philadelphia; Gordon Moffat is director of litigation support services at Pillsbury Winthrop Shaw Pittman in Nashville; and Rex Lewis is senior discovery coordinator at Hess Corp. in Houston.
Just to keep life interesting (You expected straightforward? This was a legal track, after all…), attendees were asked to refrain from direct attribution in order to comply with an initial disclaimer: "The views and opinions expressed in this presentation are those of the speakers and do not necessarily reflect the views and opinions of their respective employers." So, in the interest of the panelists' job security, pseudonyms will herein be used (in no particular order) to identify each speaker: Meet Red, Blue, Green, and Orange.
Because techniques and protocols differ depending on the nature of the legal issue, Kuhn chose to have the panel address e-discovery for a lawsuit, using the electronic discovery reference model (eDRM). eDRM consists of eight stages and is iterative; as a case progresses, requirements for more or different data may emerge, so steps must be repeated.
The first four stages, all that the panel had time to address, are:
- Information governance: managing data from the initial creation of electronically stored information (ESI) through its final disposition
- Identification: locating data sources and determining their scope, breadth, and depth
- Preservation: ensure the ESI is not altered or destroyed
- Collection: gathering ESI for use in the process
Stages five through eight cover the conversion of data to usable formats, if necessary, and its filtering; review and analysis; delivery to those who require it; and ultimate presentation during proceedings.
Of course, no project goes straight through the steps, said Blue. That's merely the ideal scenario. The first thing to do is identify data custodians (that is, whoever is responsible for the data's safe custody, transport, and storage), as well as where they house the data. “We try to get our hands on it as fast as we can and remind everyone of their continuing obligation to preserve data," Blue explained. It also helps for the house counsel and in-house IT to figure out, together, what they need.
Like this article? Join 1 million+ subscribers to our weekly newsletter.
It can be a challenge to get the data from the law firm's client, who may or may not have internal staff who can help, Blue added, especially since "the review is always starting yesterday." The process gets messier when the matter is an internal investigation, wherein the only people who know about it are in IT and the legal department. In that case, you just can't call data custodians to request their ESI.
Sometimes, Green said, the law firm's team gets involved in only a small part of the process. If the client has its own internal e-discovery solution and runs into a snag, it may ask its law firm for help with just that step.
Don't expect a smooth, consistent process. "From just a management and workflow process, we wish everything ran the same way," Green said. "But in reality, sometimes, especially using this model as the framework, you pop in and out of different pieces of it."
People can sometimes be too helpful (or just lazy) and may decide to send a terabyte of data to be processed, regardless of whether it's actually needed. "They just want it off their plate to say they did what they did and to check the boxes," Blue said. "Sometimes, you need to take a step back and have those conversations [about requirements] before everyone starts throwing terabytes of data at you."
Throwing lots of data at the lawyers may sound absurd. However, Kuhn illustrated what can happen, citing statistics from a 2011 Microsoft information submission to the U.S. federal rules commission:
- 48,431,250 pages (800 GB) of data were preserved, from which
- 12,915,000 pages (210 GB) were collected and processed, and
- 645,750 pages (10 GB) were reviewed,
- ultimately producing 141,450 pages (2.3 GB) of data.
Guess how much of that was actually used in the trial.
Brace yourself: a mere 142 pages (2.4 MB).
That's why all of the panelists encouraged companies to have well-defined and enforced data retention policies.
"Outside law firms don't want to get a lot of data," Orange noted. "Companies don't want to preserve a lot of data. It's good to know the types of data sources you have and the types of data that reside in those data sources." You also need processes for extracting data from all of those sources.
Blue agreed. "The last thing I want to do is look at 15 years of archived material because no one followed the retention policy. But I'll do it—and I have done it."
There's another reason to limit the amount of data you're sending: There are risks attached to having copies of your corporate secret sauce out of your control. But how much data is too much? Panelists provided the quintessential lawyer-ish answer: It depends.
Orange thinks smaller is better, with 500 GB about where the panelist starts worrying. On the other hand, "I get nervous around 100 GB," Red said. "Generally because we all know that there's not 100 GB of wisdom—100 GB of the wisdom of the universe cannot be expressed. So that's a lot. And that means we're getting the 'grab and throw over the fence' to us."
For Green, the “right amount of data” depends on the client. One client, for example, has e-discovery tools in-house, and for it, 20 GB is a lot. For another, less than 100 GB is worrisome.
It's not over until it's over
Blue advised that internal and external legal teams should work collaboratively to plan things like search terms and date parameters, emphasizing that the process is iterative.
Red agreed. "The discovery request is really just sort of a first pass. You'll see that the attorneys talk back and forth, back and forth. Even as you're producing records, they will still be discussing the actual implication and scope of that initial discovery request."
Green added, "Be mentally prepared or have the process to be able to go run additional searches." And anyone doing searches needs to understand the tools' syntax. For example, one platform uses an asterisk as a wild card, while another uses an exclamation point. If a search goes wrong, you'll be dealing with the consequences for a long time.
"Details matter," Green said.
E-discovery: Lessons for leaders
- Know your data: what it is, where it is, and who has custody of it.
- Establish and observe data retention and destruction policies so you're not wading through decades of data unnecessarily.
- E-discovery is an iterative process. Have tools and processes in place to allow for multiple passes.
The information provided in this article does not, and is not intended to, constitute legal advice; instead, all information, content, and materials available on this site are for general informational purposes only. Information on this website may not constitute the most up-to-date legal or other information.
Readers of this article should contact their attorney to obtain advice with respect to any particular legal matter. No reader, user, or browser of this article should act or refrain from acting on the basis of information on this site without first seeking legal advice from counsel in the relevant jurisdiction. Only your individual attorney can provide assurances that the information contained herein—and your interpretation of it—is applicable or appropriate to your particular situation.
All liability with respect to actions taken or not taken based on the contents of this article are hereby expressly disclaimed. The content on this posting is provided "as is"; no representations are made that the content is error-free.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.
Lynn Greiner is a freelance technology writer, and the odd combination of a geek with a business degree. She spent many years working in corporate IT, both on the ground and in management, and is ITIL-certified.