Immutability is enforced at the storage level, not at the application level. Technologies such as Object Lock on cloud object storage, immutable cloud blobs, hardened backup repositories or arrays with WORM snapshots ensure that neither the backup software nor a compromised admin can alter the copies.
What is an immutable backup
An immutable backup is a copy of data protected at the storage level so that it cannot be modified, encrypted, overwritten or deleted by anyone — not even administrators with elevated privileges — for a defined retention period. Immutability is implemented through technologies such as WORM (Write Once Read Many), Object Lock on cloud object storage or immutable snapshots on storage arrays. It is the last line of defence against ransomware: if an attacker encrypts your entire infrastructure but your backups are immutable, you can restore without paying the ransom.
Why it matters
Modern ransomware groups do not stop at encrypting production servers. Their first action after gaining privileged access is to locate and destroy the backups. If they succeed, the victim has no choice but to pay or lose everything. That is why traditional backups are no longer sufficient: if the attacker can reach the backup server with the same domain credentials, they delete it. An immutable backup removes that possibility. Even if the attacker holds admin credentials, they cannot modify or delete protected copies until the retention period expires. For a CISO, implementing backup immutability is probably the measure with the best cost-to-impact ratio against ransomware. It does not prevent the attack, but it guarantees you can recover without giving in to extortion.
Key points
The retention period must be defined according to the RPO (Recovery Point Objective) and regulatory requirements. A period that is too short may leave obsolete copies; one that is too long drives up storage costs.
The 3-2-1-1-0 rule is the current standard: 3 copies, on 2 different media, 1 offsite, 1 immutable, 0 errors in restoration tests.
Immutability does not replace backup encryption or network segmentation of the backup infrastructure. They are complementary layers: encryption protects confidentiality, immutability protects availability and integrity.
Example: ransomware neutralised thanks to immutable backups
A logistics company suffers a ransomware attack that encrypts 120 servers and destroys the backups stored on a domain-accessible NAS. The company has a 24-hour RTO and a cyber-insurance policy that does not cover the ransom if due diligence in data protection cannot be demonstrated. However, six months earlier they had implemented an immutable backup repository on a hardened Linux host, isolated from the Windows domain. The attacker could not reach that repository because it was not domain-joined, shared no credentials and the backups had a 30-day Object Lock. The company restored all 120 servers in 18 hours from the immutable backups, without paying the ransom. The cost of the immutable repository was 15 000 euros. The ransom demanded was 2 million.
Common mistakes
- Assuming that having backups is enough without verifying they are immutable. If the backup server is on the same domain and reachable with the same credentials, an attacker with admin access destroys it in minutes.
- Not testing restoration from immutable backups. Immutability guarantees the copy exists, not that it works. Periodic restoration drills are mandatory to validate that the RPO and RTO are met in practice.
- Configuring immutability only in the cloud and forgetting on-premises backups, or vice versa. The strategy must cover both environments consistently, especially in hybrid architectures.
Related terms
Related services
This concept may be related to services such as:
Frequently asked questions
What is the difference between a regular backup and an immutable backup?
A regular backup can be modified or deleted by any user or process with the right permissions, including ransomware that has compromised administrator credentials. An immutable backup is protected at the storage level with WORM or Object Lock policies that prevent any alteration during the retention period, regardless of who attempts it.
Can an attacker with root access delete an immutable backup?
If immutability is correctly implemented at the storage level (Object Lock on cloud object storage, WORM snapshots on an array, hardened Linux repository with no root SSH access), no. Not even an administrator with the highest privileges can bypass the protection until the retention period expires. That is precisely what distinguishes it from a traditional backup protected only by file permissions.
How much does it cost to implement immutable backups?
It depends on data volume and the chosen technology. In the cloud, Object Lock is typically included at no extra cost on top of standard object storage. On-premises, a hardened Linux backup repository can be set up on standard hardware for a few thousand euros. Compared with the average cost of a ransomware attack — hundreds of thousands or millions of euros between ransom, operational downtime and reputational damage — the investment is minimal.
Are immutable backups enough to comply with NIS2 and DORA?
They are a key component but not sufficient on their own. NIS2 and DORA require complete business-continuity plans that include impact analysis, documented recovery procedures, periodic testing and defined recovery times. Immutable backups cover the data-availability part but must be integrated into a broader resilience strategy.