A backup schedule is not a recovery plan, and a recovery plan that has never been tested is an assumption, not a capability. Leadership needs to decide what must come back, how quickly, and who is accountable for making that happen—before an incident forces the answer.
The decision to enable
Decide which systems must recover, in what order, within what timeframe, and who owns the recovery—confirmed before an incident, not during one.
01
Name what must come back, and in what order
Not every system matters equally during a disruption. Identify which systems are required to serve customers, pay people, and protect access, and which can wait—then sequence recovery against that priority rather than technical convenience.
Systems required within hours versus days
Dependencies between systems that affect recovery order
Who confirms a system is genuinely usable again, not just running
02
Set a recovery time and data-loss tolerance for each priority tier
How quickly a system must return, and how much recent data the organization can afford to lose, are business decisions—not technical defaults. State both explicitly for each tier so backup design and recovery testing have a real target to meet.
03
Separate the backup from the ability to restore
A backup that has never been restored is unverified. Confirm restoration is actually tested on a known schedule, that the people who would perform it know how, and that the process works without relying on one specific individual being available.
04
Decide who is accountable during a real disruption
Name who declares an incident, who authorizes the recovery sequence, who communicates with staff and clients, and who confirms the incident is over. A plan without named accountability becomes improvisation when it is actually needed.
Decision frame
What leadership should be able to verify.
These criteria do not produce a score. They expose the questions that need resolution before a responsible decision.
CriterionUseful signalLeadership question
PrioritySystems are ranked by business consequence, not technical convenience.What genuinely cannot wait if this system is unavailable?
TargetsRecovery time and acceptable data loss are stated for each priority tier.How fast must this come back, and how much recent data can be lost?
Verified restorationRestoration is actually tested on a known schedule, not assumed to work.When was restoration last tested, and who confirmed it worked?
AccountabilityNamed people own declaration, execution, and communication during an incident.Who is authorized to declare an incident and lead the response?
Practical scenarios
The same discipline applied to different decisions.
A ransomware incident affects file storage and email
Situation: Systems become unavailable or untrusted, and leadership must decide what to restore first and how to communicate with staff and clients during the outage.
Useful response: Follow the pre-agreed priority order and communication plan rather than improvising sequence under pressure, and confirm restored systems are genuinely clean before returning them to use.
Boundary: This guide does not provide incident response services or forensic investigation.
A single administrator holds undocumented recovery knowledge
Situation: The person who understands how backups and recovery actually work is unavailable when an incident occurs.
Useful response: Treat this as a governance gap to close before the next incident: document the recovery process, assign a secondary contact, and test that someone else can execute it.
Boundary: This guide does not replace a documented, tested runbook with generic advice.