An immutable backup is a copy that cannot be modified or deleted for a defined period once it has been written, including by an administrator holding valid credentials. It is enforced by the storage layer rather than by policy, which is the distinction that matters. A backup protected by permissions can be deleted by whoever holds the right permissions. An immutable copy cannot, regardless of who is asking.
That difference has become significant because of how attacks now work. Mandiant’s M-Trends 2026, drawn from more than 500,000 hours of incident investigations, identifies ransomware operators shifting focus from data theft towards recovery denial. We have written before about why attackers go for your backups first. This piece covers the control most often named as the answer, and what it does and does not do.
What immutability protects against
Immutability addresses one specific scenario: an attacker or insider with legitimate credentials attempting to destroy recovery copies.
It is not a defence against intrusion. It assumes the intrusion has already happened and that the attacker has reached the backup environment with valid access. The protection is that having arrived there, they find they cannot delete or encrypt what they find. The copies remain readable and restorable.
This is why immutability is better understood as a recovery control than a security control. It does nothing to prevent a breach. It determines what the organisation still has afterwards.
What it does NOT do
Immutability is frequently discussed as though it settles the question of backup security. It does not.
An immutable copy can still be read. If the concern is data exfiltration rather than destruction, immutability offers nothing, the attacker copies the data and leaves the original intact. Encryption addresses that exposure.
Immutability also has a defined window. Copies are typically locked for a set retention period, after which they become deletable again. Attackers move quickly, Sophos puts the median time from initial compromise to encryption at four days, but a retention period shorter than the time an attacker spends inside the environment still leaves the copies that matter unprotected.
Finally, immutability says nothing about whether the data is recoverable in practice. A locked copy of a corrupted backup is still a corrupted backup. Immutability guarantees the copy will be there. Only testing establishes that it produces a working recovery, which is a separate exercise with its own set of outputs.
How immutability differs from isolation
These two are commonly conflated and they solve different problems.
Immutability prevents a copy from being altered. Isolation controls what can reach it in the first place. An immutable copy sitting on the production network is protected from deletion but still exposed to anything that can reach that network. An isolated copy that lacks immutability is harder to reach but can be destroyed by anyone who gets there.
The controls are complementary rather than alternatives. Isolation reduces the likelihood of an attacker reaching recovery copies. Immutability limits what they can do if they succeed.
Credential separation belongs in the same discussion. If backup management uses the same credentials as production, a production compromise is a backup compromise, and isolation at the network layer has been undone at the identity layer.
Where air gapping fits
An air gap traditionally meant physical separation: media disconnected from any network, typically tape. Nothing reachable cannot be attacked.
The term is now used more loosely. A logical air gap describes a copy that is network-isolated and inaccessible under normal operating conditions, without being physically disconnected. This is a meaningful control, but it is not the same as physical separation, and the distinction is worth clarifying whenever a provider uses the phrase.
The practical question is not whether something is described as air gapped. It is what specifically would have to be compromised for the copy to be reachable.
What to ask about your own environment
Four questions establish where an environment actually stands:
- Are immutable copies of critical data in place, and for what retention period?
- Is immutability enforced by the storage layer, or by a policy an administrator could change?
- Is the backup environment logically isolated from production, with credentials managed separately?
- Has a restore from an immutable copy been tested, rather than assumed to work?
Â
These are not only internal-use questions. Immutability is now one of the specific things insurers ask about at renewal, alongside backup isolation and documented recovery testing. If the answers are not clear, the renewal conversation is not the moment to find out.
FAQs
What does immutable backup mean?
An immutable backup is a copy that cannot be modified or deleted for a defined retention period once written, including by an administrator with valid credentials. The restriction is enforced at the storage layer rather than by access policy.
Can an immutable backup be deleted by a system administrator?
No, not during the retention period. That is the defining characteristic. A copy an administrator can delete is protected by permissions, not by immutability.
Is immutable the same as air gapped?
No. Immutability prevents a copy from being altered or deleted. An air gap prevents a copy from being reached. They address different stages of an attack and are typically used together.
Does immutability protect against data theft?
No. An immutable copy can still be read and exfiltrated. Immutability prevents destruction, not disclosure.
How long should immutable retention be set for?
Long enough to exceed the period an attacker might remain undetected, and long enough to satisfy any regulatory retention obligations.
Does an immutable backup guarantee recovery?
No. It guarantees the copy will still exist. Whether it produces a working recovery within an acceptable timeframe is established by testing.
