DORA scenario-based testing is the use of plausible disruption scenarios to assess whether a financial entity can maintain or recover its important services when information and communication technology (ICT) fails. Under the Digital Operational Resilience Act (DORA), it can form part of an entity's digital operational resilience testing programme. The term describes a testing approach, not a separate DORA certification or a guarantee of compliance.
What DORA scenario-based testing covers
A scenario describes a disruption, its effects and the conditions under which teams and systems must respond. Examples include a cloud service outage, a cyber attack, a data centre failure, corrupted data or the loss of a critical supplier. The test examines the service and its dependencies, including people, processes, applications, infrastructure and third parties.
The exercise should have defined objectives and observable outcomes. These might include whether staff invoke the correct continuity plan, whether a payment service resumes within its approved recovery objective, and whether transactions are complete and reconciled after recovery. Outcomes should be tied to the entity's documented risks, business continuity arrangements and critical or important functions.
DORA requires financial entities to maintain and test ICT business continuity, response and recovery plans. Scenario exercises can help provide that testing, alongside other methods in the broader resilience testing programme. A scenario exercise alone does not establish compliance with every DORA requirement. The entity needs to select tests that fit its risks and meet the applicable requirements for its activities and classification.
How to design and run a scenario
Start by selecting a service and mapping its supporting systems, suppliers, data flows and recovery arrangements. Define the disruption, assumptions, scope, safety limits and expected results before execution. Agree who can make decisions during the exercise, how test evidence will be recorded, and how the service will be returned to its normal state.
The format can range from a tabletop exercise, where participants work through decisions and communications, to a technical failover or end-to-end test. A tabletop can assess escalation and decision-making. Technical execution is needed to observe system behaviour and recovery performance. The test method should match the question being assessed.
Before testing, confirm that required test data, environments, access, supplier participation and monitoring are available. Check that the test will not cause uncontrolled customer impact or interfere with live processing. If the exercise relies on simulated responses, document which behaviours were simulated and which were observed directly.
Practical example: payment service provider outage
A bank tests the loss of a provider used by its payment hub. The scenario starts with provider connectivity failing during a busy processing period. The test team injects events such as delayed status updates and a growing payment queue, then observes the bank's response and recovery process.
Expected results could include escalation to the right incident team, activation of the approved fallback route, safe handling of retries, and recovery of queued payments without loss or duplication. After service restoration, testers check payment statuses against the ledger and reconcile the resulting transactions. They record timestamps, system logs, decisions and any exceptions against the agreed recovery objectives.
A successful technical failover does not by itself prove the whole service is resilient. The test may omit a dependent service, use unrealistic data volumes or leave reconciliation and customer communications untested. Record these boundaries and treat gaps as findings with owners, actions and retest criteria.
Interpreting results
Assess results against the objectives set before the exercise. Separate observed evidence from assumptions, and distinguish a control failure from a test limitation or environment issue. For example, a recovery objective miss caused by a test environment with different configuration from production may indicate environment drift; it does not show how production would behave without further evidence.
Retain the scenario, scope, participants, dependencies, execution records, results and follow-up actions. Re-test material fixes where needed and update the scenario when systems, suppliers or recovery arrangements change. This gives resilience and testing teams a traceable view of what was tested and what remains exposed.
Frequently asked questions
Does DORA require scenario-based testing every year?
DORA requires financial entities to test their ICT business continuity, response and recovery plans at least annually and after substantive changes. Scenario-based testing can contribute to this testing, but that does not mean every scenario or every test method must be repeated annually.
Does a scenario exercise count as threat-led penetration testing?
No. A general scenario exercise does not automatically meet DORA's requirements for threat-led penetration testing. That is a distinct form of advanced testing with specific scope, methods and eligibility requirements.
Can a tabletop exercise prove that technical recovery works?
No. A tabletop can assess decisions, escalation and communications, while technical recovery needs to be observed through a suitable technical test. Use both methods when the objective includes operational decisions and system recovery.