Litigation Hold and Data Immutability

Why A Litigation Hold does not Meet the Regulatory Definition of Data Immutability

For a number of years, many storage vendors, as well as industry pundits, have misused the term "immutable" in the context of non-erasable and non-rewritable storage.  “Immutable” is used recklessly and incorrectly, in an attempt to define immutability as a storage process that makes the changing or deletion of a file more difficult for the average non-technical user.

Immutable storage has a precise meaning in the storage and compliance industries: that data, once written, cannot be deleted or altered – by anyone or anything for a pre-determined length of time. The notion of data being altered by “anything” becomes increasingly important as organizations embrace the opportunities presented by artificial intelligence (AI) and machine learning (ML).

Requirements for Data Immutability in the Financial Services Sector

Immutable storage became a focus of companies in the Financial Services industry decades ago when the SEC Rule 17a-4 included the requirement that regulated electronically stored information (ESI) must be stored on a write-once-read-many media such as optical WORM media. The SEC language around the immutable storage requirement for "books and records" was specifically designed to ensure that electronic records are maintained in an unalterable form for the required retention period in order to be accurately reproduced for later reference.

In a 2003 informational release, the SEC stated that certain implementations of rewriteable and erasable media, such as magnetic disk or magnetic tape, met the requirements of a non-erasable and non-rewriteable recording environment provided the storage solution delivered the prescribed functionality, and the functionality was delivered via appropriate integrated control codes for the SEC-designated retention period associated with the stored records. The guidance included the following description:

"A broker-dealer would not violate the requirement in paragraph (f)(2)(ii)(A) of the rule if it used an electronic storage system that prevents the overwriting, erasing or otherwise altering of a record during its required retention period through the use of integrated hardware and software control codes."

This guidance may have shed some light on the financial services definition of immutability back in 2003.  Today however, as organizations (not just in the FinServ sector) increasingly adopt cloud computing and need to address new requirements for data security, privacy and what it means to manage legal holds in the cloud, it  also raises additional questions, such as:

1. Do you have SEC Rule 17 retention requirements?
2. Do legal holds by themselves meet the definition of immutable storage for FinServ regulations?
3. Does data encryption make a file completely immutable?
4. How do you utilize immutable storage in Office 365 and the Azure Cloud for regulatory compliance?

A litigation hold is not the same as immutable data storage

In recent years, some vendors and industry pundits have claimed that placing a legal hold (also referred to as a litigation hold) on an electronic record – be it a file, an email, or an entire mailbox - somehow makes it immutable.  That the ESI is undeletable and unchangeable by anyone for as long as the legal hold is in place. This claim is incorrect! Here’s why: if the legal hold can be removed (thereby removing all protections for the file), by anyone, before a preset retention period has been reached, it does not meet the definition of SEC immutability.

Let's take a closer look at this claim.

Defining ESI Litigation Holds

Traditionally, a legal hold requirement is triggered when a company anticipates or is, in fact, served with a notice of an upcoming lawsuit. The responding party's legal duty includes protecting all potentially relevant data or content that could relate to the lawsuit (referred to as “responsive data”). The legal hold process includes searching all data repositories where relevant data could be stored.  This includes but is not exclusive to email systems, local hard drives, share drives, corporate and personal cloud repositories, and SharePoint servers. Once a good-faith attempt has been completed, the relevant data is then moved into a protected repository (such as a password-protected legal department file share) to ensure it is not deleted or changed in any way.  This includes providing all original file metadata that must also remain unchanged.

Legal Holds, Office 365 and the Cloud

As companies have adopted Microsoft’s cloud-based Office 365 platform for email, cloud storage (OneDrive), and additional office productivity, the challenges of protecting potentially responsive data in Office 365 has also grown. Office 365 makes it possible for eDiscovery case managers and other authorized individuals to search custodian mailboxes, OneDrive accounts, Team accounts, and SharePoint content for litigation-related content. Once the relevant data is found, Office 365 allows for in-place legal holds on the data. Each file placed on litigation hold cannot be deleted or edited by unauthorized employees for as long as the Office 365 litigation hold is in place.

An important part of the legal hold process is the eventual removal of the legal hold so that the released data can be moved back into the data's normal retention/disposition process. In fact, many legal holds are removed as soon as the eDiscovery phase has been completed to protect against inclusion in a future legal hold.

In looking at the litigation hold process, the fact that the eDiscovery case manager, paralegal, corporate attorney, or even a company IT administrator can remove a litigation hold means an Office 365 litigation hold cannot meet the SEC Rule 17 definition of immutability, i.e., guaranteed "copy of record" status until the retention period ends. Legal holds play an essential part in the eDiscovery process, but they are not meant to be a replacement for true irreversible, immutable storage.

Data Encryption, Immutability and SEC Rule 17a-4

Some of our largest banking customers have asked me about the role of file encryption.  These organizations are looking to encrypt their data as part of a data governance and archiving strategy and want to encrypt their data before it is stored in the cloud.  The question, therefore, is can encryption provide irreversible data immutability? 

File encryption plays a vital role in data security and can also play a role in ensuring "copy of record" status for records. Encryption of data while at-rest and in-transit, as well as granular role-based access controls, can ensure your data, stored in the cloud, will be mostly secure, unreadable and unchangeable, from unauthorized personnel. Many IT personnel refer to this process as immutable data migration and storage. This makes sense in that an encrypted file cannot be viewed, edited, or otherwise changed without first being decrypted. In that sense, an encrypted file is immutable to a certain extent. However, encryption cannot prevent a file from being deleted, so therefore, does not meet the definition of immutability for SEC Rule 17a-4.

Office 365, Preservation Lock and Azure Cloud immutability

While Office 365 legal holds can protect your Office 365data (Exchange Online email, OneDrive files, Teams data, or SharePoint data) from accidental or intentional deletion or spoliation, it does not meet requirements for compliant WORM storage.

Thankfully, Office 365 does offer a WORM capability called Preservation Lock across all Office 365 storage tiers to meet SEC Rule 17 a-4 data immutability requirements:

• All records stored using Preservation Lock are retained in a dedicated storage area out of the reach of the ordinary user. Only authorized users can access and search these records but cannot alter or erase them.
• Metadata for each item includes a timestamp used in the calculation of retention durations. Timestamps are applied when a new item is received or created and cannot be modified or removed from the metadata.
• The Office 365 Preservation Lock feature allows administrators to designate whether to make the retention policy a restrictive SEC Rule 17 compliant policy. A restrictive policy prohibits anyone from having the ability to remove, disable, or make any changes to the retention policy. This means that once Preservation Lock is enabled for email and files, it cannot be disabled, and no mechanism will exist under which any data from existing custodians that has been collected by the WORM retention policies may be overwritten, modified, erased, or deleted during the preservation period. Additionally, the retention period set by Preservation Lock may not be shortened or decreased. Preservation Lock ensures that no one, not even administrators or those with specific control access, may change the settings or overwrite or erase data that has been stored. This ensures regulated files in Office 365 will meet the requirements set forth in the 2003 Release of SEC Rule 17a-4. Office 365 Preservation Lock can encompass data stored in Exchange Online archiving, Teams, SharePoint Online, and OneDrive for Business. For the legal opinion on the SEC Rule 17 compliance requirements and Office 365, you can read the opinion from the law firm of Covington & Burling LLP.

Azure data immutability

In addition to Office 365, the Azure Cloud now offers immutable storage capability to meet regulatory requirements, including for SEC Rule 17 a-4 and MiFID II.

This Azure Immutable Blob Storage capability enables organizations to store and lockdown business-critical and regulated data in a pure immutable (WORM) state for specified retention periods. For the duration of the retention period, Azure blobs can be created and read but cannot be modified or deleted by anyone, until the retention period on a specific file has been reached. Azure immutable storage can be enabled in any situation to protect sensitive data against modification or deletion and is available in all Azure regions.

As with all immutable storage operations, administrators must be careful when designating data be stored in immutable storage. Once written to WORM storage, the data cannot be deleted or changed until the retention period has expired - period.

Immutable cloud archiving for regulatory compliance

Over the years, organizations operating in the financial services industry have had to adapt to changing regulations and emerging storage technologies to ensure they not run afoul of the various agency regulators. Over the decades, storage technology has transitioned from paper records to microfiche, to optical write once read many storage, to specialized disk arrays such as the EMC Centera Compliance Edition (a hard disk-based WORM storage array), to now cloud-based WORM storage.

In 1997, the SEC amended paragraph (f) of Rule 17a-4 to allow broker-dealers to store records electronically. The SEC did not limit broker/dealers to one specific technology such as write one optical disk but instead allowed them to employ any electronic storage that stores regulated records in a non-rewritable, non-erasable format.

However, Rule 17a-4(f) and SEC guidance memos specifically notes that storage systems that only mitigate the risk a record will be overwritten or erased are not compliant. Such systems - which may use software applications to protect electronic records, such as authentication and approval policies, passwords, or other extrinsic security controls - do not maintain the records in a manner that is non-rewriteable and non-erasable. For example, non-compliant storage systems might limit access to records through the use of passwords, or they might create a hashed "fingerprint" of the record based on its content. The ability to overwrite or erase records stored on these systems makes them non-compliant with Rule 17a-4(f).

Although SEC Rule 17 is one of the most prescriptive federal regulations, it still left the WORM technology requirement open to interpretation – causing many companies to spend money on technology that didn't meet the actual intent of the regulation. Remember, the intent of SEC Rule 17 a-4 is to ensure that broker/trader communications cannot be altered or deleted to defeat SEC investigations based on client complaints.  

Archive360's Archive2Azure intelligent information management and archiving platform was architected as a native Azure application to be installed and managed out of the customer's own Azure tenancy. This innovative design provides a much higher level of security, provides the customer direct management of their sensitive data, and allows clients to take full advantage of Azure's immutable blob storage for those organizations that have CFTC Rule 1.31(c)-(d), FINRA Rule 4511, SEC Rule 17a-4, and MiFID II WORM storage requirements.

Please contact us for more information on how Archive360 and Archive2Azure can help you meet your immutable data storage requirements.