Business Continuity Plan Testing: Exercise Types, Tabletops and Audit Evidence

Short answer: Business continuity plan testing means exercising your plan on a schedule to prove people, processes and systems can recover within your targets. Most SMBs combine an annual plan review, one or two tabletop exercises and at least one technical recovery test, then record results in an after-action report and update the plan.

Related guides:

• How to create a business continuity plan
• Business continuity and disaster recovery plan: template and requirements
• How to develop an effective disaster recovery plan

Key takeaways

• A plan that has never been exercised is an assumption. Testing turns it into evidence that recovery actually works within your RTO and RPO.
• Exercise types range from a desk review to a full interruption. Most SMBs get the best return from tabletop exercises plus targeted failover and restore tests, not full shutdowns.
• HIPAA, SOC 2 (availability), ISO/IEC 27001 and ISO 22301 all expect some form of periodic testing and revision. None of them prescribe one exact exercise format for every organization.
• Auditors look for a dated after-action report, named participants, findings, owners and proof that the plan was updated afterwards.
• Update the plan after every exercise, real incident and significant change.

What are the types of business continuity exercises?

There are five common exercise types, and each one proves something different at a different cost.

NIST SP 800-84, NIST's guide to test, training and exercise programs for IT plans, describes tabletop exercises as discussion-based sessions where personnel talk through their roles in an emergency, and functional exercises as events where people perform their duties in a simulated operational environment. The table below extends that into the five formats most teams use.

Exercise type	What happens	Typical effort	What it proves	What it does not prove
Plan review / walkthrough	Owners read the plan section by section and check contacts, dependencies and procedures	1–2 hours per owner	The plan is current and complete on paper	That anyone can execute it under pressure
Tabletop exercise	A facilitator walks a team through a scenario and asks what each person would do	Half a day plus prep	Roles, decisions, escalation and communications are understood	That systems actually recover in time
Functional / simulation exercise	People carry out real tasks in a simulated environment, such as activating the call tree or switching to manual workarounds	1 day plus prep	People can perform their duties and tools work as expected	Full production recovery
Failover / technical recovery test	Engineers restore backups, fail over a database or rebuild a service in a secondary region	Hours to days of engineering time	RTO and RPO are achievable for specific systems	That the business side copes with the outage
Full interruption test	Production is actually switched off or cut over to the recovery site	High, with real customer risk	End-to-end recovery under real conditions	Rarely justified for SMBs

In our experience, a small SaaS company rarely needs a full interruption test. An isolated failover test plus a tabletop for the human side covers most of what customers and auditors ask about. If you are unsure where continuity ends and recovery begins, see business continuity vs disaster recovery.

What do HIPAA, SOC 2 and ISO standards say about testing?

Every major framework expects periodic testing and revision, but they differ in how specific they are.

Framework	What it says	Practical reading
HIPAA Security Rule	45 CFR 164.308(a)(7)(ii)(D), testing and revision procedures, is an addressable specification: "Implement procedures for periodic testing and revision of contingency plans." (eCFR)	Addressable does not mean optional. You implement it, or document why an alternative is reasonable and appropriate.
SOC 2 (availability)	Criterion A1.3: "The entity tests recovery plan procedures supporting system recovery to meet its objectives." (AICPA Trust Services Criteria)	Applies when availability is in scope of your SOC 2 report. Expect your auditor to sample test records.
ISO/IEC 27001:2022	Annex A includes 5.29 (information security during disruption) and 5.30 (ICT readiness for business continuity). (ISO/IEC 27001:2022)	Certification auditors generally look for evidence that continuity and ICT recovery arrangements are verified, not just documented.
ISO 22301:2019	Clause 8.5 sets out an exercise programme: exercises at planned intervals, consistent with business continuity objectives, with post-exercise reporting and improvement. (ISO 22301:2019, summary by Schellman)	The most detailed of the four. ISO lists the 2019 edition as under revision, so check for a newer edition before your next certification cycle.
NIST guidance	SP 800-84 covers designing and running test, training and exercise events. SP 800-34 Rev. 1 is NIST's contingency planning guide.	Written for federal systems, but freely usable as a method by any organization.

For a deeper comparison of continuity controls across the two ISO standards, see ISO 22301 vs ISO 27001 continuity controls.

How often should you test a business continuity plan?

At least once a year for the plan as a whole, with critical systems tested more often, and an extra exercise after any major change.

No framework above sets a universal frequency, so tie the cadence to your risk and recovery objectives. Here is a sample annual calendar that, in our experience, works for a 20–150 person SaaS company:

Quarter	Exercise	Owner	Output
Q1	Plan review: contacts, vendor list, RTO/RPO, runbooks	Compliance lead	Updated plan, version history
Q1	Backup restore test for the production database	Engineering lead	Restore log with start/end times vs RPO
Q2	Tabletop exercise: cloud region outage	Head of engineering + facilitator	After-action report
Q3	Failover test of a critical service to a secondary region or environment	Platform/SRE	Test record vs RTO, issues logged
Q3	Call tree and status page communication drill	Operations / support	Response times, contact gaps
Q4	Tabletop exercise: ransomware or key vendor failure	Leadership team + facilitator	After-action report, plan updates
Q4	Management review of all findings and open actions	Executive sponsor	Signed-off review, next year's calendar

Adjust it to your audit window. For a SOC 2 Type 2 or an ISO 27001 surveillance audit, make sure at least one documented test falls inside the period being reviewed.

How do you run a BCP tabletop exercise?

Pick one realistic scenario, gather the people who would actually respond, walk through it in timed injects and write down every gap.

NIST SP 800-84 organizes exercises into four phases: design, development, conduct and evaluation. Here is that approach as a practical checklist:

1. Set objectives. Two or three, such as "confirm who declares a disaster" or "validate customer notification within our SLA."
2. Choose the scenario. Base it on your risk assessment and business impact analysis, not on the most dramatic headline.
3. Invite the right people. Decision makers, the engineers who own recovery, support, legal or privacy, and a note taker. Keep it to roughly 6–12 people.
4. Write injects. Three to five timed updates that change the situation, for example "T+2 hours: the vendor confirms no ETA."
5. Facilitate, do not lecture. Ask "what do you do now, and where is that written down?" Let gaps surface.
6. Capture observations live. Decisions, delays, missing contacts, unclear ownership and assumptions nobody could confirm.
7. Hot wash. Spend the last 20 minutes on what worked and what did not, while it is fresh.
8. Write the after-action report within a week and assign every finding an owner and due date.
9. Update the plan and log the change.

You do not have to build scenarios from scratch. CISA Tabletop Exercise Packages (CTEPs) are ready-made packages for organizations to run their own exercises, covering cyber scenarios such as ransomware and sector-specific ones including healthcare. Per CISA's CTEP fact sheet, packages include a situation manual, facilitator and evaluator handbook, and an after-action report/improvement plan template. For leadership-level framing, see our note on the tabletop CISO.

Example tabletop scenario for a HealthTech SaaS

A useful HealthTech scenario combines a technical outage with a patient-data question, so both recovery and compliance decisions get tested.

Scenario: ransomware reaches the EHR integration service.

Time	Inject	Questions for the team
T+0	Monday 08:10. Alerts show files on the integration server that syncs with customer EHRs are being encrypted. Clinics report missing appointment data.	Who is paged? Who has authority to isolate the service?
T+1 hour	The integration is isolated. Backups exist, but the last verified restore of this service was eight months ago.	What is the real RPO? Do we trust the backup? Who confirms it is clean?
T+3 hours	Three hospital customers ask whether patient data was accessed. Sales has already replied to one.	Who owns customer communication? Is there a holding statement? Do we need to start a HIPAA breach risk assessment?
T+6 hours	The cloud provider's support case is unresolved. A key engineer is on leave and unreachable.	Who else can restore? Is the runbook usable by someone who did not write it?
T+24 hours	Service is restored in a clean environment, but four hours of data is missing.	How do clinics reconcile data? What goes in the after-action report?

An alternative scenario is a full cloud region outage affecting your primary database. It tests multi-region failover, status page updates and contractual SLA commitments without the breach notification layer.

What evidence do auditors expect from a BCP test?

Auditors expect a dated, reviewable record showing what was tested, what went wrong and what you changed as a result.

NIST SP 800-84 recommends that after-action reports include background (purpose, objectives, participants, scenario), observations, recommendations and participant feedback. In practice, these are the fields to capture:

After-action report field	What to record
Exercise name, type and date	Such as "Q2 tabletop: cloud region outage, 12 May"
Scope and objectives	Systems, processes and the 2–3 objectives tested
Participants and roles	Names, roles, facilitator, note taker
Scenario summary	Narrative and injects used
Results vs targets	Actual recovery time and data loss vs RTO and RPO
Observations	What worked, what failed, where the plan was unclear
Findings and actions	Each gap with an owner, priority and due date
Plan changes	Sections updated, new version number
Sign-off	Reviewer or executive approval with date

Track every action to closure. Auditors often notice when last year's findings are still open.

When should you update the plan?

Update the plan after every exercise and real incident, and whenever a change makes any part of it inaccurate.

Common triggers:

• Findings from a test, exercise or real incident
• New or retired critical systems, regions or architectures
• A new critical vendor, or a change in a vendor's SLA or support model
• Changes to RTO or RPO after a new business impact analysis
• Key people joining, leaving or changing roles (owners, call tree, backups)
• New customer contracts with stricter availability or notification terms
• New regulatory obligations or expansion into new markets
• The scheduled annual review, even if nothing else has changed

Record each revision with a date, author, summary and approver so the change history itself becomes evidence.

How SecureSlate helps

SecureSlate keeps continuity testing connected to the rest of your compliance program:

• Multi-framework control mapping: one continuity testing control can map to HIPAA, SOC 2, ISO 27001 and other built-in frameworks, so a single exercise supports several requirements. ISO 22301 can be set up as a custom framework.
• Audit management: store after-action reports, restore logs and plan versions as evidence against the right controls for your auditor.
• Risk management: turn exercise findings into tracked risks and actions with owners and due dates.
• Agentless read-only cloud integrations: monitor backup and infrastructure configuration in your cloud accounts between exercises.
• Vendor risk management: keep critical vendor information and reviews current, which often feeds plan updates.

Start your free SecureSlate trial

FAQ

What is the difference between a BCP test and a BCP exercise?

People use the terms loosely. A test usually checks whether a specific component works, such as restoring a backup within the RPO. An exercise, such as a tabletop, rehearses how people make decisions and coordinate. A good program uses both.

Is a tabletop exercise enough for SOC 2 or HIPAA?

It depends on your scope and risks. A tabletop shows people understand the plan, but it does not prove systems can be recovered. SOC 2 A1.3 refers to testing recovery plan procedures, so most teams pair tabletops with documented restore or failover tests.

Who should facilitate a BCP tabletop exercise?

Someone who knows the plan but is not a key responder in the scenario, such as a compliance lead, an engineering manager from another team, or an external facilitator. Their job is to keep time, deliver injects and push for specifics.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.