A backup that has never been restored is a hypothesis. Organisations discover this during the incident rather than before it, which is the most expensive possible moment. Resilience is not the absence of failure; it is the demonstrated ability to recover from one within a time you decided in advance.
The two numbers that determine everything else
Recovery point objective is how much data you can afford to lose, expressed as time — if you back up nightly, your RPO is up to twenty-four hours. Recovery time objective is how long you can afford the service to be unavailable.
These are not IT decisions. They are business decisions about what an outage costs per hour and what the organisation is willing to spend to shorten it. Until they are stated per service and agreed by the people accountable for that service, no infrastructure design can be judged adequate, because there is nothing to judge it against.
They also differ sharply by service. A payroll system may tolerate a day; a clinical system or a payment gateway may not tolerate an hour. Applying one target to everything either overspends on the trivial or underprotects the critical.
Test the restore, and time it
A backup job reporting success confirms that data was written somewhere. It says nothing about whether that data can be read back, whether it is internally consistent, whether the restore procedure is documented, or whether anyone still working at the organisation knows how to execute it.
The only meaningful test is a restore into a clean environment, performed by someone following the written procedure, and timed. If the restore takes eleven hours against a four-hour objective, the design has failed — and it is far better to learn that on a Tuesday afternoon than during an incident.
Test at least quarterly for business-critical systems, and after any significant schema, platform or infrastructure change. Record each test with its date, scope, duration and outcome. That log is also the single most persuasive artefact you can produce in an audit.
Map what everything quietly depends on
Systems described as independent often share a switch, a power feed, an authentication service, a virtualisation host, an administrator or a supplier. Any of those is a single point of failure capable of taking down several services that were each individually designed to be resilient.
Mapping dependencies is unglamorous and repeatedly worthwhile. Once mapped, each single point of failure becomes a decision: remove it, or accept it explicitly with a named person recording that acceptance. Both are legitimate. Not knowing is not.
Rehearse the plan, because that is where it fails
Continuity plans rarely fail on technology. They fail because the contact list is out of date, the person authorised to declare an incident is unreachable, credentials for the recovery environment are held by someone on leave, or nobody agreed who tells the regulator and the public.
A tabletop exercise — walking a realistic scenario through with the people who would actually be involved — surfaces these gaps in an afternoon. Running one annually, and after significant organisational change, is the difference between a plan that exists and a plan that works.
Written by
Login Technologies
Published 11 Jul 2026. If you would like to discuss anything in this article in the context of your own programme, we are happy to talk it through.
Start a conversation
