Struggling To Know How To Find The Evidence You Need In eDiscovery? This Should Help.

A checklist for identifying and understanding the sources of ESI that exist for a case.

One of the hardest parts of dealing with eDiscovery as a litigator is having to walk into a room and ask questions about ESI when you don’t know or understand how the systems that create and store ESI work. During a presentation last week, an attorney asked me exactly how to deal with that situation and we talked through my mental checklist on what I want to know. Her question was a good one and one where I thought you might like to hear the answer. This information is also good to use when talking to your client’s IT staff or even during custodian interviews when you don’t know the client’s systems intimately.

We’ve talked before about starting at the end and letting the jury instructions and what you need to prove or defend drive your discovery. I’ve told you that I believe targeted and cooperative discovery is how to control costs and advocate for your client effectively. So how do you do that when your client knows little to nothing about the systems of data that may contain the evidence you are looking for? And when opposing counsel isn’t a fountain of knowledge either?

Start by thinking about what the evidence is that you need and where you would find it. Ask your client pointed questions to help you identify what you need to ask about — you will have to be the detective to identify the sources of ESI you need to request. They know more than they think they do. Use the questions to narrow the focus of what you are looking for. For example:

  • How did/do you communicate electronically?
  • How did others communicate at levels higher up that you? You need to have an idea of what types of data you are looking for. Is it email? Instant messaging? Social media posts? Text messages? Photographs?
  • Did you see electronic communications that are what you are complaining about or need to use to defend the case? If so, where were they? Who wrote them? Date range?
  • For mobile devices, are they company issued? What’s the company policy on mobile devices and how is access to data set up if at all?

But there are times you won’t have good intel from your client and you go into the meet and confer or the initial discussion blind. What do to then? Have a list of general sources of ESI that you believe may have relevant data for your case and use this checklist to learn more about what is available in each source so you can tailor your request appropriately:

  • Data type. What is the type of data the source covers? Email, IM, social media, database, time-keeping, procurement, inventory, contract management, etc. Those are just a few examples.
  • Date range of available data. How far back does data go in this system? If the system was put in place AFTER the duty to preserve arose or during the timeframe of data you are interested in, you want to ask about the legacy (previous) system and what data was migrated to the new system. Oftentimes companies will migrate old data to the new system but it depends on the cost and value of that data.
  • Retention set on the system. How long is data kept? What is the basis for the retention? Is there a policy in place? I explore this only to the limits of what I need for a case — there really is no need to see a policy unless what you are looking for isn’t there. For example, if I need data back to 1/1/15 and the data is available back to 1/1/13, there’s only a need to ask for what is relevant.
  • Legal hold. Was a legal hold put on this data? If so, when? Case law generally protects against having to produce a legal hold notice, but when it was issued and to whom is discoverable. Was the source specifically listed in the hold or was someone notified to put data on hold? Again, this is only necessary if the data you need no longer exists.
  • Physical location of the data. Is the system stored locally at the client or in the cloud (meaning someone else is storing it)? If it’s in the cloud, and stored as part of a third party solution (meaning that the party uses the system but does not own access), how accessible is the data? How long will it take to get it? Are there any barriers to access for the party that need to be addressed? Any expense in acquiring it that needs to be considered?
  • Format of the data. What format is the data available in? You need to know that to plan. Some systems will only to export .pdf files, while others will allow you to export native data. Ask. Most databases just provide reports, most in .csv format, which is readable by any spreadsheet application (think Excel, Numbers, etc.).
  • How it works. If you don’t know how the system works, ask point blank. For example, if you’re asking about Salesforce.com, walk through how a salesperson uses it to record data. When do they access it, how do they access it (computer, mobile device) and via what location? On a mobile device it may be via an app, or it may be via logging into the company VPN to get to the database (not usually for Salesforce, but maybe for other CRM applications). What is the step by step process used? Look at screenshots or have counsel show you the platform. Study it and figure out whether and how data stored there may be relevant and good evidence and what you want to ask for. This step should also be where you learn how data is captured by the system.
  • Fields for database reports. If you are getting a report — whether it’s time entries, customer calls, orders for a product, etc. — consider what the fields of data are that you want in that report. Chances are 100 percent that there are hundreds of fields of data that you do NOT want, and when you fail to specify, you’ll get them all. What happens is that you end up with a monstrous .csv file that crashes when you try to load it. If you do that, save an original copy, then on a COPY, delete the useless fields so you can focus just on what you want to see. I like to ask for the pretty copy — it has great formatting and is easy to read — AND the .csv with the formulas in it. You’ll want both.
  • Who has access. You want to know who has the ability to create, store, send and receive data from this source. Not a complete list if it numbers in the tens of people, but generally. For example, if manufacturing workers have email addresses but rarely access them because they have shared workstations, that matters. Pay attention to this as we’ve seen cases where bad actors create data on someone else’s account and knowing the level of access was has helped identify the issue. Forensics can help there too.

Sponsored

Your real goal is to learn how data is created, stored, sent, and received for the particular application so you can make decisions about the scope of what you need. For each type of application and each individual case, your inquiry will be different. Tailor it. Think about what you need during the meeting, and don’t feel pressured to commit to what you want on the spot.

Once you’ve had that meeting, go back to your office and think about what you’ve learned. Google some stuff. See what other questions you have and follow up — all with the goal of providing tailored discovery that gives you relevant data.

Your job now includes having to identify the relevant data and get it. Hopefully, this list will help.

Did I miss something?  Drop me a line and let me know.


Sponsored

Kelly TwiggerKelly Twigger gave up the golden handcuffs of her Biglaw partnership to start ESI Attorneys, an eDiscovery and information law Firm, in 2009. She is passionate about teaching lawyers and legal professionals how to think about and use ESI to win, and does so regularly for her clients. The Wisconsin State Bar named Kelly a Legal Innovator in 2014 for her development of eDiscovery Assistant— an online research and eDiscovery playbook for lawyers and legal professionals. When she’s not thinking, writing or talking about ESI, Kelly is wandering in the mountains of Colorado, or watching Kentucky basketball. You can reach her by email at Kelly@ediscoveryassistant.com or on Twitter: @kellytwigger.

CRM Banner