The backup you have never tested is not a backup
Ransomware groups go for backups first, precisely because a working restore removes their leverage. Most organisations discover their recovery time during the incident.
One stopwatch, nothing else
A single mechanical stopwatch on a seamless bone-white surface, viewed slightly from above. Vast empty space around it. Nothing else in frame.
2400×1350 · WebP · <350KB
Every organisation we have helped through a ransomware incident had backups. That is not the differentiator. The differentiator is whether anyone had ever restored from them under time pressure, with the person who normally does it unavailable, while the domain controller was also encrypted.
Attackers target backups deliberately
Modern ransomware operators are not opportunists who happen to encrypt a file share. They spend days inside the network first, and one of their earliest objectives is your backup infrastructure — because a customer who can restore does not pay. They delete snapshots, they corrupt repositories, and if your backup server is domain-joined with a domain admin service account, they do it with your own credentials.
If an attacker with domain admin can delete your backups, you do not have backups. You have copies.
3-2-1-1-0, and the part everyone skips
- 3 copies of the data
- 2 different media types
- 1 copy offsite
- 1 copy immutable or air-gapped — object-lock storage an attacker with full control still cannot delete
- 0 errors on restore verification
The final zero is the one that gets dropped, because it is the only one that requires ongoing effort rather than a purchase. Everything before it is architecture. That last digit is a habit.
What a real restore test looks like
Not a backup job that reported success. An actual recovery, to isolated infrastructure, of a system that matters, timed with a stopwatch, run by someone who is not the person who built it. You are testing three things at once: that the data is intact, that the runbook is accurate, and that a normal member of your team can follow it.
Do it with the runbook printed. During a real incident your wiki may be encrypted, your SSO may be down, and your password manager may be one of the systems you are trying to restore.
The numbers you should be able to state
For each tier of system: how much data you can afford to lose (RPO), how long you can afford to be down (RTO), and — separately — the recovery time you have actually measured. The gap between the last two is your real exposure, and it is the only figure in this article worth taking to your board.
Most organisations we assess find that gap is a factor of three or more. Not because the technology is wrong, but because nobody had counted the hours for restoring Active Directory before the application servers, or noticed that the offsite copy restores over a link that takes eleven hours to move a terabyte.