eDiscovery Productions in Business Productivity Suites: Truly End-to-End?

By |2020-11-03T19:58:54+00:00November 2nd, 2020|Categories: eDiscovery|Tags: , , , , , |

I work with many clients that implement cloud-based messaging and storage systems like Microsoft 365 (M365) and Google Workspace to manage their enterprise. I’m a proponent of moving enterprise systems to the cloud and generally encourage IT organizations to consider all manner of cloud solutions. Legal hold and eDiscovery needs are often secondary (or tertiary or not even considered) in the decision to move messaging and storage to the cloud especially when an organization is not regularly dealing with eDiscovery or data subject access requests (DSAR). Do these tools help enable an “End-to-End” eDiscovery workflow? My definition of an “End-to-End” eDiscovery solution starts with legal hold, data identification, data processing, data review, data search (basic and advanced), and data productions. Based on that definition my answer is no specifically because data productions require additional tools to meet the typical production obligations. Both M365 and Google Workspace have functionality to support legal hold, eDiscovery and data compliance at the tenant level. That equates to using the native index to search for responsive users and content which does not include non-indexable data. eDiscovery in M365 and Google Workspace were built as data triage tools to reduce the amount of information going into the expensive review process. The functionality to support that triage process is powerful with both tools in the hands of a practitioner that understands the nuances of the data workflow in these technologies. Producing data to requesting parties will require additional steps and/or technology depending on the requirements for the production. Production formats vary from case to case, but it is common to have a production specification for TIFF or PDF with native spreadsheet along with a load file. This is important especially with when markings (e.g. Bates stamp, etc.) or redactions [...]

M365 Advanced eDiscovery: Tipping Point?

By |2020-10-13T01:37:08+00:00October 13th, 2020|Categories: eDiscovery|Tags: , , |

I often have discussions with people looking to understand the eDiscovery space better as part of the eDiscovery Advisory Strategy Practice. One of the most recent conversations was around understanding how organizations that are doing in-house culling will impact the volume of downstream data going into the traditional eDiscovery process ending in contract review. Many of my clients over the years have implemented toolsi Nuix, Relativity, ProSearch, CloudNine Law, OpenText EnCase, Forensic Tool Kit (FTK) as well as legal hold tools like Zapproved, IBM Atlas, or Exterro to identify and triage data as part of the initial identification and collection process. It is my experience that the larger, highly regulated organizations typically have a mature workflow around data culling to reduce the data as early as possible in the EDRM lifecycle. But where does that leave the rest of the organizations in the corporate world where it doesn’t make sense to invest heavily in advanced eDiscovery technologies? What can these types of organizations do to cull data down by date, users, and search terms to reduce their downstream eDiscovery costs? I believe that Microsoft 365 (M365) may be the tipping point for smaller organizations making a significant dent in downstream eDiscovery data. M365 comprises of messaging (Exchange) and file sharing (OneDrive) along with underlying services like MS Office, SharePoint, and Teams. Underneath the hood is an indexing engine and administrative tools to manage all the data. eDiscovery functionality is found in the Microsoft Compliance Center which manages the data in the M365 ecosystem. Within the M365 Advanced eDiscovery technology (which requires an E5 license or comparable academic license) exists the functionality to search the indexable data stored in the Microsoft tenant as well as place the data on preservation/legal hold. From there [...]