Exceptions in Ediscovery Searching

One of the key components of the electronic discovery process is the ability to cull and filter data. In an ideal world, your criteria would be run against easily accessible custodian data stores. With a few clicks of some fancy buttons, a relevant, pristine data set would be produced.
Alas, the real world rarely grants such a straightforward process. Discovery matters become more complex as data is collected from a cornucopia of electronic data sources using a variety of media. The processing of data can be fraught with issues small and large, running the gamut from inaccessible source data to corrupt, encoded or password protected files, invalid formats, even the inability to create export files.

It is up to the tools of the trade to help end-users address the issues and exceptions that are encountered during the standard collection and searching of data. While the quirks of electronic data make it next to impossible to avoid problems entirely, the strength of your electronic discovery process lies in the way these issues are handled and audited.

It is of paramount importance that exceptions be identified during processing. Without clear issue logging, it would be impossible to find and resolve the problems that do occur. For those items that can’t be resolved, methods to handle exceptions are essential. You don’t want one inaccessible data store to bring down a search that has been running for hours. Detailed reporting of the exceptions is key to helping keep a robust audit trail.

In addition to identifying exceptions, your ediscovery process should also clearly lay out alternate means of processing in case it is required. Equally, it would be beneficial to define the conditions under which these alternate methods will be employed. While every condition cannot be anticipated, clear communication will make the process run smoother. For example, if a number of password protected documents are encountered, making text search impossible, make sure all the stakeholders are clear on how these items will be handled and under what conditions (and cost) they might be reviewed or produced.

Within Sherpa Software’s Discovery Attender ediscovery solution, exceptions are entered into logs that can be accessed on a task or search level. A myriad of alerts for errors, skipped items or warnings can be produced on any level of a task. Examples include data store (Access Denied), documents (Unable to Parse, Encryption), folder (cannot retrieve list of items) or message (Corrupt Property) exceptions.

Once these issues are identified, Discovery Attender provides a number of features to help users further process data in accordance with their discovery plan. Data stores that were corrupted or encountered access errors can be identified and resolved. Then, Discovery Attender can rescan the source data stores for inclusion in the production set.

For document or message level issues, some users simply use the built-in reports to audit the problems. Others will take advantage of the unique export feature to create a separate collection of exception items for further processing.

Regardless of which tool you use to process data, if your ediscovery process is not clear on exceptions, more clarification (and therefore time) will be needed to respond to discovery requests. Ignoring this area can lead to gaps in the audit trail and, perhaps, adverse judgments.

The key point to take away is that exceptions will occur. Make sure that proper tools are in place to identify issues, along with a proper process to adequately address problems that arise. With the help of these two steps, collection and searching data becomes much less complex, and much more efficient, effective, and defensible.

Leave a Reply

Your email address will not be published. Required fields are marked *