One, two, three…steps to improve your eDiscovery review database security

There are many good reasons to be proactive when it comes to securing our data everywhere it lives.  In legal matters, we go from legal hold, collection, processing, publishing, to an eDiscovery review platform, and then to document review and production. Each step in this transition poses potential security risks. The ideal is to retain strong protection end to end throughout this process. 

There are options to keep data on legal hold within the same umbrella of security.  And there are options to keep data secure during the collection phase.  For example, software like OpenText Encase eDiscovery^TM offers multiple security options for this process.  When it comes to recreating this security within your document review database, there are some additional steps that should be considered.

Before you begin, be sure you have pre-identified all data sets that require additional security.  This may include data with personal identifiable information (PII), trade secret and/or proprietary information, legal requirements regarding access, and the like.  If you can’t pinpoint all of it by data set, don’t worry.  Step Three below has you covered.

Step One – Data Staging

You can easily have more than one staging area for data ingestion/loading purposes.  For instance, there can be a general staging area where most data are staged and another staging area for data requiring more security.  The latter would limit access to a smaller pool of dedicated people needed for managing the data.  Other security elements can also be applied, such as user citizenship or geographic location.

Pro Tip:  If the data is in an encrypted container or a forensic image, stage it without extraction.  The container/image provides additional security and most data processing software can handle decryption and mounting as part of the process.

Step Two – Data Processing & Publish to Review

When data from your secured staging area is ingested or processed, your processing/ingestion software should have options to automatically create a special metadata value that flags these records as “Sensitive Data” or some similar identifier.  Then, knowing in advance what that value will be, you can create additional security settings within the database based on a search for these records.  If you are using both a processing/ingestion database and a review database, the same security settings can be applied to the review database.  This database-level security can be used to limit the users that have access to these records as well as what can be done with them (e.g., printing, downloading, etc.).

For example, in OpenText^TM Axcelerate Ingestion^TM the Load Batch field can be used to apply a field value (e.g., “Sensitive Data”) that identifies these restricted records at ingestion.  Alternatively, the folder path to this secured staging area may also be used to identify these particular records.  Once the method for identifying these records is determined, then a search-based security setting can be created that will be applied automatically as data is loaded/ingested. Then the same search-based security settings can be applied to either/both OpenText^TM Axcelerate Investigation^TM and OpenText^TM Axcelerate Review & Analysis^TM so subsequent publishes of records will result in the same automatic security application.

Step Three – Review Process

Prior to beginning the document review process where many more users will have access to these records, additional security measures may be applied to further limit the data’s exposure. 

First, consider applying redactions in bulk in advance of review.  Some Review database systems allow for redaction in bulk based on many criteria that can be used to pre-redact records with privileged content, PII, proprietary information, etc. using regular expressions or RegEx pattern searching.  These redactions can be verified by the appropriate team members to ensure accuracy.  Another use case for applying bulk redactions is to create sanitized versions of records. Once the redactions are branded in, these images can be exported for other uses (e.g., exported for review in another country or to populate into a separate database requiring less security).

Second, use your review platform’s AI to identify further potentially sensitive records.  For example, Axcelerate Investigation and Axcelerate Review & Analysis uses both Magellan Text Mining^TM and RegEx Pattern Search to capture common PII values.  And the RegEx Pattern Search is fully customizable for better precision that best suits your data set.  This functionality can be used to supplement the identification of sensitive data and to automatically apply further security similar to the database settings described in Step Two.  And, better yet, the RegEx Pattern Search results can be used in Axcelerate’s global redaction feature.

Pre-Planning is Key

Keeping our data secure has become a fundamental need across industries.  A little pre-planning in our eDiscovery database setup and review workflow process will provide the additional safeguards we need at the right time.  Be creative and use all your review tool’s bells and whistles to expand upon these one, two, three steps.