Tabletop vs Simulation vs Full Interruption Test

Most resilience programmes run the wrong exercise for the question they need answered: tabletops where only a live switchover would prove the recovery time, or a full interruption test on a plan nobody has rehearsed. Tabletop exercises, simulations and full interruption tests sit on one ladder, but each answers a different question, carries a different risk to production and produces different evidence. This guide compares the three side by side: what each proves, what can go wrong while running it, how to define success, and which regulatory and standards expectations (DORA, ISO 22301, NIST SP 800-34 and SP 800-53 CP-4) each one satisfies. It is written for resilience managers, IT disaster recovery owners and CISOs who have to choose and defend an annual exercise plan. For how to design and facilitate a tabletop, see the Tabletop Exercise Guide; this page is about choosing between exercise types, not running any one of them.

Key takeaways

Each type answers one question. A tabletop asks "do we know what to do", a simulation asks "can we do it under time pressure", and a full interruption test asks "does the service survive without the primary at all".
Risk rises faster than evidence. A tabletop cannot cause an outage; a full interruption test can turn into one. Each rung should only be climbed once the rung below has passed cleanly.
Regulators want proof, not discussion, for critical services. DORA Article 11(6) requires yearly testing of ICT business continuity and response and recovery plans, including switchover scenarios for non-microenterprises, which a tabletop alone does not demonstrate.
Write success criteria before the exercise. Timed objectives against the recovery time objective (RTO) and recovery point objective (RPO), decisions made within agreed windows and named corrective actions are what make any exercise auditable.
Most failures are design failures. Rehearsed scripts, scope that excludes identity and DNS, no rollback plan and corrective actions that never close undermine every exercise type.

The short answer

Use a tabletop when a plan is new or changed, when the main risk is decision-making (authority, escalation, communications, regulator notification) or when executives need to rehearse. Use a simulation when the plan is understood and you need to prove that people and tools can execute recovery tasks inside the RTO without touching production. Use a full interruption test only when simulations and planned failovers have already passed, when a regulator, customer or your own risk appetite demands evidence that nothing hidden depends on the primary site, and when you have a tested way back.

Terminology varies across sources. NIST SP 800-34 Rev. 1 describes tabletop exercises as discussion-based sessions where personnel talk through their roles in response to a scenario presented by a facilitator, with no equipment or resources deployed, and functional exercises as letting personnel perform their duties in a simulated operational environment. The US Homeland Security Exercise and Evaluation Program (HSEEP, January 2020) uses tabletop for discussion and drill, functional and full-scale for operations-based exercises. "Simulation" in business continuity practice usually maps to a functional exercise. "Full interruption" is practitioner language for actually taking the primary site, region or platform out of service; NIST's closest term is the full-scale functional exercise, which includes failover to the alternate location and full recovery and reconstitution to a known state.

Side-by-side comparison

Dimension	Tabletop exercise	Simulation (functional exercise)	Full interruption test
Question answered	Do people know the plan, their roles and decision rights?	Can teams perform recovery tasks, in order, within target times?	Does the service run without the primary, and can it come home?
What is real	Nothing: discussion of a scenario	People, runbooks and tools; systems are test or isolated copies	Everything: the primary is shut down or isolated, live traffic moves
Production risk	None	None to low, if isolation holds	High: a failed test is a real outage
Cost and effort	Low: facilitator, scenario, room	Medium: control cell, test environment, injects, evaluators	High: change approval, customer notice, standby staff, rollback
Evidence produced	Decisions, gaps in plans, actions	Timings against RTO and RPO, task completion, tool failures	Real service metrics, customer impact, failback time
Finds best	Unclear authority, missing contacts, notification gaps	Runbook errors, access failures, dependency order, staffing	Hidden dependencies on the primary, capacity limits, failback faults
Misses	Whether anything actually works	Live load, external integrations, partner allow lists	Little, but at the price of risk
Maturity needed	Any	Documented and walked-through plan	Proven simulations and planned failovers

The Disaster Recovery Testing Guide breaks the technical middle of this ladder into component, isolated and planned failovers; the Cyber Incident Exercises Beyond Tabletop Guide covers drills and functional exercises for incident response teams.

Tabletop exercise: risk, failure modes and success criteria

Threat model: the risk being tested is human and procedural. Who declares a disaster, who can approve paying for emergency capacity, who talks to the regulator, what happens when the incident lead is unreachable.

How it works: a facilitator walks a cross-functional group through a scenario in timed stages, adding injects (new facts) at each stage. Participants say what they would do, with which plan and which authority. A scribe records decisions and gaps.

Exercise risk: none to systems. The real risks are reputational inside the organisation (an executive embarrassed in front of peers) and false assurance, where a smooth discussion is reported as proof of recoverability.
Failure modes: scenarios so generic that every answer is "we would follow the plan"; the people who will actually do recovery are absent; the session becomes a lecture; actions are recorded but never assigned.
Success criteria: each decision point has a named owner and a time; every plan reference resolves to a current document; notification triggers (for example the DORA major incident classification) are identified correctly; every gap becomes a corrective action with an owner and date in the Tabletop Exercise After Action Report Template.
Controls: a no-fault rule, a facilitator who is not the plan owner, and a report that states it tested decisions, not technology.

Worked scenario: a payments firm adopts a new incident classification process after DORA applies. A two-hour tabletop takes the crisis team through a ransomware outage of its card authorisation platform. The team discovers that nobody is named to decide when the incident becomes "major" and that the regulator contact list is held only in the encrypted file share. Both become corrective actions. Ready-made scenarios are in the Tabletop Exercise Scenario Pack.

Simulation: risk, failure modes and success criteria

Threat model: the risk being tested is execution. Runbooks with missing steps, recovery tools that no one can sign in to, restore jobs slower than the RPO assumes, and teams that cannot coordinate across infrastructure, identity, application and communications roles under time pressure.

How it works: a control cell plays the outside world (customers, suppliers, regulators, the attacker) and issues injects from a master scenario events list (MSEL). Players perform real tasks against test systems, isolated recovery copies or a fenced recovery network: restoring databases, promoting replicas in an isolated bubble, rotating credentials for a test service, standing up out-of-band communications. Evaluators time each task against the targets in the plan. HSEEP describes the functional exercise as testing capabilities and functions in a realistic, real-time environment, with the movement of resources usually simulated.

Exercise risk: low, but not zero. The common incidents are leakage from the test environment into production: a recovered server that registers in production DNS, a recovered domain controller that replicates, duplicate machine identities, or a script run against the wrong subscription.
Failure modes: testing in an environment that does not resemble production; pre-staging data or credentials so the test cannot fail; excluding identity providers, DNS and secrets from scope; stopping the clock when a task "would have worked".
Success criteria: each critical recovery task completed within its target time, measured from the inject, not from when the team started; recovered services pass functional checks; staff sign in to the recovery environment with their normal break-glass or recovery accounts; issues are logged as they happen.
Controls: network isolation verified before the start, an exercise-stop phrase, a no-play list of production systems, trusted agents who know the scenario, and a cleanup step that removes all recovered copies.

Worked scenario: the same payments firm runs a one-day simulation of the loss of its primary cloud region. Infrastructure recovers the authorisation service into an isolated network in the secondary region. The database restores in 70 minutes against a 60 minute RTO, and engineers cannot sign in because the recovery accounts depend on the identity provider in the failed region. Both are fixed and retested in a drill a month later.

Full interruption test: risk, failure modes and success criteria

Threat model: the risk being tested is hidden dependency. A licence server, a hard-coded IP address, a certificate bound to a primary hostname, an external partner that only allow-lists the primary egress addresses, a batch job scheduled from the primary site. Only removing the primary entirely proves none of these exist.

How it works: the primary site, region, data centre or platform is deliberately taken out of service, usually in an agreed change window. Live workload moves to the recovery site, runs there for a defined period, and is then failed back.

Exercise risk: high. If recovery fails, the test is a real outage of a critical service, with customer impact, possible regulatory reporting and data inconsistency between sites. Failback carries its own risk: replication must be reversed and verified before traffic returns.
Failure modes: running it before simulations have passed; no tested abort criteria; customers, suppliers and supervisors not told in advance; failback not planned, leaving the business on the recovery site for weeks; a partial interruption described as full in the report.
Success criteria: service restored at the recovery site within RTO with data loss inside RPO; external integrations and customer journeys verified with real traffic; the service runs for the agreed period without manual intervention; failback completed within its own target; no unplanned customer impact beyond what was approved.
Controls: formal change approval with business sign-off, explicit go/no-go and abort criteria, a rollback path that does not depend on the failed primary, customer and supervisor communication, and senior decision makers on standby throughout.

Worked scenario: after two clean simulations and one planned failover, the payments firm takes its primary region out of service for six hours on a low-volume Sunday. The authorisation service recovers in 38 minutes. A fraud scoring partner rejects traffic from the recovery region's addresses, which no earlier test had exercised because test traffic never reached the partner. The firm fails back on schedule and adds the addresses to the partner contract.

Regulatory and standards drivers

The table shows what each source expects and which exercise type typically satisfies it. Confirm against the source text and your supervisor's guidance.

Source	What it requires or describes	Exercise types that fit
DORA (Regulation (EU) 2022/2554) Art. 11(6)	Test ICT business continuity plans and ICT response and recovery plans at least yearly and after substantive changes to ICT systems supporting critical or important functions; non-microenterprises include cyber-attack scenarios and switchovers between primary and redundant capacity	Tabletop for plan and decisions; simulation or planned failover for switchover evidence
DORA Art. 12(2)	Periodic testing of backup procedures and restoration and recovery procedures and methods	Simulation (restore and recovery in isolation)
DORA Art. 24	A risk-based digital operational resilience testing programme, tests undertaken by independent parties (internal or external), appropriate tests on all ICT systems and applications supporting critical or important functions at least yearly	All types, chosen by risk
DORA Art. 26	Threat-led penetration testing (TLPT) at least every 3 years for entities identified by competent authorities	Separate from continuity exercises; see the DORA Resilience Testing Guide
ISO 22301:2019 clause 8.5	An exercise programme that validates business continuity strategies and solutions over time, with exercises based on appropriate scenarios, post-exercise reports and improvement actions	Progressive mix of all three
NIST SP 800-34 Rev. 1	Tabletop for low-impact systems, functional exercise for moderate-impact systems, full-scale functional exercise (including alternate site failover and full recovery and reconstitution) for high-impact systems	Maps directly onto the three rungs
NIST SP 800-53 Rev. 5 CP-4	Test the contingency plan to determine effectiveness and readiness; CP-4(1) coordinate with related plans; CP-4(2) test at the alternate processing site; CP-4(4) full recovery and reconstitution	CP-4 base: any; CP-4(2) and CP-4(4): simulation at the alternate site or full interruption

For DORA scope and definitions see the DORA Guide; for UK supervisors' impact tolerance and scenario testing expectations see the UK Financial Operational Resilience Guide; and for the management system clauses see the ISO 22301 Business Continuity Guide.

Choosing the right exercise

Decision criteria

Plan maturity: a plan that has never been walked through gets a tabletop first.
Service criticality and impact tolerance: services supporting critical or important functions need operational evidence (simulation or failover) at least yearly; low-impact services may be adequately covered by tabletop and plan review.
Architecture: active-active services have no failover event, so "full interruption" means draining a site and confirming the rest absorbs the load. Active-passive services need a switchover test to prove anything about RTO.
Change: a substantive change (new platform, region or provider) restarts the ladder for that service.
Risk appetite and business calendar: a full interruption test needs a window where an outage would be survivable.
Third parties: if recovery depends on a provider, the provider must participate. The DORA Critical ICT Third-Party Provider Oversight Guide covers provider obligations.

Small versus large organisations

Small organisations: two tabletops a year plus one isolated simulation of the few systems that matter is realistic and defensible. Free scenarios come from the NCSC Exercise in a Box (20 exercises across 12 topics) and CISA Tabletop Exercise Packages. Full interruption is rarely justified unless a key customer contract requires it.

Large organisations: tier services by criticality, run simulations of tier 1 services at least yearly (automated where possible), and schedule full interruption or site-drain tests on a rotating basis, so every tier 1 service and shared dependency is covered over a cycle.

Building the progression

HSEEP describes a progressive approach: a series of exercises tied to common priorities with increasing complexity, each building on the last, though not necessarily in a fixed sequence. A practical progression for one critical service:

Plan review and tabletop: confirm the plan matches current architecture, contacts and decision rights. Exit criterion: no open critical actions.
Component drills: time single tasks, such as a database restore, a replica promotion, a DNS change, a break-glass sign-in. Exit criterion: each task meets its target twice.
Simulation in isolation: recover the whole service in a fenced network with a control cell and injects. Exit criterion: service recovered within RTO and RPO with no leakage into production.
Planned failover: move live traffic to the recovery site with the primary available as a fallback. Exit criterion: customer journeys and integrations work on real traffic; failback succeeds.
Full interruption: remove the primary for an agreed window. Exit criterion: success criteria above met, with no unapproved customer impact.
Roll back the ladder after change: a major change returns the service to step 1 or 3, depending on how much of the recovery path changed.

Use the Business Impact Analysis Template to set the targets each step measures, and the RTO and RPO Guide for how to measure them.

Where identity fits

Identity is the dependency most often left out of exercises. Simulations and full interruption tests should include the identity provider, privileged access tooling, break-glass accounts, service accounts and secrets stores in the recovery path, and should have the people who perform recovery sign in with the accounts they would really use. See the Secrets Manager Resilience Guide and the identity scenarios in the Identity Attack Tabletop Exercise Scenarios.

Detection and measurement

Recovery time achieved vs RTO: per critical service, measured from the inject or interruption to verified service, for simulations and full interruption tests.
Data loss achieved vs RPO: the gap between the last consistent recovery point and the interruption time.
Exercise coverage: percentage of critical or important functions exercised at the operational level (simulation or above) in the last 12 months.
Decision latency: time from inject to key decisions (invoke the plan, declare a major incident, notify the supervisor) in tabletops and simulations.
Corrective action closure: percentage of actions closed by their due date, and the number of findings repeated from a previous exercise.
Exercise-induced incidents: production incidents caused by the exercise itself; target zero.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	CP-4, CP-4(1), CP-4(2), CP-4(4)	Contingency plan testing, coordination, alternate site and full reconstitution
NIST SP 800-53 Rev. 5	IR-3, IR-3(2)	Incident response testing coordinated with related plans
NIST CSF 2.0	ID.IM-02	Improvements identified from security tests and exercises, including with suppliers
NIST CSF 2.0	RC.RP-01	Recovery portion of the incident response plan is executed
ISO/IEC 27001:2022 Annex A	5.30 ICT readiness for business continuity	ICT continuity planned, implemented, maintained and tested
ISO 22301:2019	Clause 8.5	Exercise programme
DORA	Art. 11(6), 12(2), 24, 26	Continuity testing, backup testing, testing programme, TLPT

Common failure patterns

Reporting a tabletop as recovery evidence: the discussion went well, so the service is declared recoverable. A tabletop cannot show that anything works.
Skipping rungs: attempting a full interruption test because a regulator or customer asked for one, before simulations have passed. The test becomes the outage it was meant to prevent.
Scripted success: the same scenario every year, with pre-staged data and participants who know the injects. Timings improve while real capability does not.
Out-of-scope dependencies: identity, DNS, certificates, secrets and third parties are excluded "to keep the test simple", which removes the most common causes of real recovery failure.
No way back: failover is tested but failback is not, leaving the business on the less resilient site after the test.
Actions that never close: the same findings recur in consecutive after-action reports.

Decision checklist

Has the plan for this service been reviewed and walked through since its last substantive change? If not, run a tabletop.
Are RTO and RPO targets defined from a business impact analysis, and written into the exercise objectives?
Has each critical recovery task been timed in a drill or simulation, and has it met its target twice?
Is isolation of the test environment verified, with a stop phrase and a no-play list, before any simulation starts?
Are identity, DNS, secrets and key third parties inside the scope of the operational exercise?
For a full interruption test: are go/no-go and abort criteria, rollback, failback and customer and supervisor communication approved?
Does the exercise schedule cover every critical or important function at the operational level at least yearly, as DORA Article 11(6) and Article 24(6) expect for in-scope entities?

Practitioner checklist

Map every critical service to the highest exercise rung it has passed and the date it passed.
Write measurable success criteria (times, data loss, decision windows) into every exercise plan.
Run simulations in a verified isolated environment and clean it up afterwards.
Require participants to sign in with their real recovery and break-glass accounts.
Test failback as a separate, timed objective.

Tabletop vs Simulation vs Full Interruption Test: Choosing the Right Resilience Exercise