BCM-009 Backup Immutability and Isolation
Description
At least one backup copy of each system within the recovery scope is written to a store that cannot be altered or deleted before its retention period expires. The retention lock is applied as the copy is written rather than afterwards. That copy sits in a separate failure domain from both the production environment and the primary backup store, in an account or subscription with its own credentials. No role that operates production or routine backups can delete it or shorten its retention. A change to the retention policy or a deletion of a locked copy requires a second authorised approver and raises an alert to a team outside the one requesting it.
Rationale
Ransomware and a compromised administrator both reach the backups through the same credentials that reach production, which is why restore tests pass in exercises and fail in incidents. A retention lock applied at write time and an account boundary with separate credentials leave one copy standing when everything reachable from production is gone. BCM-004 holds backup coverage, frequency and off-site storage, BCM-005 the restoration test and DAT-003 the encryption of backup media. Issued in S4 from G-BCM-2 in docs/review-canonical-quality.md section 7.3.
Applicability (9 profiles)
Framework Mappings (8)
| BCR-08 | Backup | informative |
| BCR-08 | Backup | informative |
| HIPAA-164.308.a.7.ii.A | Data Backup Plan | informative |
| HIPAA-164.312.c.1 | Integrity | informative |
| 8.13 | Information backup | informative |
| NIS2-CIR-4.2 | Backup and Redundancy Management | informative |
| CP-6(1) | Alternate Storage Site | Separation from Primary Site | full |
| CP-9 | System Backup | partial |
Evidence (2)
Retention lock and account isolation configuration for the immutable backup store, with the permission policy showing which roles can write to it and which can change its retention.
Example: Backup vault configuration export of 2026-08-16 showing compliance-mode retention lock at 35 days on the isolated backup account, the cross-account write role and the resource policy denying deletion to production roles
Test: Export the configuration of the immutable backup store. Verify: (1) a retention lock is set in a mode that cannot be shortened or removed before expiry, (2) the lock is applied at write time and covers every system in the recovery scope, (3) the store sits in an account or subscription separate from production and from the primary backup store, with credentials that production roles do not hold, (4) no production or backup-administration role has delete or retention-change permission on it, (5) retention-change and deletion actions are alerted.
Live attempt to delete a locked backup copy and to shorten its retention, performed with production and backup-administration credentials and observed to fail.
Example: Witnessed immutability test of 2026-07-29 recording three deletion attempts from the production administrator role and the backup operator role, each refused, with the alerts they raised
Test: Attempt to delete a locked copy and to shorten its retention using production and backup-administration credentials. Verify: (1) every attempt is refused by the store rather than by a naming convention or a runbook, (2) each attempt raised an alert to a team outside the one making it, (3) a legitimate retention change made through the approved path required a second approver, (4) the copy remained restorable after the attempts.
Questions (3)
Is at least one backup copy written to a store that cannot be altered or deleted before its retention period expires?
The store has to refuse the deletion. Answer no where deletion is prevented by a permission an administrator can grant themselves, or by a policy that says not to.
Which of the following apply to that copy?
The test an assessor runs is to try the deletion with the credentials an attacker would have taken. Answer against what those credentials can do today, not against the intended design.
How much of the recovery scope has an immutable isolated copy?
Options run from strongest to weakest. Recovery scope means the systems the continuity plan commits to restoring, so the answer is measured against that list rather than against the backup estate as a whole.