What is an Immutable Backup?
An immutable backup is a backup copy that technically cannot be modified, overwritten or deleted for a predefined retention period, not even by a user with administrator rights. The storage system enforces this using the WORM principle (Write Once, Read Many): data is written once and can then only be read until the retention period expires. That makes an immutable backup the last line of defence against ransomware, malware, malicious insiders and human error. It is the extra β1β in the 3-2-1-1-0 rule: three copies, two media types, one off-site, one offline or immutable, and zero errors in restore tests.
Immutable = unchangeable within the retention period: whoever takes over the management console still cannot wipe the restore points.
π― Why are immutable backups needed?
Ransomware groups no longer just encrypt production systems. They first go after the backup server, often through stolen Active Directory admin accounts, and delete or encrypt the restore points there. In its StopRansomware Guide (September 2023), the US agency CISA warns that many ransomware variants actively look for accessible backups in order to delete or encrypt them. Without a usable backup, the only options left are paying or rebuilding from scratch.
An immutable backup solves this by refusing the delete command itself. In concrete terms, it protects against:
- Ransomware and wipers - an attacker with admin rights cannot encrypt or delete older restore points
- Abused admin accounts - even a compromised backup or domain admin account cannot shorten the retention period (in the strict mode)
- Insider sabotage - a disgruntled employee cannot quietly wipe restore points
- Human error - a misconfigured retention clean-up or a faulty script run does not destroy restore points
- Evidence and data integrity - stored logs and historical data remain demonstrably unchanged
π§ How does immutability work technically?
Immutability is not a property of the backup file but of the storage layer, which refuses write and delete commands. There are four common implementations:
| Application | Mechanism | Typical implementation |
|---|---|---|
| Object storage with object lock | A retain-until date per object version; versioning required | AWS S3 Object Lock, Azure Blob immutable storage, S3-compatible storage such as Wasabi |
| Hardened Linux repository | Immutable file attribute that only a root service can set or remove | Veeam Hardened Repository: 7 to 9,999 days |
| Backup appliance | Proprietary file system with locked snapshots and management through separate privileges | Rubrik, Cohesity, Commvault appliances and similar |
| WORM tape | Physical cartridge that cannot be overwritten once written | LTO WORM cartridges, available since LTO-3 |
Governance versus compliance mode
With cloud storage, the mode determines how strict the lock is. In AWS S3 Object Lock, a user with the special BypassGovernanceRetention permission can still delete an object in governance mode. In compliance mode, nobody can delete the object or shorten its retention period, not even the root account; only closing the entire AWS account removes the data early. Azure makes a similar distinction between an unlocked policy (for testing) and a locked policy, which can only be extended. Azure allows retention periods from one day up to 146,000 days (400 years).
Both cloud services have been assessed by Cohasset Associates against the financial record-keeping rules SEC 17a-4(f), FINRA 4511 and CFTC 1.31. These are US archiving rules, not OT requirements, but they show that the lock has been independently verified.
π How does it differ from a regular backup, snapshot or air gap?
| Characteristic | Regular backup | Snapshot | Air gap / offline | Immutable backup |
|---|---|---|---|---|
| Deletion by an administrator | Possible | Possible | Only with physical access | Not within the retention period |
| Reachable over the network | Yes | Yes | No | Yes (read and append only) |
| Restore time | Fast | Very fast | Slow (media must be retrieved) | Fast |
| Protects against ransomware | Limited | Limited | Strong | Strong |
| Protects against data theft | No | No | Partly | No |
Immutable and offline copies complement each other. An offline copy is unreachable but slow to restore; an immutable copy is online and fast, but still depends on the software and management layer of the storage system. That is why organisations often combine the two.
β οΈ What does an immutable backup not protect against?
Immutability is strong, but it is no guarantee of recovery:
- Infected data - a backup of a system that was already compromised or tampered with stays immutably compromised; scan restore points and keep enough history
- Data theft - in double extortion the attacker threatens to publish; encryption and network segmentation help against that, immutability does not
- Takeover of the storage environment - whoever gains control of the cloud account or the hardware itself can still do damage in governance mode or through the physical server
- Clock manipulation - some solutions calculate the retention period from system time; Veeam therefore detects time shifts, including those caused by a compromised NTP server
- Expired retention - an attacker who stays undetected longer than the retention period simply waits for the lock to expire; good security monitoring therefore remains necessary
π Why does immutability matter in OT environments?
In OT, the data is not office documents but the knowledge an installation runs on. Often there is no second source:
- PLC programs and firmware versions - the only current version is sometimes stored only on the controller and on a single engineering station
- SCADA, HMI and DCS projects - configurations with years of changes that cannot be reconstructed from the documentation
- Historian data - process history needed for quality records, permits or investigating a failure
- Golden images - clean installations of engineering stations and servers, including licences and installation media
NotPetya showed in 2017 how large that dependency is: Maersk could only restore its Active Directory thanks to a single domain controller in Ghana that had been offline due to a power outage. An immutable copy would have made that stroke of luck unnecessary.
Step-by-step approach for OT
- Inventory what recovery needs, using an asset inventory and a business impact analysis; define the RTO and RPO per system.
- Collect backups centrally in the OT network, linked to change management, so that every change to a PLC or HMI produces a new restore point.
- Lock a second copy: a hardened repository or object storage in compliance mode, outside the Active Directory domain and with dedicated MFA-protected accounts. Transfer runs through a DMZ.
- Choose the retention period well above the time an attacker can stay undetected; 30 to 90 days is a common starting point for daily restore points, supplemented with monthly or yearly copies.
- Test restores periodically on a test set-up, because recovery is what counts: can a PLC program be restored, does the HMI project start, is the version correct? Record the results.
π Which standards and laws require protected backups?
No standard, IEC 62443 included, literally prescribes βimmutableβ, but all of them require backups that survive an attack:
| Framework | Relevant requirement | Role of immutability |
|---|---|---|
| NIS2 / Dutch Cybersecurity Act | Article 21(2)(c): business continuity, such as backup management and disaster recovery | Demonstrable ability to recover after a ransomware incident |
| ISO 27001:2022 | Annex A 8.13 Information backup | Protect backups and test them regularly |
| IEC 62443-3-3 | SR 7.3 Control system backup, with enhancements for integrity verification and automation | Immutability safeguards the integrity of the backup |
| NIST CSF 2.0 | PR.DS-11: backups of data are created, protected, maintained and tested | βProtectedβ calls for separation and locking |
The Dutch Cybersecurity Act (Cyberbeveiligingswet) has been in force since 15 August 2026. Organisations in scope must be able to demonstrate appropriate measures for business continuity and disaster recovery; an immutable copy is a strong argument towards supervisors and auditors. Note that CISA points out that immutable storage does not automatically meet every retention regulation, so compliance requires its own assessment.
β Frequently asked questions
Is an immutable backup the same as an offline backup?
No. An immutable backup remains reachable over the network, but the storage system refuses changes and deletions until the retention period expires. An offline backup is physically or logically disconnected. Both protect against ransomware and are often combined in the 3-2-1-1-0 rule.
Can an administrator still delete an immutable backup?
That depends on the mode. In governance mode or with an unlocked policy, a user with special privileges can lift the lock; in compliance mode or with a locked policy, nobody can delete the immutable backup or shorten its retention period. For recovery-critical OT backups, choose the strict mode.
How long should the retention period of an immutable backup be?
The retention period of an immutable backup should be longer than the time an attacker can remain undetected in the network. A common starting point is 30 to 90 days for daily restore points, supplemented with longer periods for monthly copies. Locking data for too long costs storage capacity, because it can only be cleaned up once the period expires.
Is a snapshot an immutable backup?
A regular snapshot is not an immutable backup, because an administrator can delete it and it usually sits on the same storage system as the source data. Some storage systems do offer locked snapshots that cannot be deleted within a set period. Only that variant meets the definition of immutability.
Does an immutable backup protect against data theft?
No, an immutable backup protects the availability and integrity of data, not its confidentiality. Against double extortion, where an attacker threatens publication, you need encryption, access control and segmentation. Encrypt the immutable copy itself as well.
Which OT data belongs in an immutable backup?
In an OT environment, PLC programs, firmware versions, SCADA, HMI and DCS projects, historian data, Active Directory and golden images of engineering stations belong in an immutable backup. These are exactly the files that often exist nowhere else. Link the backups to change management so that every change produces a new locked restore point.
π In summary
An immutable backup makes restore points technically unchangeable for a retention period, through object lock, a hardened repository, an appliance or WORM tape. Choose the strict mode, place the copy outside the domain, align the retention period with your detection time and test your restores. Immutability does not replace monitoring, encryption or an offline copy, but it turns a ransomware attack into a recoverable incident.
An immutable backup is only valuable when it sits beyond the reach of stolen admin rights, stays locked long enough and is demonstrably restorable.
