Why does electronic evidence multiply? Why does it move or get renamed or even deleted? It does not do it on its own… so who is responsible and why?

The storing and management of electronic evidence has been an important topic for litigation support, legal and IT teams for many years. The most common issues for each group surround how best to manage and control the information for ongoing use by the appropriate people without letting it get out of control. Some commonly raised questions are:

  • Where is the data housed on the servers?
  • Where “should” it be housed?
  • How many copies of the data get made by the various interested parties?
  • How long does the data reside on the servers?
  • How is the data archived, if at all?
  • What security is, or should be, applied to the data?
  • Why has it been moved, renamed or even deleted?

The best way to address these questions is to develop and implement a set of best practices for the handling of electronic evidence:

1. Intake

  • Inventory the evidence and store for control and review purposes.
  • Record the location of all evidence stored.
  • Record who has access.

2. Storage

  • Create a location on the appropriate server(s) that will be the “forever home” for the data.
  • Create a project folder and sub-folder structure that is replicated for all evidentiary storage projects.
  • Identify location(s) that will be accessible for all internal litigation support applications such as processing, review tool access, etc.
  • Legal teams should not have unrestricted access to the source data repositories. They should also refrain from creating copies of the source data on server locations, other than known locations established by IT and/or litigation support staff.
  • Clean up and moving of source data, while done with the best of intentions, has been the cause of many a headache when applications fail to recognize the new location of source data. Further complications arise when no one knows where data went so that application remediation and archive or destruction requests are not able to be performed adequately.

3. Security

  • Apply the requisite security to the data storage location.
  • Review any conflicts and/or ethical walls that need to be applied and apply them.
  • Data that is not appropriately secured or secured only based on application access can cause problems when well-meaning staff who should not have access will locate source data and either move, delete or rename it for their use.

4. Duplication, Sub-Sets, Working Sets

  • Do not create multiple copies of the same data set for use.
  • IT directors and CIOs generally find themselves having to purchase additional storage because of the replication of evidence across their server farms.
  • Working copies or working data sets should be deleted upon completion.
  • If working sets are required to be saved they should remain under the main project folder heading for management and control.
  • Duplication required for processing output and review tool loading should be managed by the litigation support staff and controlled carefully if the application tool does not integrate with the processing application.

5. Review Tool Access

  • It is essential that evidence sets used to populate internal review tools do not get moved.
  • All data sets used to populate review applications should be secured for limited access by litigation support and/or IT staff only.

6. Production

  • Production data should be saved within the litigation support folder structure.
  • Legal team access to production data should be managed pursuant to internal procedures.

7. Backups

  • Initial backup of the complete evidence folders is an essential part of the IT process.
  • Other backups should only capture changes made as part of the review process, if new data has been added, etc.

8. Archiving

  • Frequent analysis of data repositories should be performed.
  • Internal parameters should be set to identify old and non-active projects that can be archived or deleted if clients agree.

While the above list may seem obvious the practical application of these are few and far between. Data can and should be managed and secured.