DORA made operational resilience testing a legal duty for financial entities across the EU, not an internal best practice. It expects a real testing programme and business-continuity arrangements that actually work. Plenty of firms are handling that with a documented plan and a checklist. The document proves you have a plan. It proves nothing about whether the plan works, or whether the people who’d have to run it can.
What DORA actually requires
DORA isn’t a paperwork exercise dressed up as resilience. Article 11 requires ICT business continuity policies and response and recovery plans that are maintained and tested. Articles 24 to 26 require a programme of digital operational resilience testing of your ICT systems, and for the larger entities, advanced threat-led penetration testing. The word doing all the work there is testing. DORA doesn’t ask you to have a continuity plan. It asks you to prove it holds up.
What DORA asks, what a tabletop delivers
Why firms default to the checklist
The checklist is the obvious answer, and it’s obvious for good reasons. It’s auditable, it’s cheap, and it produces the artefact a supervisor asks for. If the goal were to show that a plan exists on paper, the checklist would be enough. That’s just not what DORA is testing for.
A plan you have never run is a hypothesis
A continuity plan that’s never been exercised is a set of assumptions about how people will behave in the worst hour of their year. Who makes the call to fail over. Whether the runbook still matches the systems you actually have now. Whether the business owner and the technical team even agree on what “recovered” means. You don’t find those gaps by reviewing the document. You find them by running it, under time pressure, before a real disruption finds them for you.
What resilience testing looks like when it works
It looks like the team running the plan, not reading it. You take your actual continuity plan, put it under a realistic disruption with a clock, and watch where it breaks. That’s what FAILOVER does. It’s a business-continuity exercise run against your real plan, not a generic case study, so the gaps you find are the gaps you actually have. It’s the difference between a plan you filed and a plan you trust.
DORA will keep raising the bar on what counts as testing, and a checklist was never going to tell you whether your organisation can actually recover. Test the plan the way you’d test anything you depend on. Run it.
DORA is one of several EU regimes now demanding tested capability rather than filed documents. NIS2 makes the same move at board level, and the game-based approach across both sits in training for EU cyber regulation.
Frequently asked questions
Does DORA require operational resilience testing?
Yes. DORA Articles 24 to 26 require a programme of digital operational resilience testing of ICT systems, and Article 11 requires ICT business continuity plans that are maintained and tested. Larger entities also face threat-led penetration testing.
Is a documented continuity plan enough for DORA?
No. DORA is explicit that plans must be tested, not just maintained. A documented plan satisfies the paperwork but does not demonstrate the resilience DORA is asking you to prove.
What counts as a DORA resilience test?
Exercising your actual ICT continuity and response plans against a realistic disruption, so you find where they break before an incident does. A facilitated business-continuity exercise against your real plan, such as FAILOVER, is one way to do it.
Who does DORA apply to?
Financial entities in the EU and their critical ICT third-party providers. If you fall under DORA, the operational resilience testing obligation applies to you.
Want to put this in front of your team?
I run these as games your board and your responders actually take part in, not another slideshow. Tell me where your team is and what they need to practise, and we will set it up.
