Almost every organisation that pays a ransom had backups running. That is the uncomfortable statistic behind modern incident response. The backups existed; they just could not be used — because they were encrypted alongside production, or because restoring would have taken three weeks the business did not have.
A backup job that completes successfully is not a recovery capability. Three measurements separate the two.
Recovery Point Objective is the age of the data you restore from. A nightly backup completing at 2am means a Friday afternoon incident costs you a full day of work — every order, ticket and invoice since the last run.
The point is not to drive RPO to zero everywhere; that is expensive and usually unnecessary. It is to make the number explicit per system. Finance and order management might justify a 15-minute RPO. A file share of historical documents might be fine at 24 hours. What causes damage is discovering the number for the first time during an incident.
Recovery Time Objective is how long restoration takes. This is where estimates diverge from reality most sharply, because RTO is rarely dominated by the restore itself. It is dominated by decision-making, by locating credentials for systems nobody has rebuilt in two years, by rebuilding domain controllers before anything else can authenticate, and by dependency order.
Teams that have actually run the drill report recovery times two to five times longer than their pre-drill estimate. That gap is the whole problem.
Modern ransomware operators specifically hunt backups before triggering encryption. They have been inside the network for weeks; they have domain admin; they know where the backup server is. If your backups can be deleted using credentials that exist on the network, assume they will be.
Immutable storage — write-once, delete-protected for a defined retention window — removes that option. It is the single highest-value change most organisations can make to their backup posture, and it is now available across major cloud object storage and most modern backup platforms.
The classic 3-2-1 rule has been extended for exactly this threat:
That trailing zero carries most of the weight. An untested backup is a hypothesis.
A meaningful restore test does not mean opening a file from last night's job. It means restoring a business system into an isolated environment, timing it, having someone who was not involved in building it perform the restore, and writing down where it went wrong. The findings are always useful and rarely flattering.
We run these tests quarterly for clients as part of managed backup. If your last verified restore was more than six months ago — or you are not sure — that is worth a conversation.