How to Run a Disaster Recovery Tabletop Exercise

A disaster recovery tabletop exercise is a facilitated discussion in which the people who would respond to a real outage work through a realistic scenario, make decisions, expose dependencies and identify gaps. It is deliberately different from a technical failover test: the tabletop tests readiness of people, decisions, procedures and coordination; it does not prove that infrastructure will actually recover.

1. Start with a business service, not a technology

Choose one critical service and describe what the business needs from it. Identify the application, database, network, identity, third-party and operational dependencies that matter to recovery. AWS recommends exercising workload-impacting events with the same teams that would handle a production event and incorporating lessons learned back into recovery processes.

2. Define objectives and success criteria before the exercise

Write down what you want to learn. Useful objectives include whether the team can declare a disaster, identify the correct recovery strategy, assign owners, make decisions within the recovery window, communicate with stakeholders and determine when service is safe to declare recovered.

3. Bring the people who would actually respond

Typical participants include the service owner, infrastructure or cloud operations, application and database owners, networking, security, business leadership and communications. Add vendors or other teams when the service depends on them. Avoid running a purely technical exercise when business decisions determine priorities or acceptable downtime.

4. Establish RTO and RPO targets

Put the agreed recovery time objective and recovery point objective in front of the team before the scenario starts. The exercise should force participants to make choices under those constraints rather than discussing recovery in unlimited time.

5. Use a scenario that creates decisions

A useful scenario does not need pages of narrative. It needs enough information to create uncertainty and decisions. Examples include a primary Region or site outage, database corruption, network failure, identity-provider outage, failed backup or restore, or loss of a critical SaaS dependency.

6. Advance the scenario and record decisions

For each significant action, capture the owner, expected duration, dependencies and result. If two independent recovery activities can happen in parallel, treat them that way. Failed attempts should consume simulated time. Keep an immutable event timeline so the after-action review reflects what the team actually decided rather than a cleaned-up version created afterward.

7. Do not declare recovery too early

“The server is running” is not the same as “the business service is recovered.” Define recovery gates such as data availability, application health, authentication, network access, dependent services and business validation. The facilitator should only declare recovery when the agreed gates have been satisfied.

8. Finish with a hotwash and corrective actions

Immediately after the scenario, ask what worked, what slowed the team down, what information was missing and what should change. NIST guidance recommends capturing observations against pre-defined evaluation criteria and using the debrief and lessons learned in an after-action report.

A practical 60–90 minute agenda

1. 10 minutes: objectives, scope, rules, RTO/RPO and participant roles.
2. 35–55 minutes: scenario, decisions, injects and recovery planning.
3. 10 minutes: recovery declaration and validation discussion.
4. 15 minutes: hotwash, gaps, owners and corrective actions.

What the tabletop should produce

At minimum, keep the event timeline, key decisions, unresolved assumptions, RTO/RPO outcome, corrective actions with owners, and changes required to plans or runbooks. Any recovery runbook produced from a tabletop should be treated as an exercise-derived draft until it has been technically validated.

References

Further reading: AWS Well-Architected Framework, REL12-BP05 (conduct game days regularly) and REL13 (disaster recovery planning); NIST SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities.