A backup is one part of recovery. Consider the people, priorities and dependencies needed to get meaningful work moving again.
Define what recovery means for the business
The question 'Do we have backups?' is useful, but it does not describe everything a business needs during disruption. A technical service may be restored while employees still lack access, a supplier remains unavailable or no one is authorized to resume a sensitive activity. Recovery planning needs a view of the work itself.
Start with a business activity and describe what a minimum workable service would look like. Could staff accept orders using a temporary process? Which information would they need? Who would authorize that arrangement, and what would happen to the records afterward? These questions help translate an abstract recovery discussion into practical operating choices.
Agree priorities before an interruption
Different stakeholders may assume their systems will return first. Bring those assumptions into the open by discussing the consequences of interrupted activities over time. Consider customer commitments, dependencies between processes and the people needed to restart work. The outcome should be a reasoned sequence that technical and business stakeholders can review together.
For an illustrative distributor, access to order information might be needed before dispatch can resume. Restoring a reporting tool first may offer little immediate operational value. Another business could have a different order of priorities. The plan should explain these dependencies and provide a way to revisit them when the operating model changes.
Check the assumptions behind the backup
CISA's StopRansomware Guide recommends maintaining offline, encrypted backups and regularly testing their availability and integrity in a disaster recovery scenario. The practical lesson is to verify recovery arrangements, rather than infer readiness from a successful backup notification. Testing should follow an agreed scope and avoid disrupting live business operations.
Ask who can initiate a restore, what access they require and where the instructions are kept. Identify any services, credentials or supplier support needed to complete the process. Record what has actually been tested and what remains an assumption. A partial test can be useful, provided its limits are understood and the remaining questions have owners.
Walk through decisions and communication
A discussion exercise can start with a simple situation: a critical platform is unavailable at the beginning of the working day. Ask who recognizes the disruption, who coordinates the response and who can approve temporary ways of working. Then consider how staff and other relevant stakeholders would receive updates if their usual communication channel were also unavailable.
Keep the exercise focused on decisions and information needs. If someone says they would contact a supplier, check whether the contact route is documented and available. If a workaround is proposed, ask who understands it and what its limits are. Capture unanswered questions as actions instead of filling gaps with optimistic assumptions during the meeting.
Close the loop after the exercise
The value of a recovery discussion depends on what happens afterward. Assign an owner to each material gap, agree the next action and set a review point. Where an assumption changes, update the relevant plan or procedure. Keep essential information accessible to the people who need it, including when normal systems are unavailable.
Readiness is specific to the scenario and arrangements you have considered. A successful exercise does not show that every disruption can be handled. It does provide evidence about particular decisions, dependencies and recovery steps. Use that evidence to refine the plan and choose the next question to test as the business and its technology evolve.