Key takeaway: Ransomware operators target backups deliberately and early. A backup reachable with production credentials is not a backup — it is another copy waiting to be encrypted.
What Attackers Do First
Modern intrusions do not begin with encryption. They begin with weeks of quiet access, and one of the earliest objectives is locating and neutralising recovery capability.
Backup servers are enumerated, backup agent credentials harvested, retention policies shortened, snapshots deleted, and cloud backup buckets emptied. Only then is the payload deployed, because an organisation that can restore does not pay.
This is why the reflex answer — “we have backups” — so often fails. The backups existed and were reachable from the compromised environment using credentials the attacker obtained.
The Properties That Matter
| Property | Weak arrangement | Resilient arrangement |
|---|---|---|
| Credential separation | Same directory as production | Separate identity, no trust |
| Network reachability | Accessible from production | Isolated or pull-based |
| Immutability | Deletable by admin | Object lock or WORM |
| Copies | One location | Three copies, two media, one offsite |
| Restore testing | Never | Regular timed exercise |
| Scope | Databases only | Configuration and dependencies too |
Immutability is the single most valuable control. Object lock or write-once storage means a retention period cannot be shortened and objects cannot be deleted, even by an account with administrative rights. That converts backup deletion from a routine attacker step into an impossibility.
Credential separation is next. If the same directory account can reach production and the backup system, one compromise reaches both. Backup infrastructure needs its own identity plane with no trust relationship to the production one.
Testing Reveals What Design Misses
A restore exercise surfaces problems that no review finds. Backups that ran successfully but excluded a directory added last year. A database backup without the encryption key needed to read it. A restore that takes eleven days for a business expecting two. Application configuration nobody backed up, so restored data has nothing to run in.
Time the exercise. The number that matters is not whether restore succeeds but how long it takes end to end for a realistic scope, and that figure is almost always far worse than assumed.
Test restoring to clean infrastructure rather than over the existing environment. During a real incident the original systems are evidence and are presumed compromised, so restoring in place is not an option.
The Data Theft Complication
Backups solve availability and do nothing about disclosure. Contemporary operations exfiltrate before encrypting and threaten publication, so an organisation that restores perfectly still faces a data breach with notification obligations and reputational consequences.
This means backup resilience removes the ransom leverage for availability while leaving the extortion leverage for disclosure. The controls that address the second are the ones limiting bulk data access and detecting large outbound transfers — a different investment that backup strategy does not substitute for.
The Bottom Line
Make backups immutable with object lock, isolate them behind separate credentials with no production trust, include configuration alongside data, and run timed restores to clean infrastructure on a schedule. Then recognise that recovery capability does not address exfiltration, which needs its own controls.
