How banks approach DORA testing

DORA testing for banks is the planned assessment of whether a bank’s information and communication technology (ICT) can withstand disruption and support recovery, as required by the Digital Operational Resilience Act (DORA). Banks build a risk-based testing programme around critical or important functions, the systems and providers that support them, and the impact a failure could have on customers, markets and the bank’s operations.

How banks scope DORA testing

Start by mapping critical or important functions to the people, processes, data, applications, infrastructure and ICT third-party providers they depend on. A payment service, for example, may rely on a channel, an API gateway, a payment engine, sanctions screening, a ledger, a cloud-hosted component and an external settlement connection. Testing only the customer-facing application would miss failures elsewhere in the service chain.

Use the bank’s risk assessments, business impact analysis and continuity arrangements to select scenarios and define expected outcomes. Those outcomes should reflect the bank’s approved recovery objectives, impact tolerances and legal or contractual obligations. DORA does not set one recovery time or pass score for every bank and service.

DORA requires financial entities other than microenterprises to carry out appropriate tests at least annually on ICT systems and applications supporting critical or important functions. The wider programme should be proportionate to the bank’s size, risk profile and operational complexity. A test calendar should therefore explain what is in scope, why each test is suitable, and how gaps in coverage will be addressed.

Build a programme that tests recovery as well as controls

Choose methods that fit the risk and the question being tested. A programme can include vulnerability assessments, network security testing, source-code reviews where feasible, performance and compatibility testing, scenario-based exercises, end-to-end tests and penetration testing. Tabletop exercises can check whether teams understand their roles and escalation routes; technical tests are needed to verify system behaviour and recovery.

Include dependencies that can affect the end-to-end service, such as identity services, network links, data replication, backup processes and third-party platforms. Agree test access, responsibilities, notification routes and safeguards with providers. Supplier reports may inform the bank’s assessment, but the bank remains responsible for its own DORA obligations and should assess whether external evidence covers its services, risks and recovery requirements.

Control the test environment and data carefully. Production testing can expose customers or services to risk, so define authorisation, safety limits, monitoring and abort conditions before execution. Use representative, protected test data where possible. Record environment and configuration differences: a successful recovery in a test environment may not demonstrate that the production service can recover if the environments have drifted.

A payment recovery test in practice

Suppose a bank tests the loss of the primary payment-processing environment. The team switches processing to the recovery environment, submits controlled payment instructions, checks screening and ledger updates, and verifies that queued transactions resume in the correct order. It then checks acknowledgements, customer-visible status, settlement files and reconciliation totals.

The test passes only if agreed criteria are met, such as restoring the service within its approved recovery objective and preserving transaction integrity. A service that resumes quickly but duplicates, loses or misorders payments has failed the business outcome. Record timestamps, system versions, configuration, test data, observed errors and decisions made during recovery. If a dependency prevents recovery, log the finding against the affected service and assign an owner and remediation date.

Findings, retests and threat-led penetration testing

Assess results against the criteria set before the test. Classify findings by their effect on the supported function, identify the underlying cause, and track remediation through to retest. A closed ticket is not evidence that resilience improved: the retest should exercise the failed behaviour and confirm that recovery works under the relevant conditions. Keep records of scope, approvals, methods, results, findings and follow-up so the bank can explain its programme and decisions to supervisors.

Threat-led penetration testing (TLPT) is a distinct, advanced form of testing under DORA. Competent authorities identify the financial entities required to perform it, taking account of factors such as systemic impact and ICT risk. Identified entities carry it out at least every three years. TLPT uses threat intelligence to test realistic attack paths against live production systems under controlled conditions. It does not replace the bank’s broader resilience testing programme, and its production risks require careful governance and coordination.