Write once read many (WORM) storage is an essential capability for compliance requirements such as SEC Rule 17a-4.

At HubStor, we receive a constant flow of inquiries from IT, data security, and compliance leaders in search of immutable storage. They often want to achieve WORM compliance storage in the cloud with Microsoft Azure and bypass the usual headaches associated with satisfying these requirement on premises.

In this post, we will discuss the WORM storage requirement and how you can support it in the cloud with Azure and HubStor. 

What is WORM storage?

WORM just means that the data written to the storage media is immutable. No changes can occur. A file can be read as many times as necessary, but it cannot be overwritten, deleted, or modified in any way.

Disk-based WORM storage was popularized by EMC’s Centera product line in the early 2000’s. The precedent exists that storage media which is inherently not WORM compliant (e.g. hard disk drives) can be accepted as WORM provided that it has a software layer that governs access, deletion, and auditing in a compliant manner.

WORM retention periods

With solutions that rely on software to achieve WORM compliance, you will typically find the concept of WORM retention periods. Retention periods define how long a particular item must be held in a WORM state. When the retention period expires, the item is eligible for deletion.

According to SEC rules, retention periods can be lengthened but never shortened.

Redundancy

Another standard compliance requirement that accompanies WORM is redundancy. Content and indexes should be maintained with replicas. In Azure, synchronous storage redundancy on block blob storage and active geo-replication on the databases meets the requirements conveniently.

HubStor’s Azure WORM storage feature

By design, with versioning enabled, HubStor is a read-only archive system. Any changes to a file result in a new version write to storage with a version history for tracking.

HubStor does include a central deletion feature that is secured with authorization and an immutable audit trail. To meet WORM requirements alongside the deletion function, HubStor’s WORM policies ensure content does not purge before it is eligible for deletion.

There are two types of WORM policies in HubStor:

1. Item-level WORM – Granular policies that can evaluate access rights, folder location, and any item-level attributes to output particular WORM retention periods on individual files.

2. Storage account-level WORM – Specifies a standard retention period for all items within the storage account.

Most HubStor clients that need WORM retention controls use item-level WORM because of its flexibility.

Both WORM options in HubStor evaluate in real-time during the writing process to Azure.

Event-based retention

HubStor includes a patent-pending feature for managing event-based retention. Our approach simplifies event-based retention by removing the need to occasionally extend retention periods on WORM protected items before their final retention period is defined.

You can trigger event-based retention using any metadata, including custom attributes. For instance, if the content has an associated AccountID, this can be enabled for event-based retention so that when a client account closes you can quickly look up all the content relating to that account and trigger the final retention period.

Advanced data management and auditing

Eventually, you will want to audit WORM retention periods in your archive to report on data volumes and retention workloads.

Managing content deletion is another important task – as retention periods expire, you will want to maintain a close watch on content that is free for removal and defensibly purge it.

HubStor’s data-aware storage concept gives you a complete visualization of what is in your archive. You can query the storage to model policies, generate reports, and perform investigations.

Azure deployment requirements

HubStor lets you bring your Azure account, or your HubStor tenant can run under HubStor’s Azure account.

Today, clients that need Azure WORM storage compliance run under HubStor’s Azure account because this ensures their access to the data is strictly through HubStor’s interface. Otherwise, if deployed in an account the client controls, they would have direct access to the blobs in Azure storage and technically have the ability to bypass the software’s WORM controls.

The future of Azure WORM storage

We expect Microsoft to add WORM functionality to the blob storage layer in Azure in the future because there is significant demand for it and Amazon Web Services (AWS) has already ticked the checkbox.

At HubStor, this possible enhancement in Azure will allow us to meet the WORM requirement in a client’s Azure account. We do not see WORM features in Azure as competitive to our WORM capabilities. Instead, they are harmonizing because Azure WORM needs a solution like HubStor to be turnkey and HubStor’s WORM solution benefits by way of added WORM protection that trickles down the stack to the cloud infrastructure.

Whenever Infrastructure-as-a-Service (IaaS)-level enhancements come out that seem to overlap features at the Software-as-a-Service (SaaS) level, we have to remind people that functions available at the infrastructure level are not turnkey or user-friendly for business use cases. The application software layer needs to plug these capabilities into workflows and interfaces that are meaningful to the business.

Letter of attestation or compliance certified

When it comes to WORM compliance requirements, we often hear questions like, “is your technology certified for compliance with [name the regulation that requires WORM].”

It is important to understand that the regulatory bodies that put forward WORM compliance requirements do not certify or endorse particular vendor technologies. Furthermore, the technology itself does not fulfill the requirement of compliance entirely – it is a combination of process and technology.

Your compliance requirements may stipulate that the WORM technology vendor must attest to the regulatory body that their solution meets the WORM requirements. Even if the regulatory body does not require such attestation, it is a good idea to obtain this from your vendor for your records.

Vendors might also commission a third-party to evaluate their technology’s fit for a compliance standard. The third-party might issue an opinion or statement that can help you sleep better at night.

Designated third party or Business Associates Agreement (BAA)

SEC/FINRA rules require a designated third party (D3P) that can satisfy audits and requests for information in the event the regulated entity is non-responsive. In the case of cloud services, D3P is often included by the vendor as an add-on service.

For HIPPA, a similar construct exists and is referred to as a Business Associates Agreement (BAA). The BAA covers a broad spectrum of data security requirements about Personally Identifiable Information (PII) as well as audits and investigations. The BAA is not typically an add-on service like D3P, but instead a contractual requirement to do business.

Next steps

A good SaaS WORM solution in Azure will give you policy controls, data management, query, analytics, and auditing over top of the IaaS-level WORM protection. Moreover, if WORM features are not there yet in the cloud infrastructure, HubStor can make it happen as long as your HubStor tenant runs in HubStor’s Azure account. If Azure adds WORM features to blob storage in the future, you can bet HubStor will tightly integrate it.

Learn more

Want to learn more about Azure WORM storage?

Contact us today to obtain access to the 'Solution Guide: Azure WORM Storage and Litigation Hold'.

You can also schedule a demo to see Azure WORM storage features in action.