A DORA risk-based testing programme is an organisation's planned, documented approach to testing information and communication technology (ICT) systems, services and controls according to the risks they pose to digital operational resilience. Under the Digital Operational Resilience Act (DORA), financial entities use it to identify important services and dependencies, select proportionate tests, assess recovery and control effectiveness, and track findings through remediation.
How a DORA risk-based testing programme works
The programme starts with an assessment of ICT risks and the business services they could affect. A team maps critical or important functions to the applications, infrastructure, data flows, internal teams and external providers that support them. It then considers credible failure scenarios, their potential impact and the controls intended to prevent, detect or recover from them.
That assessment informs test selection and priority. A payment service with a concentrated dependency on one processing provider may need outage and recovery scenarios. A customer portal change may call for functional, security and end-to-end checks. The test plan should state the risk being examined, scope, method, preconditions, expected outcomes, owners and evidence to retain.
DORA's digital operational resilience testing requirements cover different forms of testing. Depending on the risks and context, these can include vulnerability assessments, network security assessments, source code reviews where appropriate, scenario-based testing, performance testing, end-to-end testing and penetration testing. The programme should choose methods that produce evidence about the risks in scope, rather than treating a large test count as proof of resilience.
What the programme should show
A useful programme links risks to services, systems, controls, tests and findings. This makes it possible to see which risks have been tested, where coverage is weak and whether an unresolved issue affects a critical service. Test evidence should record the environment and configuration, data used, execution results, deviations, relevant approvals and any limitations that affect interpretation.
Findings need an owner, severity or priority, remediation action and follow-up decision. A test that passes in a lower environment may provide weak assurance if that environment differs from production in configuration, capacity or provider behaviour. The programme should identify such limitations and decide whether further testing or other evidence is needed.
Tests involving external ICT providers require coordination. Teams need to confirm scope, access, responsibilities and any constraints that could affect the provider or live services. A test that creates operational risk should have safeguards, monitoring and a clear stop or rollback condition. These controls make the test safer and help ensure that its result reflects the scenario being examined.
Practical example: payment provider outage
Suppose a bank assesses the outage of an external payment processor as a material risk to a critical payment service. The test plan defines the affected payment flows, provider interface, failover route, test data and conditions for stopping the exercise. The team simulates provider unavailability, checks that eligible payments move to the alternative route or remain safely queued, and verifies that retries do not create duplicate transactions.
The team also checks customer and operational status updates, recovery to the primary route, and reconciliation between payment records and ledger postings. Evidence should show actual outcomes against defined expectations, including any delay, manual intervention or data mismatch. A failed assertion becomes a tracked finding, with retesting after remediation where appropriate.
How it differs from general risk-based testing
Risk-based testing prioritises tests according to product or business risk. A DORA risk-based testing programme applies that principle to digital operational resilience and the regulatory testing duties for financial entities. Its scope includes the ability to withstand, respond to and recover from ICT disruption, which can require service-level scenarios across internal systems and third-party dependencies alongside conventional software tests.
Threat-led penetration testing (TLPT) is a specific, advanced form of testing under DORA for entities identified as subject to that requirement. It does not replace the broader resilience testing programme. The programme should make clear which activities address general testing obligations and which meet any separate TLPT requirements.
Frequently asked questions
Does DORA prescribe one testing method for every financial entity?
No. DORA requires a testing programme that is appropriate to the entity's risks and circumstances, so the methods and scope should reflect the services, systems and dependencies being assessed.
Does every financial entity have to conduct threat-led penetration testing?
No. DORA's threat-led penetration testing requirement applies to financial entities identified as subject to it under the regulation's criteria. It is separate from the wider digital operational resilience testing programme.
How often must systems supporting critical or important functions be tested?
Under DORA, financial entities other than microenterprises must ensure that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions at least annually.