Why exercises are needed
A business continuity exercise is a practical test of the business continuity plan. Team members, each in their own role, play out a disruption scenario: around a table, in a simulation, in a technical test or in a full-scale exercise. The aim of an exercise is to find what does not work in the plan while fixing it is still cheap.
An exercise checks that people know their roles under the business continuity plan (BCP), that contacts are up to date, that backup resources are available and that recovery time objectives (RTO) can be met. Regular testing is a mandatory requirement of the ISO 22301 standard.
Types of exercises
- Tabletop (desk-based). Team members work through a disruption scenario “around a table”, each in their own role. Cheap and quick, and it exposes most of the gaps in the plan.
- Simulations. An incident staged close to reality: alerting and decision-making in real time.
- Technical tests. Actual recovery of IT systems from backups (part of the DRP).
- Full-scale exercises. A test of the whole chain, from detection to recovery.
How to run an exercise: step by step
- Choose a scenario (for example, ransomware or loss of the office).
- Define the goal and the participants, and appoint an observer.
- Run the exercise and record where the team “stumbles”.
- Gather the lessons: what did not work, which contacts or resources were missing.
- Update the plan and assign owners for the fixes.
Common mistakes
- The scenario is handed to participants in advance, and the exercise turns into a scripted read-through.
- The lessons stay in the minutes and never turn into plan changes with owners and deadlines.
- The same scenario is played every year, so the team practises remembering instead of reacting.
Frequently asked questions
Which type of exercise should you start with?
With tabletop (desk-based) exercises: the team works through a scenario around a table. It is inexpensive and exposes most of the gaps in the plan.
How often should exercises be held?
As a baseline, once every six to twelve months, one scenario at a time; for critical systems, technical recovery tests more often. Regularity is what matters most.
From the requirements of the standard to a working system
The assessment shows the gap between your documents and reality. Then the system is built either by your own team in the programme or by us as a turnkey project.
