Ransomware Resilience: Immutable Backups, Proven RTO

Q: Why do companies with backups still pay the ransom?

Because having a backup and being able to restore from it are two different things, and ransomware crews attack exactly that gap. Modern operators spend days inside a network before encrypting anything, and once they have domain or cloud administrator rights the first thing they do is neutralise the recovery path: they delete snapshots, wipe or encrypt the backup server, corrupt the backup catalog, and remove the volume-shadow copies. When the encryption finally fires, the victim discovers that the backups technically exist but cannot be restored — the catalog is gone, the media is encrypted, or a restore would take longer than the business can survive being offline. The organisations that do not pay are the ones whose backups were immutable and isolated from the production identity plane, so a fully compromised administrator could not touch them, and who had rehearsed the restore so they knew, on a clock, that recovery was faster than the damage of staying down. Paying is what happens when the only clean copy is one the attacker already controlled.

Q: What does immutable backup actually mean, and how is it different from delete protection?

Immutable backup means the data physically cannot be altered or deleted for a defined retention period, and that guarantee is enforced by the storage layer itself rather than by a setting an administrator can reverse. This is the distinction that matters under attack. Ordinary delete protection is a toggle in a console: it stops accidental deletion, but a compromised administrator with the right credentials can switch it off and then delete the data, which is precisely what ransomware operators do. True immutability, such as Amazon S3 Object Lock in compliance mode or AWS Backup Vault Lock once its grace period has elapsed, denies the delete operation to everyone, including the account root user and even the cloud provider, until the retention clock expires. There is no override, no support ticket that shortens it, no privileged escape hatch. That is the entire point: your recovery copy must survive a scenario in which the attacker owns every credential in the production environment. If a human can turn the protection off, it is not immutability — it is a suggestion, and ransomware does not honour suggestions.

Q: What is the 3-2-1-1-0 backup rule?

The 3-2-1-1-0 rule is the ransomware-era evolution of the classic 3-2-1 backup guidance. The original 3-2-1 said: keep three copies of your data, on two different types of media, with one copy off-site. That was designed for hardware failure and fire, not for an adversary who actively hunts your backups. The two extra digits close that gap. The additional 1 means one copy must be offline or immutable — air-gapped or WORM-protected so that an attacker with full network access cannot reach or alter it. The final 0 means zero errors in a restore that you have actually tested, which forces the discipline of periodically restoring from your backups and validating the result rather than assuming the backup job succeeding is the same as the restore working. In practice most organisations comfortably satisfy the first three digits and fail the last two, and those last two are the ones that decide whether a ransomware event is recoverable. The offline/immutable copy defeats deletion, and the tested restore defeats the false confidence of a backup that was never proven.

Q: How long does the AWS Backup Vault Lock grace period last, and can it be undone?

AWS Backup Vault Lock in compliance mode has a mandatory cooling-off window, called the grace time, that must be set to at least 3 days, which is 72 hours, and can be as long as 36,500 days. During that grace period the lock behaves like a safety net: you can still remove the vault lock or change its configuration, which protects you from a misconfiguration that would otherwise be permanent. Once the grace period expires, the vault and its lock become fully immutable — the configuration cannot be altered or deleted by any user, by the account root, or by AWS itself, and recovery points cannot be deleted until their own retention lifecycle completes. That irreversibility is deliberate and is what makes it a genuine defence against a compromised administrator, but it also means you must configure retention carefully, because after the grace time you cannot shorten it. Vault Lock is offered at no additional charge beyond normal AWS Backup storage costs, so the immutability guarantee itself is free; you pay only for the stored data. Governance mode, by contrast, can always be removed by a user with sufficient IAM permissions, so it is not a ransomware control.

Q: Why should backups live in a separate account or domain from production?

Because backups that share an identity plane with production share a blast radius with the exact threat they are supposed to survive. Ransomware operators win by acquiring administrative control — a domain admin in Active Directory, or a privileged role in your cloud account — and from there everything reachable with those credentials is theirs to encrypt or delete. If your backups sit in the same AWS account, the same subscription, or behind the same domain administrator as the systems being protected, then compromising production automatically compromises the recovery path, and the immutable copy you thought you had is deletable after all. Isolation breaks that chain. Putting the backup copy in a separate account or subscription, ideally with a distinct identity provider, MFA-delete, and its own privileged-access model, means that owning production does not grant ownership of the backups. The attacker would have to separately compromise a second, hardened environment that has no trust relationship handing them the keys. This is the same multi-account, least-privilege discipline applied to the one system you cannot afford to lose, and it is what turns an immutable copy from a checkbox into an actual guarantee.

Q: What is an isolated recovery environment and why do I need one?

An isolated recovery environment, sometimes called a clean room, is a separate, hardened environment where you rebuild and restore systems during an incident without any trust relationship to the compromised production environment. You need one because restoring clean data back into an environment the attacker still controls simply re-exposes it — the malware, the persistence mechanisms, and the stolen credentials are all still there, so your freshly restored systems get re-encrypted or re-compromised within hours. The isolated recovery environment gives you somewhere safe to work: you rebuild domain controllers and core infrastructure from known-clean media, restore application data from the immutable backup copy, and validate the integrity of what you restored and scan it for malware before anything reconnects to a production network. It also lets you measure recovery honestly, because the restore happens under realistic conditions rather than in a friendly test that assumes the network is healthy. Skipping this step is one of the most common reasons recovery fails on the second attempt: teams restore quickly into the dirty environment, declare victory, and are back in the incident before the week is out. The clean room is not optional infrastructure; it is where recovery actually happens.

Q: How do I prove my recovery time objective (RTO) instead of guessing it?

You prove an RTO the only way it can honestly be proven: by running a full restore under attack-realistic conditions, on a clock, and measuring how long it actually takes end to end. A restore drill means starting from the assumption that production and its identity plane are hostile, rebuilding core infrastructure from clean media, restoring your largest and most critical datasets from the immutable backup copy, validating data integrity, scanning for malware, and only then declaring the system recovered — timing every stage. This surfaces the costs that policy documents ignore: restoring a multi-terabyte dataset over a throttled or degraded link is slow, rebuilding directory services is fiddly, integrity validation on large datasets takes real hours, and dependencies between systems mean you cannot recover them in any order you like. Almost every team that runs its first honest drill discovers its real RTO is several times longer than the number in its business-continuity plan. The value is twofold: you get a defensible recovery figure to give leadership, and you find and fix the bottlenecks — bandwidth, sequencing, missing runbooks, stale credentials — while it is a drill and not a live incident. An RTO you have never tested is not an objective; it is a hope, and hope is optimistic by a margin you cannot afford to learn during a breach.

Q: Is preventing ransomware not more important than planning to recover from it?

Prevention and recovery are not competing priorities; they defend against different phases of the same attack, and a programme that funds only prevention is one bad day from catastrophe. Prevention — endpoint detection, email filtering, multi-factor authentication, patching, phishing-resistant credentials — lowers the probability that an attacker gets in, and that is genuinely valuable because most incidents are stopped early. But prevention is a probability game, and across enough attempts and enough time the probability of at least one success trends toward certainty; a single stolen session token or one unpatched edge device is enough. The moment an attacker has administrative control, every preventive control you bought stops helping, because those controls were designed to keep intruders out, not to undo damage done by someone already inside with admin rights. That is the phase recovery architecture owns. Immutable, isolated backups and a proven restore are what determine whether that inevitable eventual success is a contained, recoverable event or an existential one. The correct posture is defence in depth across both phases: invest in prevention to reduce frequency, and invest in recovery architecture so that when prevention eventually fails — and it will — the outcome is a bad week, not the end of the business. Building all prevention and no proven recovery is the most common and most dangerous imbalance in security budgets.