In part two of this two-part series, I discuss the e-discovery process (EDRM) and highlight two common e-communications archiving architectures used by organizations today as part of their e-discovery strategy. If you missed part one, check it out here.

The e-discovery process

The EDRM (Electronic Discovery Reference Model) acts as a guideline, representing the different steps that one might follow as part of the e-discovery process. The EDRM is flexible and iterative by nature – flexible in the sense that you are not required to follow each stage and iterative because it allows you to switch back and forth between different stages. As you go through each stage of the EDRM, you should see a reduction in volume and an increase in relevance of the data under consideration.

Source: www.edrm.net

Source: www.edrm.net

The different stages of the EDRM are:

  • Information Management – Organizing your electronic data and preparing a strategy for managing future potential e-discovery.
  • Identification – Looking for ESI (Electronically Stored Information) within your organization and understanding what you have.
  • Preservation – Making sure that your ESI is properly protected against inappropriate alteration or destruction.
  • Collection – Gathering ESI for use in other stages of the e-discovery process (e.g. processing).
  • Processing – Reducing the volume of ESI (e.g. de-duplication) and converting it to other formats.
  • Review – Reviewing ESI to determine its relevance and privilege.
  • Analysis – Analysing data content & context (topics, people, discussion).
  • Production – Delivering ESI to others in a suitable format and appropriate way (e.g. securely and ensuring integrity).
  • Presentation – Presenting relevant ESI in court or as part of an investigation.

Archiving architecture

While each organization will tailor its archiving infrastructure according to its specific business requirements, there are typically two common architectures that are used.

Hosted Messaging Archive Solution

An organization may choose to rely on a third-party vendor to host their e-communications in a cloud-based environment (as shown in the image below).

hosted_archive_solution

 

 

With reference to the above image, the typical flow of a message sent by an internal user would be as follows:

(1) User sends a message to a number of internal and/or external recipients
(2) A copy of the message is kept in the ‘messaging store’
(3) The original message is delivered to the intended recipient(s)
(4) Ingestion occurs at regular intervals to move the messages from the ‘messaging store’ to the archive servers in the cloud.

On-premise Archiving Solution

On the other hand, some organizations choose to retain control of their messaging archive and implement an archiving solution within their own environment (as shown in the image below). 

onpremise_archive_solution

With reference to the above image, the typical flow of a message sent by an internal user would be as follows:

(1) User sends a message to a number of internal and/or external recipients
(2) A copy of the message is stored in the database as it flows through the system
(3) The original message is delivered to the intended recipient(s).

In both situations, messages can be tagged with meta-data to make them more easily
searchable in the future. For example, if an e-mail was tagged with a user’s UserID or mail group membership information, you could use these properties to search for all e-mails where this particular UserID or mail group were senders or recipients of the message.