A backup the attacker can delete is not a backup
Ransomware crews go for the backups first, and cloud backups are easier to delete than tape ever was. Immutability, credential separation and a copy outside the blast radius are what turn a backup into a recovery.
The pattern in every ransomware incident report reads the same. The intrusion is not detected for weeks. During that time the attacker does reconnaissance, finds the backup system, and either deletes the backups, encrypts them along with everything else, or quietly changes the retention policy so they age out. Only then do they trigger the encryption. By the time anyone notices, the recovery path was removed days earlier.
This is why "we have backups" and "we can recover" are different claims. The first is about whether data was copied. The second is about whether a copy survives an attacker who has your administrator credentials.
Immutability is the control that matters most
Every major object store now supports write-once-read-many retention, sold as object lock or immutable storage. When a retention period is set in compliance mode, nobody can delete or overwrite that object until the period expires. Not an administrator, not the account root, not the vendor's support desk.
This is the single highest-value control on this list, because it is the only one that holds when the attacker has full administrative access. Governance mode, where a privileged role can override the lock, is useful for protecting against mistakes and worth nothing against a determined intruder who can obtain that role.
Two things to get right. The retention period must exceed your realistic detection time. If intrusions go unnoticed for a month on average and your lock is seven days, the lock does not help. And legal hold plus a lifecycle rule interact in ways worth testing, because a misconfigured combination either deletes early or accrues cost forever.
Separate the credentials, separate the account
If the identity that runs your production workload can also delete your backups, you have one blast radius, not two.
The backup destination belongs in a different account, subscription or project, with its own identity boundary and no trust relationship that a compromised production role can traverse. The production side gets write-only, append-only permission to the destination. The ability to delete lives with a small number of identities that do not exist in the production environment at all, protected by hardware-backed multi-factor authentication.
Check the path an attacker would take. Can the production CI pipeline assume a role in the backup account? Can the organisation management account reach it, and who can reach the management account? Most estates have one link they did not intend, and it is usually a broadly scoped role created during a migration.
The copy that is somewhere else
The old three-two-one rule survives the move to cloud with one clarification: "offsite" now means outside the failure domain that includes your cloud account, not merely another region.
A separate region protects against regional failure. It does not protect against an account compromise, a billing failure that suspends the whole account, or a mistaken organisation-level policy. For the data you genuinely cannot lose, keep one copy in a separate provider or in physical storage. That copy can be smaller, slower and less current than the primary backup, because its job is survival rather than convenience.
This is also where a regulator's expectations bite. Both NIS2 and DORA press on demonstrable recoverability rather than the existence of a process document, which is covered from the obligation side in NIS2 scope and obligations and DORA for a technology supplier.
Encryption keys are part of the backup
A backup encrypted with a key held in the compromised environment is not recoverable if the attacker deletes the key, and key deletion is a documented ransomware technique because it is faster than encrypting the data.
Hold the key for backup data in a separate key vault in the separate account, enable deletion protection and the longest purge protection window your provider offers, and record the key identifier somewhere outside all of it. Test decryption from a clean environment, because discovering during recovery that nobody knows where the key material lives is a bad afternoon.
Detect the deletion, not just the encryption
Mass deletion of backup objects is an unusual event with a clear signature, and it happens before the visible damage. That makes it one of the highest-value detections available.
Alert on: any deletion of objects in the backup bucket, any change to a lifecycle or retention policy, any change to the backup job schedule or destination, disabling of versioning or object lock, and a backup job that reports success with a size significantly smaller than the previous run. That last one catches both the attack and the far more common silent breakage.
Route these to a channel that is monitored, and to an identity that is not in the compromised environment. An alert that emails an account the attacker controls is decoration.
Restore testing, because a backup is a hypothesis
None of this means anything if the restore does not work, and restores fail for mundane reasons far more often than dramatic ones: a missing schema, a dependency on a secret nobody exported, a database version that no longer exists, an object lock that prevents writing the restored data back.
Test on a schedule, restore into a clean environment, and time it. The number you produce is the real recovery time objective, and it is usually several times the one in the plan. That whole discipline is the subject of RTO, RPO and the restore test.
The tension with privacy
Immutable backups and a right to erasure pull in opposite directions, and pretending otherwise fails an audit.
The defensible position is a bounded maximum backup retention window, documented, with a process that re-applies outstanding deletions after any restore, and that process actually implemented and evidenced. Set the immutability period to match the backup retention window rather than exceeding it. The reasoning behind that position is set out in GDPR as engineering controls.
The things people forget
- Snapshots in the same account are not backups. They share the failure domain and the permission model with the thing they protect.
- Managed database point-in-time recovery has a short window. It is excellent for accidental deletion and useless against an intrusion discovered in week three.
- Configuration is data. Infrastructure definitions, pipeline configuration, identity policies and DNS records need to be recoverable, and a git repository the attacker can force-push to is not a backup either.
- Third-party SaaS is your responsibility. The provider protects against their failure, not against your administrator deleting a workspace. Export what matters.
- Restore capacity has to exist. Recovering a large estate needs compute and network you may not have quota for, on a day when everyone is panicking.
What to do this week
Take the credential your production environment uses and check, precisely, whether it can delete an object in your backup destination. Not by policy reading, by trying it in a test path. If it can, that is the finding, and putting object lock on that bucket is an hour of work that changes your worst day entirely. We check exactly this in a security engagement.