Immutable Cloud Backups: Six Tests to Verify That WORM Storage Really Protects Your Data

The dashboard displays a reassuring message: Object Lock enabled, immutable retention or WORM. Then an incident occurs. A compromised administrator account tries to delete the backups, a bucket disappears from the inventory, an encryption key is no longer available, or the primary region becomes inaccessible. The question is no longer whether the provider offers an immutability feature. You need to verify what that feature really protects, against whom, for how long and with what evidence.

WORM means Write Once, Read Many: data can be written and read, but not modified or deleted during a defined period. This property is valuable against ransomware and administrative mistakes. It is also local to a specific boundary: an object version, a retention policy, an account, a key and sometimes a region. A backup can therefore be impossible to delete while still being poorly replicated, hidden after a logical deletion or unreadable when recovery is needed.

The right response is to turn the technical promise into a verification protocol. The six scenarios below do not replace the provider’s documentation. They force the team to compare that documentation with its own environment, permissions and crisis procedures.

1. Start by Defining What “Immutable” Must Prevent

Before running a deletion command, clarify what the test is meant to establish. An immutable cloud backup can provide several different protections, and they are too easily treated as one.

The first concerns the content itself: a given version must not be modifiable or deletable before its retention period ends. In Amazon S3, Object Lock works with versioning and protects a specific version through a retention period or a legal hold. The bucket is therefore not one uniformly locked container. Multiple versions and multiple states can coexist.

The second protection concerns duration. A time-based retention period sets a date until which the object remains protected. A legal hold keeps the lock in place until it is explicitly lifted. In Azure Blob Storage, time-based retention policies and legal holds reflect the same general distinction: a protected blob cannot be modified or deleted during the specified period or until the hold is removed, as described in Microsoft’s documentation on Blob immutability.

The third protection is administrative. Who can change the duration? Who can remove a legal hold? Who can delete the account, bucket or encryption key? A configuration that is fully protected against object deletion may still be vulnerable to a broader compromise of the environment.

Finally, there is recoverability. Immutability is not recovery. It does not prove that backup metadata is intact, that the catalogue can locate the objects, or that the key needed to decrypt them still exists. That is why every test should pair a hostile action with an expected result and retained evidence: an audit log, an API response, the version state, the retention date and the outcome of a recovery attempt.

2. Verify the Lock at Object Level, Not Only at Bucket Level

The first control is to follow a real backup from end to end. Create a test object or use a non-critical copy, activate the intended policy, then record its version identifier, retention end date and, where the scenario requires it, its legal hold. The aim is to answer a simple question: which exact data must survive deletion?

In S3, versioning is a structural requirement. A later write does not necessarily replace the protected version; it can create a new one. This preserves the earlier data, but it can also create operational confusion. Does the application or catalogue consult the correct version? A team that checks only that a new object is still accessible may miss the historical version it will need to restore during a crisis.

The test should therefore capture metadata before and after every action: version identifier, retention status, expiry date, presence of a legal hold and read result. Lifecycle rules also deserve review. According to AWS, they cannot delete a version that is still locked. However, a version whose retention has expired becomes deletable unless a legal hold remains active. An automated policy should not be treated as an independent guarantee: it follows the state of the lock.

The same reasoning applies to other clouds, even though their objects and policies have different names. Google Cloud Storage allows a retention policy to be locked at bucket level. Once locked, its duration cannot be reduced and the policy cannot be removed; the locked bucket also cannot be deleted until all its objects have satisfied their retention periods. This irreversibility is useful, but it also raises the cost of choosing the wrong duration. Test it with representative data and a known recovery procedure.

The evidence expected at this stage is not a screenshot. It is a reproducible file: the command or API call used, the identity that performed the operation, the response received, the corresponding logs and the state of the file after the read attempt. An audit can then distinguish an enabled policy from protection that has actually been observed.

3. Scenario 1: A Compromised Identity Tries to Shorten Retention

The first realistic adversary is not necessarily sophisticated malware. It is a legitimate account whose credentials have been stolen, or an access key that is too powerful and is used by mistake. The test uses a role similar to the one that could be compromised and asks it to attempt three operations: shorten retention, remove a legal hold and delete the protected version.

This distinction is essential in S3. Governance mode allows certain principals with the s3:BypassGovernanceRetention permission to bypass retention. Compliance mode does not allow retention to be shortened or the protected version to be deleted during the specified period, according to the Object Lock management considerations. An organisation that says “the bucket is immutable” must therefore specify which mode it uses and which identities have the bypass permission.

The test is not intended to prove that no administrator can ever act. It is intended to map the attack path. Can an operations role disable the lock? Can an account administrator delete the bucket? Does an emergency procedure have bypass rights? Do the logs record the attempt and the identity that made it?

The expected result depends on the chosen protection level, but it must be explicit. In Governance mode, a successful deletion with the dedicated permission is not necessarily a failure of the feature. It is evidence that this permission is a critical control that must be isolated, monitored and removed from ordinary roles. In Compliance mode, the attempt must fail during the retention period. In both cases, the team should retain the returned error and verify that the version remains readable.

Azure and Google Cloud present a comparable decision around the policy itself. Azure distinguishes retention from legal holds. Google Cloud makes the policy irreversible after it has been locked. The operational question remains the same: who can activate the mechanism, who can still manage the data without reducing its protection, and how can an independent team verify that before an incident?

4. Scenarios 2 and 3: Logical Deletion, a Deleted Bucket and Ransomware

A successful deletion through the interface does not necessarily mean that protected data has disappeared. In S3, a simple deletion can create a delete marker: a marker that hides earlier versions during an ordinary lookup. AWS specifies that the marker itself is not protected by WORM. The locked version can therefore remain in place while becoming less visible to an application that does not explicitly request versions.

The second test is to delete the object using the same type of tool used in production, then check two paths: the normal read path and the version inventory. If the file no longer appears through the first path but remains recoverable through the second, protection against destruction is present, but the recovery process must know how to bypass the masking. Document this distinction. Otherwise, a team under pressure may conclude too quickly that the backup has been lost.

The next test broadens the action: delete the bucket, storage account or a complete data set. WORM protection on an object is not automatically protection against every management operation around it. With Google Cloud, locking a policy prevents the bucket from being deleted while its objects have not completed their retention periods. But this property must be verified in the exact context of the permissions and services used by the organisation.

The third test simulates ransomware. Deploying malicious software is not necessarily required: a controlled procedure can attempt to traverse the repository with a compromised backup account, rewrite objects, add versions and place delete markers. The team then observes what remains, what the catalogue displays and how long it takes to isolate the account.

The CISA recommends isolated, encrypted, immutable and regularly tested backups against ransomware. These qualities complement one another. A copy accessible with the same credentials as production systems is not truly isolated; a locked copy that has never been recovered is not yet a demonstrated recovery capability. The test result should include surviving data, triggered alerts, the access-revocation procedure and the time required to find a healthy recovery point.

5. Scenarios 4 and 5: Retention Expiry and Partial Recovery

A retention period is not an eternal shield. When it expires, an S3 version becomes deletable unless a legal hold remains active. This is precisely the behaviour to test rather than assume: what happens on the expiry date, which Lifecycle rule applies, who receives the information, and do older versions remain covered by the intended policy?

An accelerated test in a dedicated environment can verify the transition between three states: a protected version, a version whose retention has expired and a version maintained by a legal hold. The aim is not to delete important data, but to observe the change in rights and connect it to the logs. This check often exposes a decision that was never formalised: is the duration meant to protect the backup during a regulatory window, throughout the period needed to detect a compromise, or for the full period required by operations?

The next step is to move from deletion to recovery. A complete recovery verifies that the environment can restart, but it does not always show whether one file, one table or one virtual machine can be recovered quickly. The partial-recovery scenario takes a known object or subset, finds the correct version despite a possible delete marker, decrypts its contents and verifies its integrity in a separate location.

Measure this sequence without turning the test into a speed contest. Record the search time, required permissions, catalogue dependencies, volume actually recovered and the checks that prove the content matches the selected backup. A recovery that succeeds only because an administrator has exceptional rights is not necessarily unusable, but that dependency must be visible in the crisis plan.

Azure documents time-based WORM policies and legal holds that prevent modifications and deletions during the protection period. Google Cloud explains, with Bucket Lock, that a locked policy can no longer be reduced. In both cases, retention irreversibility does not remove the need to verify recovery. It simply makes deliberate or accidental deletion more difficult during the defined window.

6. Scenario 6: Regional Loss, Replication and Encryption Keys

A copy in another zone or region is often presented as the answer to an outage at the primary site. It should not, however, be confused with immutability. Redundancy can replicate a deletion or replacement. Microsoft explains this for Azure: deletions and replacements are replicated to the copies, while geo-replication protects against certain regional failures. A geographically separate copy is therefore not automatically protected against a hostile administrator.

In S3, replicating an Object Lock bucket requires the destination to have versioning and Object Lock enabled as well, according to the AWS replication requirements. This requirement should appear in the control matrix, along with the destination’s configuration, its own permissions and its own retention period. A destination that is merely “replicated” but not locked may preserve a copy without offering the same resistance to deletion.

Replication is also asynchronous. Data written just before an outage may not yet be present at the destination. AWS documentation on live replication also points out that newly configured replication does not automatically copy every earlier object. The test should therefore include an object created before configuration, one created after configuration and one written during a delay window. For each, record whether it exists at the destination, with which WORM metadata and after what delay.

The final check concerns encryption. Object Lock does not protect against the loss or deletion of the encryption key: AWS states that immutable objects can become unreadable if the corresponding KMS key is deleted. A backup can therefore survive a DELETE operation while failing at read time. The test should recover an encrypted object from the destination, then check the governance of the key’s lifecycle, the identities authorised to use it and the ability to retrieve the secret from within the recovery perimeter.

At the end of this scenario, the team should be able to produce a simple map: primary copy, remote copy, replication status, acceptable delay, protected versions, available keys and the recovery procedure when the primary region is inaccessible. If any element still depends on a service located in the lost region, write that limitation down rather than leaving it open to interpretation.

7. Turn Test Results into Evidence of Resilience

A good test campaign does not end with a “compliant” note in a spreadsheet. It leaves a record that allows the test to be repeated after a role, provider, Lifecycle policy or replication topology changes. For each scenario, retain the identity used, the object or data set involved, the configuration before the test, the action performed, the refusal or success message, the audit logs and the read or recovery result.

The matrix can remain concise if it separates the questions clearly. Does the lock apply to the expected version? Can a compromised account reduce the duration? Does a logical deletion hide data that remains recoverable? Does the expiry date produce the expected behaviour? Is the encryption key available independently of the production system? Does the regional destination have its own protections? Finally, have both a complete recovery and a partial recovery been performed with rights and tools that would genuinely be available during a crisis?

Gaps should not be treated as minor configuration details. If Governance mode can be bypassed, the corresponding permission should become an exceptional, monitored access right. If delete markers disrupt the catalogue, the recovery procedure must search for versions. If replication is asynchronous, the plan must define acceptable data loss and how lag will be measured. If KMS keys sit within the same failure perimeter, their separation and recovery become a priority project.

The frequency of testing depends on the pace of change, but the principle is stable: a backup that has not been recovered recently remains an assumption. CISA emphasises regular recovery testing. This is probably the most practical recommendation in the entire approach. It forces the organisation to confront the WORM policy with the catalogue, permissions, network dependencies, keys and the time actually available.

The desired result is not an absolute promise. No single mechanism simultaneously covers deletion, compromised credentials, regional loss, key unavailability and the absence of a procedure. An immutable cloud backup becomes credible when its limits are known, its access paths are separated, its replication is verified and its recovery regularly produces usable evidence.

Conclusion

The word “immutable” describes a precise technical property, not a general state of security. In WORM storage, a version may be protected for a defined period while a delete marker, a badly configured destination or a lost key undermines recovery. That difference between a locked object and the complete backup system deserves attention.

The most reliable method is therefore empirical: try to shorten retention with a compromised account, delete an object and search for its versions, simulate ransomware, observe expiry, recover a subset, then cut access to a region and check the remote copy. Each scenario should produce evidence and expose a limitation that the organisation is prepared to acknowledge.

A team that knows these answers does more than possess an immutable cloud backup. It knows what will survive, what will remain readable, who can recover it and within what timeframe. During a crisis, that precision is worth more than a simple “WORM enabled” badge.

Daymain Team