The increased adoption of the cloud and its impact on eDiscovery was a hot topic of discussion in a recent webinar featuring Dr. Gavin Manes, Avansic’s CEO, Doug Austin of eDiscovery Today, and Jack Petracek of Armstrong Teasdale.
During the webinar, the panelists talked about major eDiscovery issues in the recent case Cabo Concepts Ltd. v. MGA Entertainment. In this case, a Microsoft Outlook desktop client was used for searching and collection. Although this is certainly not the first time Outlook has been used for eDiscovery data collection, it has fallen out of favor because of the way it indexes data or – perhaps more importantly – how it chooses not to index data. Outlook cannot perform optical character recognition (OCR) on non-character types, so it can’t search documents that don’t have text it can extract, for example, a scanned document or inbound fax that came as an attachment to an email. It also does not have a method of identifying the documents it wasn’t able to index, which results in silent failures. When a program fails without alerting a user, unexpected outcomes abound, which is not an ideal circumstance in eDiscovery and beyond.
Fortunately, there are abundant tools and workflows for eDiscovery that most of the industry has adopted. But it is true on the road and in eDiscovery, that great cars can have bad drivers. Looking again at Cabo Concepts Ltd. v. MGA Entertainment, they used Office 365 to search for email in select date ranges. O365 can be a fantastic tool for eDiscovery in the right situation, but in this case, they used the creation date of the email for filtration instead of the sent or received date. This mistake was correctly labeled as a “rookie error,” but with an appropriate workflow alongside it, the misstep would have been caught. Filtering, in this case, occurred before the data was exported, purportedly to save on cost, which would have been fine had the filtering been appropriately applied. It’s a good lesson in understanding effective searching and the limitations of platforms like O365, Google Vault, and iCloud.
With O365, there are well-documented search limitations and published workflows that account for these limitations. The most common is the lack of an OCR engine that creates searchable text from non-searchable documents with text (such as scans or faxes) – this is the same as Outlook. But the crucial difference is that O365 identifies these items as non-searchable and allows users to download those items as part of the larger search in order to address exceptions in other tools. Another needed step is building a specific syntax to search for communications between parties. This is based on the use of “distinguished name format,” which may not include an email address or name. Therefore, the syntax needs to include an item from the header that meets the necessary criteria.
The most common mistake made by O365 users is the limitations of the search syntax. Proximity searches are not possible, so if a user is looking for “cat” within five words of “dog,” they would have to search for cat and dog and then use a tool that supports the proximity feature to perform a final search. This workflow solves one of the issues in Cabo Concepts Ltd. v. MGA Entertainment, but it would require exporting the general searches from O365 and then narrowing them down in an eDiscovery tool. Note that in some cases, the types of searches that can be performed in O365 are directly related to the license type.
On the webinar, the presenters agreed that sometimes cloud tools can be helpful in eDiscovery but only if they are used in conjunction with experienced users, robust workflows, and a solid understanding of their limitations. With these three factors in place, the pitfalls of the Cabo case can be avoided, putting eDiscovery success closer at hand.