FAILOVER
Test your plan before the plan tests you.
The only BCM exercise run against your actual plan, not a case study.
Your BCP has never been tested by the people who have to use it
Your BCP was written by people who had not been in a crisis with it. It describes what should happen. It does not describe what will happen when the backup contact is unreachable, the supplier system is down, and the recovery sequence assumes infrastructure that was deprecated last quarter.
Most BCM exercises test a generic scenario. FAILOVER tests your actual plan, the one your crisis team would have to invoke tomorrow. That distinction matters. Generic scenarios produce generic learnings. Running against your real BCP surfaces the specific gaps in your specific situation.
Decision authority is the gap that appears most often. Who can invoke the BCP? Who can deviate from it when the situation does not match the written procedure? These questions should have clear answers before a real incident forces them.
FAILOVER puts your crisis team in the scenario, with your plan, under time pressure, and makes the gaps visible before they cost you.
THE SIMULATION
What FAILOVER actually is
FAILOVER is a structured BCM simulation that runs against your actual BCP. Participants play their real crisis team roles, not generic ones. The scenario introduces plausible failure events drawn from your sector and your organisation’s dependencies. Decisions made in the simulation expose gaps in authority, sequencing, communication, and supplier dependencies that exist in your real plan.
Sessions run 90 to 180 minutes for a standard crisis team of five to twelve people. Longer formats are available for organisations that need to run multiple scenarios or test cross-site coordination. The simulation works with your existing BCP documentation, no preparation or rewriting required before the session.
FAILOVER does not score your plan. It shows your team what works and what does not under pressure, in a controlled environment where the cost of failure is a useful debrief rather than an actual incident.
FAILURE MODES
What FAILOVER tests
Decision authority
Supplier dependencies
Communication chain integrity
Recovery sequencing
Resource availability
Plan invocability
LEARNING OUTCOMES
What your team walks away with
Where the plan breaks down
Resolved decision authority
Dependency gap list
Tested communication chain
Revised recovery sequence
A team that has practised
HOW IT WORKS
How a FAILOVER session runs
Step 1, Plan review (20 min): The facilitator reviews your BCP with the crisis team before the simulation begins. Known gaps or questions are noted but not resolved. They are surfaced in the simulation instead.
Step 2, Scenario briefing (10 min): The failure event is introduced. The team is told what they know at T+0. The clock starts.
Step 3, First response (30–40 min): The team invokes or considers invoking the BCP. Who has authority? What is the trigger? The simulation immediately surfaces whether those answers are clear.
Step 4, Escalation phase (20–40 min): Additional injects arrive: supplier unavailability, communication failures, recovery sequence mismatches. The team adapts, or does not.
Step 5, Structured debrief (30 min): Gaps identified in the simulation are mapped back to specific sections of your actual BCP. The team leaves with a prioritised gap list and recommended BCP amendments.
Who this is for
FAILOVER works for crisis management teams, business continuity managers, and risk teams who need to validate whether their BCP actually works, not just whether it exists. Typical participants include the people who would be in the room during a real incident: department heads with invocation authority, IT leads responsible for system recovery, communications leads managing internal and external messaging, and third-party relationship managers who need to know which suppliers matter most. It runs with the actual people who would use your actual plan.
DORA & BCM MAPPING
How FAILOVER maps to DORA and BCM
| Requirement | What it asks | How FAILOVER addresses it |
|---|---|---|
| DORA Article 11, ICT business continuity | Financial entities maintain and test ICT business continuity and response and recovery plans | Runs the exercise against your actual continuity plan, not a generic scenario |
| DORA Articles 24 to 26, resilience testing | Entities run a programme of operational resilience testing of ICT systems | Provides a repeatable, facilitated test of the plan and the people who execute it |
| ISO 22301 and general BCM | Continuity plans are exercised regularly to stay valid | Exercises the plan with the team and surfaces where it breaks before a real incident does |
FAQ
Frequently asked questions
Does FAILOVER help us meet DORA operational resilience testing requirements?
What makes FAILOVER different from a normal tabletop exercise?
Who should take part?
How long does it take?
Do we need a mature BCM plan first?
Is it only for financial services and DORA?
How well does your plan hold up when things go wrong?
FAILOVER runs on-site with your crisis team and your BCP. No prep required beyond sharing the plan ahead of the session.
Explore the full serious games lineup.
