Migrated from eDJGroupInc.com. Author: Greg Buckles. Published: 2010-05-18 13:20:17Format, images and links may no longer function correctly. In my consulting practice, I frequently work with corporate legal departments to select and prepare their designated ‘IT Custodians’ who will have to sign affidavits and may be deposed/testify as a Rule 30(b)(6) witness. Historically, these designated subject matter experts covered accounting systems, business practices and other complicated areas relevant to the issues at the heart of a matter. The enterprise ESI lifecycle itself has become so complicated that every preservation or collection request may now require a translator to effectively communicate all the implications of system configurations, user actions and discovery technologies on the scope and format of response efforts. I am always amazed at what floats to light when we get down to specifics on exactly how IT has been carrying out Legal’s requests. Corporate IT administrators must constantly balance user requirements/requests against the realities of system and resource capabilities. Many fall into the trap of assuming that their users cannot understand the complexity or scope of requests, so they apply their best efforts without communicating caveats, restrictions or options back. But what you do not know can indeed come back to haunt you. With Exchange/Sharepoint 2010 about to be released, many corporations are looking to migrate content management/archiving systems while they are under existing legal holds. The time to ask hard questions of your system administrators is prior to any conversion or movement of data, not after the damage has been done.
In the eyes of most users and IT admins, there is no effective difference between an email in a Domino mailbox and the same email in an Exchange mailbox. Most discovery platforms were designed to deal with Microsoft mail storage formats like PST, MSG and EDB. They have to ‘normalize’ or convert the fields so that the messages can be processed. This is not a perfect process. The same ‘field mapping’ methodologies apply to most system migrations and can even happen with major upgrades. Enterprise environments are dynamic, evolving information ecosystems. This has driven many of the ‘preservation products’ like StoredIQ and EnCase Enterprise to focus on collection of a preservation copy instead of trying to ‘preserve in place’. My point here is that it is just not feasible for IT to freeze a working system. Keeping daily/weekly/monthly tapes may still allow items to fall through the cracks and creates a monster bill if you ever have to restore those tapes. Archives and content management systems may preserve content, but any major upgrade or migration should be tested and documented by someone who understands the standards of evidence and can communicate potential changes to counsel for the appropriate risk /cost decision.
With overlapping legal holds as a fact of corporate life, how can you evaluate the potential impact of system changes and migrations?
- Designate a technical point of contact and approval requirement as part of your IT Change Management system. There should be clear threshold criteria so that the person on the hot seat does not have to approve help desk tickets, but they should be in the decision loop for anything that has the potential to destroy or alter ESI.
- Having a central Data Map that tracks holds makes decisions a lot easier. The map should be maintained by IT, while Legal should manage the holds. This can be as simple as a database or even spreadsheet of primary systems and data sources.
- Run samples of known ESI through any upgrade or migration process in your lab environment. Remember that this is not performance testing, so a virtual environment will suffice.
- Have your outside counsel, service provider or a third party consultant do a fast analysis of the original and new ESI samples. This is not a requirement, but it will make the documentation process a lot easier and goes a long way to show that you were serious about your preservation obligations. Remember to test the content and the context of the samples. So hash, header and OS metadata all need a comparison.
- Consider a clean offline back up prior to migration if that is practical given the scope of the system. Remember that the problems with reconstructed or transformed ESI can be very subtle and are often not important. If you have an ‘inaccessible’ copy, then the plaintiffs are unlikely to push as hard. If you have not recovery option, then they can make lots of noise about what ‘might’ be there, so they have the incentive to push the issue.
- Create a summary memo of any proposed changes and send this all outside counsel. They can make the decision as to whether it is relevant or what should be disclosed to the opposing parties. Keep this as simple and factual as possible. Include samples that are safe to share with the other side.
You can see that the crux of change management under legal holds is communication, communication, communication. Your IT admins need to have a mandate to ask before taking actions that might cause ESI loss or spoliation, but that means that Legal has to be able to translate potential impact into a risk decision and make that decision in a timely fashion. IT will stop asking if Legal becomes a road block to keeping the infrastructure healthy and growing.