Looking back on my last few meet and confer sessions, I recall spending an inordinate amount of time discussing e-discovery processing and production specifications, and little on the location and description of electronically stored information (ESI). It is often the case that people feel more comfortable discussing the form and format of production details, however, it is critical to discuss the data map in detail. The best way to answer the two most often asked questions, “How much data is there, and how long will it take to produce?” is to ensure an up-to-date data map is in play.
Data maps are essential for compliance with Federal Rules of Civil Procedure 26(a)(1)(A), which covers the duty to disclose and general provisions governing discovery.
In the ideal world, the client has proactively – prior to litigation or investigation ensuing, taken strides towards creating a data map. Unfortunately, in the majority of the cases wherein I have assisted with collecting ESI, a data map did not exist, or one existed, but was sadly out of date.
The concept of a data map is not overly complex; however, creating a data map can be time-consuming and requires the involvement of several key stakeholders. Whether designing a data map in a proactive or reactive manner, you will want to keep the following in mind.
Who Owns the Data?
Prior to the commencement of creating the data map, meeting with and receiving buy-in from the ultimate decision maker, which is often the chief technology (or information) officer and general counsel is critical.
In addition, it is necessary to conduct interviews with the business unit owner(s) for each department (legal, accounting, HR, etc.). The business unitowner will play a key role in identifying all locations where ESI may be located.
Types of Data
The two key classifications of data types are structured and unstructured data. As you can imagine, structured data is organized in a controlled, manageable format such as an Oracle database. Unstructured data by contrast is loose, raw data residing in varying locations—for example, email, word processing documents, etc. The manner in which each data type is stored and backed-up will likely vary. It is important to note, certain types of structured data can be extremely large and unwieldy. In addition, where you can often isolate and collect certain unstructured files, the data contained within structured data may require third party reporting tools (i.e., Cognos) to create meaningful reports. You should track this when creating your data map.
Don’t forget to look in old data lockers, storage rooms and other rarely visited places that may contain legacy systems / data. This is an often overlooked, yet equally important part of creating a data map. You will want to know if there are legacy hardware systems active or offline, and what data is stored on each.
Keeping Up to Date
When we think of a data map, we often associate it with a visual schematic. While this can be the case, at least in part, the majority of the detail captured as a part of a data map is in textual format, and is stored in a database or multiple spreadsheets.
Once a data map is created, it is important to understand that it is a living, breathing document. In order to maintain its effectiveness and overall value, it will need to be kept up-to-date. This can be achieved by assigning each business owner with the task of keeping their department document current.
Simply calling the client’s “IT guy” and asking where all the data is located without an identified data map is no longer acceptable. It is imperative prior to attending a scheduled meet and confer, you understand what potentially relevant ESI your client has in its possession, where it is located, how it is maintained, whether it is readily accessible and the associated costs for producing.
A data map can prove an invaluable resource for both the business and outside counsel should the need arise to know where ESI is stored and keeping in compliance with the e-discovery requirements.