Business Continuity Plan Test Checklist

A business continuity checklist for testing your BCP: pick a realistic scenario, run a tabletop or live test, measure recovery times and fix what broke.

Typical schedule annually
The checklist 4 sections, 19 items
Variables {{scenario}}

Use this template Free, no credit card. Imports the checklist into your Runbook organization.

Use this checklist to test your business continuity plan at least once a year, and after major changes such as a new hosting provider or a new office. A plan that has never been tested usually fails on small things: an expired password for the backup account, a phone list with old numbers, or a restore that takes far longer than anyone assumed.

Who owns it

The owner of the continuity plan, often an operations or IT lead, plans the test and facilitates it. A small group of people who would actually respond in a real event takes part. Someone who is not running the scenario takes notes and records times. Adapt this to your jurisdiction and contracts; it is a practical checklist, not legal advice.

Common pitfalls

Testing the scenario you are ready for. Choose scenarios that hurt, such as losing your main cloud account or a key person being unavailable.
Only talking. A tabletop exercise is useful, but also restore real data from backup at least once a year and time it.
Assuming the usual tools work. If your plan lives in the same workspace that is down, nobody can read it.
No follow-up. The test is only worth it if the gaps become tickets with owners and dates.

Schedule this checklist yearly in Runbook. The completed runs become evidence for SOC 2 or ISO 27001 auditors.

The checklist: Continuity test: {{scenario}}

Plan the test

Choose the scenario {{scenario}} and the services and teams it affects
Choose the test type: tabletop discussion, partial technical test or full failover
Write down the recovery time and recovery point objectives you will test against
Invite the people who would respond in a real event, including a deputy for each key role
Appoint a facilitator and a separate note-taker who records times
Inform anyone affected by a live test and agree a stop condition optional

Check the basics before the test

Confirm the continuity plan is readable outside your normal systems
Keep an offline or separately hosted copy, for example a printed copy or a file in a different cloud account.
Confirm the emergency contact list is current, including vendors and support numbers
Confirm emergency access to backups and admin accounts works, including MFA devices

Run the scenario

Walk through detection: how would you notice {{scenario}}, and who is told first
Walk through decisions: who declares the incident and who communicates with customers
Restore a real system or data set from backup and record the time it took
Test the alternative way of working, such as manual processes or a backup site optional
Send a test message through the emergency communication channel

Evaluate

Compare actual recovery times with the objectives
List what went well and what failed or was unclear
Record gaps as tickets with an owner and a due date
Update the continuity plan, contact list and runbooks with what you learned
File the test report and share a summary with management

Checklist as Markdown

# Continuity test: {{scenario}}

## Plan the test
- [ ] Choose the scenario {{scenario}} and the services and teams it affects
- [ ] Choose the test type: tabletop discussion, partial technical test or full failover
- [ ] Write down the recovery time and recovery point objectives you will test against
- [ ] Invite the people who would respond in a real event, including a deputy for each key role
- [ ] Appoint a facilitator and a separate note-taker who records times
- [ ] Inform anyone affected by a live test and agree a stop condition (optional)

## Check the basics before the test
- [ ] Confirm the continuity plan is readable outside your normal systems
  Keep an offline or separately hosted copy, for example a printed copy or a file in a different cloud account.
- [ ] Confirm the emergency contact list is current, including vendors and support numbers
- [ ] Confirm emergency access to backups and admin accounts works, including MFA devices

## Run the scenario
- [ ] Walk through detection: how would you notice {{scenario}}, and who is told first
- [ ] Walk through decisions: who declares the incident and who communicates with customers
- [ ] Restore a real system or data set from backup and record the time it took
- [ ] Test the alternative way of working, such as manual processes or a backup site (optional)
- [ ] Send a test message through the emergency communication channel

## Evaluate
- [ ] Compare actual recovery times with the objectives
- [ ] List what went well and what failed or was unclear
- [ ] Record gaps as tickets with an owner and a due date
- [ ] Update the continuity plan, contact list and runbooks with what you learned
- [ ] File the test report and share a summary with management

Frequently asked questions

How often should a business continuity plan be tested?

At least once a year is a common baseline, and again after major changes to your systems, suppliers or team. Many organisations alternate between tabletop exercises and technical tests such as a full restore. Your own policy and customer contracts may set a specific interval.

What is the difference between a tabletop exercise and a live test?

A tabletop exercise is a guided discussion where the team walks through a scenario and its decisions without touching systems. A live test actually fails over or restores systems. Tabletops are cheap and good for finding gaps in roles and communication, while live tests prove that the technical recovery works.

What is the difference between business continuity and disaster recovery?

Disaster recovery focuses on restoring IT systems and data. Business continuity is wider and covers how the business keeps operating, including people, communication, suppliers and manual workarounds. A good test checks both.

Updated 2026-11-04