There are many good reasons to be proactive when it comes to protecting our data wherever it may be. In legal matters, we moved from legal hold, collection, processing, and publication to an eDiscovery review platform, and then to document review and production. Each step in this transition poses potential security risks. Ideally, maintain strong end-to-end protection throughout this process.
There are options to keep data on legal hold within the same security framework. And there are options to keep data secure during the collection phase. For example, software like OpenText Encase electronic discoveryTM offers multiple security options for this process. When it comes to recreating this security within your document review database, there are a few additional steps to consider.
Before you begin, make sure that you have previously identified any data sets that require additional security. This may include data with personally identifiable information (PII), trade secret and/or proprietary information, legal requirements regarding access, and the like. If you can’t identify everything 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 ingest/load purposes. For example, there might be a general staging area where most of the data is staged, and another staging area for data that requires more security. The latter would limit access to a smaller group of dedicated people needed to manage the data. Other security elements may also apply, such as the user’s citizenship or geographic location.
Pro Tip: If your data is in an encrypted container or a forensic image, stage it without extracting it. 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 and Posting for Review
When data is ingested or processed from your secure staging area, your ingest/processing software should have options to automatically create a special metadata value that marks 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 lookup of these records. If you are using both an ingest/processing database and a patching database, the same security settings can be applied to the patching database. This database-level security can be used to limit the users who have access to these records, as well as what can be done with them (eg, print, download, etc.).
For example, in OpenTextTM speed up ingestionTM the Batch Upload field can be used to apply a field value (eg « Sensitive Data ») that identifies these restricted records in ingestion. Alternatively, the folder path to this secure staging area can also be used to identify these particular records. Once the method for identifying these logs is determined, a search-based security configuration can be created that will be applied automatically as the data is loaded/ingested. Then the same search-based security settings can be applied to one or both open textTM speed up researchTM and open textTM Expedited review and analysisTM therefore, subsequent log postings will result in the same automatic security enforcement.
Step Three: Review Process
Before beginning the document review process where many more users will have access to these records, additional security measures can be applied to further limit data exposure.
First, consider applying bulk redactions before the review. Some Review database systems allow bulk redaction 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 matching. These redactions can be verified by the appropriate team members to ensure accuracy. Another use case for applying bulk redactions is creating clean versions of records. Once redactions are flagged, these images can be exported for other uses (eg, export for review in another country, or to fill in a separate database that requires less security).
Second, use your review platform’s AI to identify more potentially sensitive records. For example, Axcelerate Investigation and Axcelerate Review & Analysis both use Magellan Text MiningTM and RegEx Pattern Search to capture common PII values. And the RegEx pattern search is fully customizable for more precision that best suits your data set. This functionality can be used to supplement the identification of sensitive data and to automatically apply more security similar to the database setup described in Step Two. And even better, the results of the RegEx pattern search can be used in Axcelerate’s global compose function.
Planning ahead is key
Keeping our data secure has become a fundamental need in all industries. A little pre-planning in our eDiscovery database configuration and review workflow process will provide the extra protections we need at the right time. Get creative and use all the bells and whistles of your review tool to expand these one, two, three steps.