Recently, I summarized the eDiscovery process in three simple phases: Phase 1 – Identification, Preservation, Collection, Phase 2 – Data Analysis, Reduction, Analytics and Phase 3 – Processing, Review, Production, as well as discussed the risks that legal teams face when they choose not to follow the process.
In this post I want to focus specifically on the topic of ESI processing because of (1) the essential role it plays in eDiscovery and (2) a common lack of understanding in the legal industry of why ESI needs to be processed.
What is ESI processing?
As with most things in our industry, the definition of processing depends on with whom you are talking and their level of expertise. Let’s take a look at D4’s high-level definition:
ESI processing is an eDiscovery workflow where native ESI is ingested into a single software program (i.e. Law, iPro, Tunnelvision, Access Data FTK, EnCase, etc.) designed to extract native file metadata and textual content in a normalized, standard format.
After processing is performed, the metadata, textual content, native files and/or images are exported and repackaged into a consistent, delimited format for the eventual loading into a document review platform or database.
Why does ESI need to be processed in eDiscovery?
If ESI is not processed, the native file source applications are required to open and view all content and any visible metadata within the files. This may seem reasonable for a handful of files, but when dealing with megabytes (MBs), gigabytes (GBs) or terabytes (TBs) of ESI, working with individual native files and their source applications becomes near to impossible.
In order to authenticate ESI, electronic data should go through a repeatable and defensible process. Reviewing ESI in its original source format and native file application can lead to data corruption, spoliation issues and eDiscovery protocol challenges.
Why does processing take so long?
There are many variables that impact turnaround times and deadlines. Here are a few things that may slow down ESI processing projects:
- Total volume of ESI
- Organizational and custodian structure of ESI
- Complexity of data formats
- Proprietary data formats
- Type of document review being performed (native or image review)
- Non-standard/custom processing requirements
- Custom field requests (i.e. chron date/time fields, hidden text flags, etc.)
- Native and image file exception/error remediation
- Encryption and password protected files
- OCRing native files where textual content could not be extracted (requires imaging, which adds an additional step in the process)
- Imaging all ESI – Oftentimes, it is a wasted step until responsiveness has been determined.
- Similar to imaging all ESI, imaging in color also slows down the process and can be an unnecessary step before responsiveness has been determined (color imaging also increases data sizes and can impact review and hosting costs significantly).
Courts and opposing parties are paying close attention to how ESI is handled during the eDiscovery process. Because of this, D4 is seeing an increase in consulting engagements that revolve around the review of Discovery protocols.
In the end, legal teams can choose to take shortcuts with ESI in an attempt to expedite the process, but they do so at their own risk. In order to minimize risk, the best practice is to send all ESI—regardless of data volume—through the same repeatable and defensible process so that eDiscovery protocols don’t trump the actual issues of a case.
Attract & Retain Top Talent
With a rapidly changing industry, it's vital to offer the right compensation and set the right expectation. With our Salary Guide, get detailed job descriptions, industry insights and local salary data to equip your managers with hiring confidence and expertise.
Get your copy »