How to Test a Disaster-Recovery Plan: A Step-by-Step Tabletop Exercise

A disaster-recovery plan is only credible when the people responsible for it can explain what they will do, in what order, with what information, and how they will decide that systems are safe to return to service. A tabletop exercise tests those decisions without taking production systems offline. It reveals unclear ownership, missing contacts, unrealistic recovery priorities, dependencies nobody documented, and gaps between a backup report and a usable recovery capability.

You do not need a major cyber incident to justify the exercise. Pick one realistic scenario, bring together the people who would make decisions, work through the first hours of response, capture the gaps, and assign improvements. The value comes from honest discussion and follow-up, not from making the exercise look successful.

What a tabletop exercise tests

A tabletop is a facilitated discussion of a simulated incident. Unlike a technical recovery test, it does not necessarily restore systems or fail over infrastructure. Instead, it tests the operating model around recovery: how the event is detected, who is notified, how priorities are set, how the team communicates, what dependencies exist, and what evidence is needed before business operations resume.

This matters because recovery is rarely a single technical action. A customer portal may depend on identity services, DNS, databases, cloud accounts, payment processors, integrations, third-party SaaS platforms, staff devices, and an up-to-date contact list. A plan that says “restore the server” may not answer whether users can log in, whether data is current, whether security has been re-established, or whether the business can safely process transactions.

Choose the right scenario

Start with a scenario that is plausible and relevant to your business. Avoid beginning with the most complex imaginable catastrophe. A clear scenario is easier to facilitate and more likely to produce actionable improvements.

Common starting scenarios include:

• a ransomware event affecting a shared file system and several user devices;
• a cloud-region outage affecting a customer-facing application;
• accidental deletion or corruption of a critical database;
• a compromised administrator account and suspected unauthorised access;
• loss of a key SaaS platform, identity provider, or internet connection;
• a failed production change that disrupts a core business process; or
• loss of a primary office while staff need to continue serving customers remotely.

The scenario should include enough detail to force decisions. For example: “At 08:15, the service desk receives reports that employees cannot open finance documents. Endpoint alerts show suspicious encryption activity on two devices. The finance shared drive is unavailable. A scheduled payroll file is due to be submitted by 14:00.”

Invite the right people

A recovery exercise is not only for IT. Include the people who own the business outcomes affected by the scenario.

For a small organisation, one person may cover several roles. The important point is to include the people who make decisions, not only those who perform technical tasks.

Prepare in advance

Set aside 60 to 90 minutes for a first exercise. Send participants a short brief in advance: the objective, scope, scenario, start time, and ground rules. State clearly that the session is a learning exercise, not a performance review.

Collect the materials that participants would need in a real incident. These may include a system inventory, application-dependency map, recovery objectives, backup and restore reports, contact list, escalation chart, incident-response procedure, supplier support details, business-continuity plan, and recent change records. Missing documents are themselves useful findings.

Assign a facilitator and a note-taker. The facilitator guides the conversation and introduces “injects”—new facts that simulate how an incident evolves. The note-taker records decisions, assumptions, unanswered questions, and actions without trying to solve everything in the room.

A 75-minute tabletop agenda

0–10 minutes: state the objective and ground rules

Clarify the system or process being tested and what success looks like. For example: “We want to test whether we can prioritise recovery of finance operations, communicate clearly, and make a safe decision about restoring shared data.” Remind participants that it is acceptable to say “we do not know.” That is often the most valuable answer.

10–20 minutes: introduce the incident

Read the initial scenario. Ask participants to describe what they know, what they need to verify, and who should be involved. Do not give them every answer immediately. A real incident begins with ambiguity.

Questions to ask:

• How would we detect this event?
• Who is on call or responsible at this time?
• What is the first containment action?
• Which business processes are affected?
• Who decides whether this is a major incident?
• What information must be preserved before changes are made?

20–40 minutes: test prioritisation and communications

Introduce a business-impact inject: a major customer needs access, a regulatory deadline is approaching, or payroll processing is due. Ask participants to define recovery order and communications.

Questions to ask:

• Which service is restored first, and why?
• What recovery-time and recovery-point objectives apply?
• What manual workaround is available, and who approves it?
• What do employees, customers, suppliers, and leadership need to know?
• Who is authorised to speak externally?
• What would we tell staff not to do?

40–55 minutes: test the technical recovery path

Introduce a constraint: the latest backup is incomplete, a supplier’s support queue is delayed, an administrator account is suspected of compromise, or the recovery environment has an unexpected dependency.

Questions to ask:

• Where is the authoritative backup or recovery copy?
• How do we know it is clean and complete?
• Which identity, network, DNS, certificate, or integration dependencies must be restored first?
• Can we recover to an isolated environment before reconnecting it?
• Who can approve a return to service?
• What checks prove that the service is functioning safely?

55–65 minutes: introduce a secondary complication

Real incidents create pressure. Add one realistic complication, such as a journalist calling, a customer threatening contractual action, an executive asking for an ETA, or a second business system showing suspicious activity.

Use this stage to test decision rights, escalation, and communication discipline. The aim is not to create drama; it is to learn whether the team can keep recovery actions aligned with business priorities.

65–75 minutes: review findings and assign actions

Summarise what worked, what was unclear, and what must change. Every finding should have an owner and target date. Prioritise a few improvements that materially improve recovery capability rather than producing a long list that nobody completes.

Measures of a useful exercise

Do not measure success by whether the team answered every question perfectly. Measure whether the exercise produced clarity and improvement.

Useful measures include:

• time taken to identify the incident lead and decision-maker;
• ability to identify affected systems, owners, and business priorities;
• accuracy and completeness of contact details and escalation paths;
• availability of current recovery objectives and dependency information;
• ability to identify the recovery source and prove it is usable;
• quality of internal and external communication decisions;
• number and severity of gaps found; and
• percentage of follow-up actions completed by the next review.

Practitioner detail: recovery questions that expose hidden gaps

Technical teams should go beyond “do we have a backup?” Ask where backups are stored, whether they are immutable or isolated, who can delete them, whether restoration has been tested, and how long the full recovery actually takes. Confirm whether the backup includes configuration, secrets, identity dependencies, infrastructure definitions, and application data—not merely files or virtual machines.

For cloud and SaaS services, verify administrative access during an incident. If single sign-on or the primary identity provider is unavailable, can authorised administrators still access the recovery console? If a vendor account is compromised, do you have out-of-band contacts and an escalation path? If recovery depends on a third party, what is their stated and observed response process?

Document the definition of “recovered.” A server being online is not necessarily a business service being restored. The service may still be missing users, data, integrations, security controls, monitoring, or customer functionality. Include business-process owners in acceptance testing and record who approved return to service.

Turn findings into a routine

Run a focused tabletop at least annually and when the environment changes materially. Consider shorter exercises after introducing a new critical supplier, migration, major application, identity platform, or recovery strategy. Rotate scenarios so the organisation tests different failure modes rather than repeating the same familiar script.

Pair tabletop exercises with technical restore tests. The tabletop tests people and decisions; the restore test proves that data and systems can be recovered. Together, they provide far more confidence than a backup-success notification alone.

Need help mapping recovery priorities, testing continuity assumptions, and turning exercise findings into a practical resilience plan? Managed Company can help structure tabletop exercises, validate recovery dependencies, document action plans, and strengthen the infrastructure controls that support reliable business continuity. Explore Infrastructure Management support or ISO 27001 Preparation for your company.