ASD ISM 2151 Technically enforced immutability protecting backups through their retention period
What it says
Backups are stored using a technically enforced immutability mechanism that prevents their modification or deletion for the duration of their retention period.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishBackups must be locked by a technical immutability mechanism so nobody, including administrators or attackers, can alter or delete them until their retention period ends.
This control requires that backups are stored in a way that makes them physically or logically impossible to change or delete until their retention period has run out. The protection must be enforced by technology (for example a storage lock or write-once mechanism), not merely by policy, process or a promise that staff will not touch the backups. It matters because backups are the last line of defence when systems are compromised. Modern ransomware operators routinely hunt down and destroy backups before encrypting production systems, precisely so the victim has no choice but to pay. An administrator whose credentials have been stolen, a disgruntled insider, or a simple mistake can achieve the same result. If the backup platform itself refuses every modification or deletion request until the retention period expires, those attacks fail even when the attacker holds privileged access. The organisation keeps a clean copy of its data to recover from, no matter what happens to the live environment.
Free. Save your status, tasks and notes.
Why it matters
Without technically enforced immutability, backups can be encrypted, corrupted or deleted by ransomware, a compromised administrator account or an insider before the organisation discovers the incident. Recovery then depends on whatever the attacker left behind, which is frequently nothing. The likely consequences are extended outages, permanent loss of business records, pressure to pay a ransom, regulatory breach reporting obligations and serious reputational harm. Backups that exist only on paper as "protected" offer no assurance if the storage layer will still honour a delete command.
How to implement
The backup or infrastructure owner selects a backup target that offers a technically enforced lock, such as object storage with object lock in compliance mode (not governance mode, which can be bypassed by identities holding the bypass-retention permission), a WORM-capable appliance, or a backup repository with a hardened immutability feature, and confirms the lock cannot be removed by the backup administrator account.
The backup administrator configures every backup job so that its output is written to the immutable target with a lock duration equal to or longer than the approved retention period for that data, rather than relying on a shorter default lock.
The storage administrator separates the credentials that can manage the immutable storage from the credentials the backup software uses to write to it, so that a compromised backup server or admin session cannot shorten or lift the lock.
The backup administrator verifies the mechanism after deployment and after each significant change by attempting to delete and modify a locked backup set with an administrative account, recording that the storage platform rejected both actions.
The records or information management owner maintains a register of retention periods per backup class and works with the backup administrator to update the immutability duration whenever a retention period is lengthened, so the lock always covers the full period.
Keep it running
Day to day, the immutability mechanism should be invisible to normal backup operations: jobs write new backup sets, and the storage platform locks each set for the configured retention period automatically. Operators need to understand that locked backups cannot be trimmed early to free space, so capacity planning must account for the full retention period across every backup set.
Any change to backup software, storage firmware, cloud storage settings or retention configuration is a moment where immutability can silently break, so treat those changes as requiring verification that the lock is still enforced. Watch for backup sets that were created without the lock applied (for example a new backup job that was not pointed at the immutable target). Attempted deletions or modifications that are rejected by the storage layer are a useful signal of misconfiguration, a compromised account or an active attack, and should be reviewed rather than ignored. Finally, when retention periods are extended for legal or business reasons, confirm the immutability window is extended to match, since the control only holds for the duration of the retention period the platform knows about.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the design or configuration documentation for the backup storage that describes the immutability mechanism in use.
Look at
Look for a named technical feature (object lock, WORM, hardened repository) rather than a procedural statement that backups are not to be deleted, and check which accounts or roles could in theory disable it.
Good evidence
The documentation identifies a specific storage-enforced lock, explains how it is applied to each backup set, and shows that no backup administrator role can remove the lock before expiry.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the live configuration of a sample of backup jobs and their storage targets.
Look at
Compare the immutability or lock duration set on each target against the approved retention period for that backup class, and check that every job is pointed at an immutable target.
Good evidence
Every sampled job writes to an immutable target and the lock duration is equal to or longer than the retention period, with no jobs writing to unprotected storage.
- Check 3 of 5What an auditor asks for
Ask for
Ask for evidence of a test where someone tried to delete or modify a locked backup set.
Look at
Check that the test was performed with a privileged account, that the attempt targeted a backup still inside its retention period, and that the storage platform refused the action.
Good evidence
A dated test record or screenshot shows the deletion and modification attempts were rejected by the storage layer, and the test has been repeated after major changes.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the storage or backup platform logs covering rejected delete or modify attempts on backup sets.
Look at
Look for entries showing that the lock actively blocked requests, and for any successful early deletions that would indicate the mechanism is not enforced.
Good evidence
Logs show that any delete or modify requests inside the retention period were rejected, and any successful deletions relate only to backups whose retention period had expired.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the list of accounts and roles with rights to administer the immutable storage and the lock settings.
Look at
Check whether the same identities that run day-to-day backups can also change lock duration or disable immutability, and whether the lock mode allows privileged override.
Good evidence
Lock administration is restricted to a small, separate set of identities, the backup service account cannot alter lock settings, and where the platform offers a mode that cannot be overridden even by administrators it has been chosen.
Mappings
Closest match in ISO/IEC 27001: A.8.13, Backup and recovery procedures for data, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.13.
ISM-2151 requires that stored backups are protected by technically enforced immutability for the full retention period. ISO/IEC 27001:2022 Annex A 8.13 requires maintaining backups and regularly testing them in accordance with a backup policy, covering the broader backup process lifecycle. ISM-2151 is a specific technical control that can be used to satisfy part of Annex A 8.13's protection expectations, but Annex A 8.13 also includes requirements (policy alignment and testing) not addressed by ISM-2151.
ASD Essential Eight: 4 mappings
This control partially meets E8-RB-ML1.3.
ISM-2151 requires backups to be stored with technically enforced immutability so they cannot be modified or deleted for the entire retention period. E8-RB-ML1.3 requires backups to be retained in a secure and resilient manner, which can be achieved in part through immutable/WORM storage. However, E8-RB-ML1.3 is broader (covering resilience and secure retention generally), while ISM-2151 is a specific technical safeguard focused on preventing alteration/deletion during retention.
This control partially overlaps E8-RB-ML1.6.
ISM-2151 requires a technical immutability mechanism that prevents any modification or deletion of backups until retention expires. E8-RB-ML1.6 focuses on preventing unprivileged accounts from modifying or deleting backups, which aligns with part of the immutability objective. However, ISM-2151 goes further by requiring protection even from administrators/attackers and by tying the protection explicitly to the retention period, while E8-RB-ML1.6 is limited to unprivileged accounts.
This control partially overlaps E8-RB-ML2.2.
ISM-2151 requires backups to be immutable so they cannot be modified or deleted for the duration of retention, including by privileged users. E8-RB-ML2.2 similarly aims to prevent privileged accounts (excluding backup administrators) from modifying or deleting backups. The overlap is the prevention of backup tampering, but ISM-2151 is stronger and more specific by mandating a technical immutability control and by explicitly covering all actors, including backup administrators, until retention expiry.
This control partially overlaps E8-RB-ML3.3.
ISM-2151 requires a technically enforced immutability mechanism that blocks modification or deletion of backups until their retention period ends. E8-RB-ML3.3 requires backup administrator accounts to be prevented from modifying or deleting backups during retention, which is a key threat model ISM-2151 addresses. E8-RB-ML3.3 is role-specific (backup administrators), whereas ISM-2151 is an implementation requirement (immutability) that protects against a broader set of actors and methods of deletion/tampering.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.