A multi-matter repository (MMR) is a processing database that houses electronically stored information (ESI) that is potentially relevant to more than one matter.
Sharing and repurposing past work for present and future matters unlocks substantial e-discovery savings and reduces project management burdens—when properly managed.
In this article, we’ll discuss how a multi-matter repository can increase e-discovery efficiency in three ways:
- Reduce the administrative burdens that fall on corporate IT and forensics teams by repurposing ESI collections.
- Eliminate additional fees and project timelines by reutilizing processed data.
- Cut time and spend by using prior work product, such as privilege reviews and logs, in subsequent matters.
1. Reduce Administrative Burdens by Repurposing ESI Collections
Managing the ESI collection process is a significant undertaking for inside counsel, corporate IT, and forensics teams.
As a general workflow example, the first step is that inside counsel will conduct a custodian interview to learn where the data is located and how it is organized. Then, the IT team will confirm data destruction policies are turned off. Finally, forensic teams will begin to coordinate the collection of the custodian’s data with IT.
Each participant is responsible for burdensome and time-consuming tasks, and those tasks can be especially daunting when e-discovery collections are not considered a priority for each department and/or team involved.
When an MMR is in place, the collection process is much more targeted.
If there is a complete overlap in custodians and time frames, no additional collection work is required—the MMR already contains the data from previous collection. For example, this allows inside counsel to immediately focus on the merits of investigation or litigation, rather than allocating time to relocate and organize data collection. When maintained properly, this workflow matures to significantly reduce the burdens on each department.
SCENARIO 1
- Matter 1
- Custodians: A, B, C, and D
- Timeframe: 1.1.2019 – 12.31.2020
- Matter 2:
- Custodians: C, D, and E
- Timeframe: 6.1.2019 – 5.30.2021
Matter 1 and Matter 2 are already in your MMR. Then, a third related—or unrelated—matter appears.
- Matter 3
- Custodians: A, B, and D
- Timeframe: 4.30.2018 – 10. 31.2019
This scenario requires a refresh collection. Your MMR has the data for custodians A, B, and D from 1.1.2019 to 10.31.2019, making it unnecessary to recollect and duplicate that data. But, for Matter 3, the timeframe extends before the previous collection timeframe—as a result, you’ll need collect custodian data from 4.30.2018 through 1.1.2019.
2. Eliminate Additional Fees and Time by Reutilizing ESI
The multi-matter repository actively stores all ESI that was previously collected, ingested, and processed, therefore all future matters benefit from little-to-no ingestion fees or time constraints associated with processing. Data should never need to be collected or processed more than one time.
And remember, you own this data.
Whether you are a business conducting an in-house investigation or you are outside counsel representing that business, the MMR can and should leveraged. A single processing MMR allows internal investigators and external counsel to seamlessly access relevant data.
Also, outside counsel handling more than one matter for the same client can reutilize ESI. Here’s a scenario representing reutilization of ESI.
SCENARIO 2
- Matter 1
- Custodians: A, B, C, and D
- Timeframe: 1.1.2019 – 12.31.2020.
- Matter 2
- Custodians: C, D, and E
- Timeframe: 6.1.2019 – 5.30.2021.
Let’s say that all of the data for custodians A, B, C, D, and E has been collected and loaded to the multi-matter repository. The data has been processed, and all of the data is culled and filtered to remove digital debris.
Firstly, you should confirm that all subsequent matters agree on the definition of digital debris. For instance, digital debris could include irrelevant email newsletters from industry publications and associations, emails sent from news and media organizations, industry publications, and/or mass communications from internal distribution lists announcing company-wide initiatives.
If the definition of digital debris in a subsequent matter changes, you would need to remove filters in the MMR. Then, filters can easily be reapplied should you need to reapply in future matters.
Your data can be further filtered by keyword, concept, or other pre-review analytics. Remember, the data set in this scenario has already been cleaned of digital debris, so it’s a smaller subset of what was collected.
This data can be parsed so that each unique matter receives the appropriate custodian’s data from the appropriate timeframe.
Should Matter 1 and Matter 2 be related and include the same definition of relevancy, then both would benefit from secondary filtering. Otherwise, secondary filtering by keyword is a separate exercise for each matter.
3. Cut Time and Spend by Using Prior Work Product
More often than not, document review is the most expensive part of discovery. Therefore, reducing the number of files in need of review presents a significant cost-savings opportunity. Reuse of prior privilege review does just that. Should privilege review take place in a prior matter, the work product from that matter can be leveraged in every subsequent matter. Instead of pushing privilege review to the end of the overall document review, the MMR cuts this burden significantly at the onset.
The multi-matter repository assigns control the number for files in the database. When a file is promoted to the hosting platform, that same control number is logged so that it can always be traced back to the MMR. This is a crucial component to sharing subsequent work product. Because this key exists in the MMR, you can apply a privilege tag to a document if it is identified as privileged in any of your relevant matters, and reduce document review for those matters.
Be sure to confirm that privilege takes on the same definition for the matters at hand, there may be court orders or agreements between involved parties that modify the definition.
This is the most complex way to leverage the multi-matter repository, but it also provides high value and savings in both time and cost. That said, data retention and mirroring the corporate data retention schedule is something to consider.
SCENARIO 3
- Matter 1
- Custodians: A, B, C, and D
- Timeframe: 1.1.2019 – 12.31.2020.
- This matter commences on 1.1.2021.
- Matter 2
- Custodians C, D, and E
- Timeframe: 6.1.2019 – 5.30.2021.
- This matter commences on 6.1.2021
- Matter 3
- Custodians: A, B, C, D, E, and F
- Timeframe: 3.23.2019 – 6.20.2021.
- This matter commences on 7.19.2022
In this scenario example, the duty to preserve for Matter 3 does not commence until 18+ months after the MMR is created, while Matter 1 and Matter 2 are perhaps nearing their end.
You need to do a refresh collection for custodians during timeframe of 5.31.2021 to 6.20.2019, and a full collection for custodian F. Be alert to the first two matters and when those end. Discuss the need to purge data from the MMR from the date range that is no longer under preservation. In this case, that range is 1.1.2019 to 3.22.2019. An information governance consideration—if preservation is not needed, ensure that the data in the MMR is being retained in accordance with the corporation’s retention schedule.
Should the duty to preserve timeframe end, maintaining the data in the multi-matter repository outside of the corporate retention period could open up potential liability requiring re-preservation when a new matter arises.
However, should the data still be within the retention period, holding on to that data in the MMR may be beneficial to a future matter that has not yet appeared.
In that case, a Matter 4 will benefit from the prior collection, processing, and work product pertaining to the privilege review conducted in the previous matters.
In all of these scenarios, the multi-matter repository reduces burdens by optimizing workflows and cutting time as well as costs by repurposing data and leveraging prior work product.
