Observable condition
The backup dashboard is green. Files are copied. Snapshots exist. Management therefore assumes the business can recover from a serious failure.
Then a real incident asks harder questions: which systems must return first, which application depends on which database, whether credentials and configuration are recoverable, how long restoration actually takes, and whether the restored environment is clean and usable.
An illustrative example
The following scenario is illustrative and does not describe a specific organisation. A professional services firm loses its main server to a hardware fault. The nightly backup is intact, and the data is restored to new hardware within a day. But the practice management application will not start: its licence is tied to the old machine, the database connection settings were never recorded, and the person who installed it left two years ago. Staff can open their documents but cannot record time, raise invoices or see client matters. The backup worked. The service did not come back.
Warning signs
- The evidence of protection is a backup job report, not a restore result.
- Restores happen only for individual lost files, never for a whole service.
- Nobody can say how long a full recovery of a critical system would take.
- Recovery documentation lists systems, not the business services they support.
- Passwords, licences, configuration and integration settings live in people's heads or on the systems being protected.
- Backup storage is permanently connected to the same network and accounts as production.
Realisation
A backup is evidence that data or system state has been copied. Resilience is evidence that the business can restore the services it depends on within an acceptable period and with acceptable loss. The two are related, but they are not the same thing, and the gap between them is where most of the recovery effort actually sits.
NIST's OT Backup Quick Start Guide (SP 1339, June 2026) describes effective backup management as integrating backups into change management, creating them regularly, testing them and reviewing them during recovery exercises. The UK National Cyber Security Centre's guidance on backing up your data makes the same point for smaller organisations: once a backup exists, it is important to know how to restore it and to check that it contains all the important data. It also advises that an external backup device should not stay connected when not in use, because some malware affects connected devices. The underlying principle is broader than any one technology: recovery must be exercised, not assumed, and backups must be protected from the incidents they exist to recover from.
Realisation prompt. When did your business last prove that it could restore a critical service, not merely confirm that a backup file exists?
Why the condition persists
Backup is easy to measure and easy to buy. A job either completes or it does not, and the result appears on a dashboard every morning. Recovery is harder to measure because it only happens under pressure, and testing it properly takes time, disruption and coordination across teams. The comfortable metric replaces the difficult one, and confidence grows without evidence.
Identification
This is a recovery-readiness and service-resilience problem. The visible condition is "we have backups". The structural question is whether people, systems, dependencies and recovery procedures can reconstruct the service the business actually needs.
Diagnosis
Backup confidence can hide weak recovery design when:
- restores are rarely or never tested end to end;
- critical service dependencies are undocumented;
- recovery priorities are based on systems rather than business services;
- credentials, configurations, integrations or infrastructure definitions are excluded;
- recovery responsibilities are unclear during an incident;
- the organisation has not defined tolerable downtime or data loss.
A technically successful restore can still fail commercially if the wrong service returns first or the business cannot reconnect the dependent workflow. NIST's contingency planning guide, SP 800-34 Rev. 1, frames this as evaluating systems and operations to determine contingency requirements and priorities, and connects system-level planning to wider organisational resilience, incident response and disaster recovery. The emphasis on priorities matters: a recovery plan is a sequence, and the sequence should follow business consequence.
The dependency question is often the weakest link. If the finance system restores but its identity provider, file share or bank integration does not, the business still cannot pay suppliers. For more on that mechanism, see when nobody knows which services depend on which systems.
Commercial impact
The commercial value at stake is uptime, revenue protection, resilience and scalability. Recovery uncertainty lengthens outages, increases operational improvisation and can turn a contained technical failure into a larger business interruption.
As infrastructure becomes more interconnected, the commercial unit to protect is increasingly the service or process, not an isolated server or file set. Untested recovery also distorts decisions during an incident: leaders cannot judge whether to wait for restoration, switch to manual workarounds or tell customers, because nobody knows how long recovery will take.
Common misidentification
The common mistake is to equate backup completion with recovery readiness. Another is to buy more backup capacity without defining recovery objectives or testing the restoration path.
More copies can improve protection, but they do not replace dependency mapping, prioritisation and exercises. A third copy of data that cannot be turned back into a working service adds cost without adding much resilience.
Possibility
A more resilient state starts with business-critical services and works backward to the systems, data, identities, integrations and configurations required to restore them. Recovery procedures are tested, ownership is explicit and results are used to improve the design.
In that state, the business can answer three questions with evidence: what comes back first, how long it takes, and how much data might be lost. The NCSC's 10 Steps guidance on incident management recommends linking incident response plans to disaster recovery, business continuity and crisis management plans, and notes that a practised plan helps people make good decisions under the pressure of a real incident.
Intervention
Identify the services whose interruption would materially affect customers, revenue, safety or operations. Map their dependencies, define recovery objectives, confirm what is actually backed up and run controlled restore exercises. Record how long recovery takes, what fails and what must change.
A practical first exercise:
- Choose one critical service and write down what "recovered" means in business terms, such as invoices can be raised or orders can be taken.
- List everything the service needs: data, application, identities, licences, configuration, integrations and suppliers.
- Check each item against what is actually backed up and where the copy is held.
- Restore into an isolated environment and time each stage.
- Record the gaps and assign owners to close them before the next exercise.
The intervention may include backup architecture, immutable or offline protection, infrastructure-as-code, disaster-recovery design, recovery runbooks, dependency mapping and regular exercises. The target is recoverable business capability.
Practical diagnostic questions
- When was the last successful end-to-end restore test?
- Which business service must recover first after a major failure?
- Are identities, configurations and integrations included in recovery planning?
- Can the organisation state its acceptable downtime and data-loss tolerance?
- Who owns recovery decisions during an incident?
- Are backups protected from the same accounts and network as the systems they protect?
Bottom line
Backups are necessary, but they are not the same as resilience. The stronger test is whether the organisation can restore the business service, in the right order, within a period the business can tolerate, and has proved it recently.
Related Mellorca reading
- The Financial Cost of Backups That Have Never Been Tested
- What Service Levels Make Sense for Business-Critical Automations?
- Why Business Systems Need Ongoing Stewardship
Sources and further reading
- OT BACKUP QUICK START GUIDE (last verified 10 October 2026)
- Backing up your data (last verified 10 October 2026)
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems - CSRC (last verified 10 October 2026)
- Incident management (last verified 10 October 2026)
- #StopRansomware Guide - CISA (last verified 10 October 2026)