A business continuity exercise is where continuity planning either becomes real or is revealed as filing. Every regime that touches resilience now asks for one, and they agree on two things most organisations never actually test.
You have to exercise the communications, and you have to exercise the switchover. Neither is demonstrated by a plan review.
What a business continuity exercise must cover

DORA Article 11(6)(a) is the most specific text in circulation. Financial entities must test the ICT business continuity plans and the ICT response and recovery plans, for systems supporting all functions, at least yearly — and again in the event of any substantive changes to ICT systems supporting critical or important functions.
Three details in one sentence, and each changes a testing calendar:
- Two plan sets, not one. Continuity plans and response and recovery plans are named separately.
- All functions, not only the critical ones. Criticality raises the bar elsewhere; the yearly test is broader.
- Change is a trigger. A substantive change to systems supporting critical or important functions brings testing forward regardless of when the last one ran.
Two things a business continuity exercise usually skips
Crisis communication. Article 11(6)(b) requires the crisis communication plans to be tested too. This is almost always the weakest part of a real incident — who speaks, to whom, through what channel when the usual one is down — and almost never the part that gets exercised.
The switchover. For entities other than microenterprises, testing plans must include scenarios of cyber-attacks and switchovers between the primary ICT infrastructure and the redundant capacity, backups and redundant facilities.
That is the sentence to take to a steering committee before scoping a business continuity exercise. A documented failover capability that has never been executed is an assumption. Organisations discover during an incident that the secondary environment has drifted, that a dependency was never replicated, or that nobody currently employed has performed the procedure.
Outsourced functions belong in the business continuity exercise
Article 11(4) requires entities to put in place, maintain and periodically test ICT business continuity plans — notably with regard to critical or important functions outsourced or contracted through arrangements with ICT third-party service providers.
A provider’s own continuity testing is not the same as testing your plan for the loss of that provider. The question a business continuity exercise should answer is what you do when the supplier is unavailable, not whether the supplier believes it will be.
That obligation belongs in the contract before it belongs in a test plan, which makes it part of third-party risk management rather than a scheduling problem.
Independent review, and the analysis underneath
Two supporting requirements are easy to overlook.
Article 11(3) makes ICT response and recovery plans subject to independent internal audit reviews for entities other than microenterprises. The plans are reviewed by someone who did not write them.
Article 11(5) requires a business impact analysis of exposures to severe business disruptions, assessing potential impact through quantitative and qualitative criteria, using internal and external data — and requires ICT assets and services to be designed and used in full alignment with the BIA, particularly in ensuring redundancy of all critical components.
That last clause is the one that closes the loop: the BIA is not a document that justifies the plan, it is the specification the architecture is supposed to meet. An exercise that reveals recovery times far outside the BIA has found an architecture problem, not a plan problem.
Where this sits in the wider standards
NIS2 requires business continuity as a risk-management measure — Article 21(2)(c) names business continuity, such as backup management and disaster recovery, and crisis management. Different words, same three components.
ISO 22301:2019 remains the certifiable management system: second edition, 21 pages, maintained by ISO/TC 292. Worth knowing that its record now shows stage 90.92 — International Standard to be revised, so a new edition is coming. As always, that is a reason to document against principles rather than clause numbers, not a reason to delay certification.
Designing a business continuity exercise that finds something
A business continuity exercise that everyone passes has usually tested the wrong thing. A few design choices separate the useful ones:
- Pick a scenario the plan does not already answer. Cyber-attack scenarios are mandated for a reason — they break assumptions that flood and fire scenarios leave intact, particularly around backups.
- Exercise the switchover for real where you safely can, rather than discussing it.
- Withhold something. The primary communications channel, or a key person, is where crisis communication plans are actually tested.
- Measure against the BIA, so the output is a comparison rather than an impression.
- Record what failed. An exercise report with no findings is evidence the exercise was too easy, and a regulator will read it that way.
How the business continuity exercise connects
| Area | Connection |
|---|---|
| Business impact analysis | The specification an exercise measures against, and what Article 11(5) requires the architecture to align with |
| Threat-led penetration testing | The other end of DORA’s testing programme, for the entities their regulator identifies |
| Breach notification | Regulatory clocks run during an incident. Exercising them alongside recovery is the only way to find out whether they are achievable |
| ISO 22301 | The management system that makes exercising a programme rather than an annual event |
Where to start with your business continuity exercise
- Check your frequency against the change trigger, not just the calendar. Substantive change brings the next test forward.
- Add crisis communications to the scope, since it is separately required and rarely exercised.
- Exercise a switchover, including backups and redundant facilities.
- Include supplier unavailability, not just your own systems.
- Compare results to the BIA and treat gaps as architecture findings.
- Get the plans independently reviewed, as Article 11(3) requires.
This guide reflects Regulation (EU) 2022/2554, Directive (EU) 2022/2555 and the ISO 22301 record on iso.org, read at 16 August 2026.
The ISO 22301 Toolkit provides 75+ editable templates covering the business impact analysis, the continuity and recovery plans, the exercise programme and the test reports — and the DORA Toolkit covers the ICT-specific testing programme alongside it.