Immutable backups: why protected data can still be hard to recover

A backup can survive an attack while the business remains unable to use it. That is the gap hidden inside a reassuring word: immutable.

Immutability addresses whether protected data can be altered or deleted under defined rules. Recoverability asks whether the organisation can turn that data back into a working service. The two are connected, but buying the first does not automatically establish the second.

For a technology leader evaluating backup proposals, the practical question is how much of the recovery chain the product protects and how much remains the organisation’s responsibility.

What is actually locked?

Product labels can obscure the level at which protection applies. Amazon S3 Object Lock, for example, applies retention protection to object versions. Its governance and compliance modes have different rules: governance-mode protections can be bypassed by users with the appropriate permissions, while compliance mode prevents a protected version being overwritten or deleted during retention, including by the account’s root user. AWS separately notes that deleting the associated account is an exception.

That distinction is specific to the documented S3 feature. It illustrates why an evaluation needs the proposed mode and configuration, not just an “immutable storage” line in a quotation.

Ask which copies are protected, when protection starts, when it ends and who can alter relevant settings. A default rule for new backups says little about older copies unless their status is also understood. The scope of the protection is part of what you are buying.

The business stakes extend beyond the backup console. In its third-quarter 2023 filing, MGM Resorts reported shutting down certain systems to mitigate its September cyber incident and experiencing disruption at its domestic properties. That disclosure illustrates why an infrastructure director’s recovery target must describe a functioning service. It does not establish that MGM’s backups failed or that a particular backup product would have prevented the disruption.

The copy is only one dependency

Recovery may require encryption keys, a functioning identity service, network access, application configuration and people with the necessary authority. Some of those dependencies may sit outside the backup platform.

Consider a hypothetical order-processing service. Its backup remains intact, but administrators cannot reach the recovery console because the organisation’s normal identity provider is unavailable. The storage protection has done its job. The recovery route has not.

Changing backup products may not solve that problem. The team first needs to identify the failed dependency and establish an appropriately controlled alternative. This is where an incident response plan that works during an outage becomes part of the backup investment, rather than an unrelated document.

Three claims that deserve different evidence

Claim	What it establishes	What it leaves open
The backup is immutable.	Specified changes or deletion are constrained by the configured protection.	Whether the right data was captured and can be restored.
The backup is isolated.	Defined access paths are separated from the production environment.	Whether shared identities or administrative dependencies remain.
The service is recoverable.	A recovery path can return the service to an agreed usable state.	How that result holds under other failures or changed conditions.

A supplier may contribute to all three, but the evidence should stay separate. A successful restore in a normal environment does not show that the same process works when privileged accounts or a shared dependency are compromised.

Evaluate the return to service

Choose a business service and define the minimum useful outcome. For order processing, that could mean authorised staff can retrieve the necessary records and complete a controlled test transaction. Restoring a file is a step towards that outcome, not necessarily its completion.

The exercise should include the people who operate the application. They can identify missing configuration, inconsistent data or a dependency that a storage-only test would overlook. Use an agreed test environment and stop conditions so the exercise itself does not create an avoidable outage.

Compare the observed recovery time with the service’s recovery objective. If a dependency consumes most of the available window, that is a concrete investment question: can it be shortened, removed or supported differently?

Buy a recovery capability you can explain

An immutable backup can be a valuable protection against destructive changes. Its value becomes clearer when the buyer can explain both its boundary and the route from retained data to a working service.

Keep the unresolved dependencies visible in the commercial decision. A proposal that leaves more recovery work to your own team may still be the right choice, but its price needs to be considered alongside that responsibility. The strongest purchase is the one whose protection and operating requirements the organisation understands before it has to rely on them.