ASD ISM 2151Technically Enforced Immutability Protecting Backups Through Their Retention Period
Backups must be locked by a technical immutability mechanism so nobody, including administrators or attackers, can alter or delete them until their retention period ends.
Plain language
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.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for system managementSection
Data backup and restorationTopic
Backup modification and deletion
Official control statement
Backups are stored using a technically enforced immutability mechanism that prevents their modification or deletion for the duration of their retention period.
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.
Operational notes
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.
Implementation tips
- 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.
Audit / evidence tips
- AskAsk for the design or configuration documentation for the backup storage that describes the immutability mechanism in use.Look atLook 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.GoodThe 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.
- AskAsk for the live configuration of a sample of backup jobs and their storage targets.Look atCompare 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.GoodEvery 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.
- AskAsk for evidence of a test where someone tried to delete or modify a locked backup set.Look atCheck 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.GoodA 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.
- AskAsk for the storage or backup platform logs covering rejected delete or modify attempts on backup sets.Look atLook for entries showing that the lock actively blocked requests, and for any successful early deletions that would indicate the mechanism is not enforced.GoodLogs 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.
- AskAsk for the list of accounts and roles with rights to administer the immutable storage and the lock settings.Look atCheck 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.GoodLock 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.
Cross-framework mappings
How ISM-2151 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 8.13 | ISM-2151 requires that stored backups are protected by technically enforced immutability for the full retention period | |
E8
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| 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 retent... | |
sync_altPartially overlaps(3)expand_less | ||
| E8-RB-ML1.6 | ISM-2151 requires a technical immutability mechanism that prevents any modification or deletion of backups until retention expires | |
| 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-ML3.3 | ISM-2151 requires a technically enforced immutability mechanism that blocks modification or deletion of backups until their retention per... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System management
See all Guidelines for system management controls, or browse the full ASD ISM library.