Skip to content
arrow_back
policyASD Information Security Manual (ISM)

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.

record_voice_over

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

Topic

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.
policyASD Information Security Manual (ISM)ISM-2151
priority_high

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.

settings

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.

build

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.
fact_check

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.
link

Cross-framework mappings

How ISM-2151 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.

ISO 27001

ControlNotesDetails
layersPartially meets(1)expand_less
Annex A 8.13ISM-2151 requires that stored backups are protected by technically enforced immutability for the full retention period

E8

ControlNotesDetails
layersPartially meets(1)expand_less
E8-RB-ML1.3ISM-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.6ISM-2151 requires a technical immutability mechanism that prevents any modification or deletion of backups until retention expires
E8-RB-ML2.2ISM-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.3ISM-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.

See all Guidelines for system management controls, or browse the full ASD ISM library.

Mapping detail

Mapping

Direction

Controls