Immutable backup
An immutable backup is a copy that cannot be modified or deleted until a retention period expires, enforced by the storage layer rather than by policy. In ransomware recovery it is the property that matters, because attackers routinely delete or encrypt backups before triggering the payload.
Enforcement location is the whole point. A retention rule that the backup application honours is not immutability, because an attacker who owns the backup console owns the rule. Object storage that refuses deletion until the clock expires, appliances with a hardened retention mode, and tape that is physically removed all fail closed for different reasons; a checkbox in the same console that holds the credentials does not.
Two details decide whether it works in an incident. Whether the account that creates the copy can also shorten its retention, which quietly restores the deletion path. And whether the restore path itself survives: an immutable copy is of no use if the catalogue, the encryption keys or the identity provider needed to read it were in the same estate that was encrypted.
On an engagement this is one of the fastest questions to answer and one of the most often answered wrongly. We look at which identity administers the backup platform, whether that identity is a member of the same directory as the production estate, and whether anyone has restored from the immutable copy rather than from the recent one. A copy that has never been restored is a plan, not a control, and against ransomware that distinction is the whole recovery.