Digital operational resilience testing in banking is the planned assessment of whether a bank can withstand, respond to and recover from disruptions to the technology and services it depends on. It tests the people, processes, systems and external providers that support important banking activities, and checks whether disruption stays within defined business and customer impact limits.
What does the testing cover?
The scope starts with services whose disruption could affect customers, financial stability or the bank’s ability to meet its obligations. A bank maps each service to its supporting applications, infrastructure, data, operational teams and third-party providers. This dependency map helps teams design tests that reflect how the service works in practice.
Testing can include recovery exercises, failover tests, scenario-based exercises, vulnerability assessments and penetration testing. Under the European Union’s Digital Operational Resilience Act (DORA), financial entities must maintain a digital operational resilience testing programme. The required testing approach depends on the entity and the applicable requirements. Threat-led penetration testing has specific scope and applicability conditions; it is not a substitute for the wider programme.
The aim is to find weaknesses that could prevent a service from continuing or recovering. Examples include a failover that loses transactions, an unavailable identity provider that blocks customer access, or an outsourced payment service that returns inconsistent statuses after reconnection.
How banks assess resilience
A test should begin with an agreed scenario, boundaries and success criteria. These include the service being tested, systems and suppliers in scope, permitted test data, expected business behaviour, recovery objectives and the people authorised to act. Teams also need a rollback or stop procedure where testing could affect live services.
Measures should reflect the service’s real obligations. A recovery time objective (RTO) sets a target for restoring a service. A recovery point objective (RPO) sets a target for the amount of data loss that can be accepted, expressed as a period of time. These technical measures should be considered alongside customer impact, transaction integrity, backlogs and any operational limits set for the service.
A successful infrastructure failover alone does not prove resilience. Teams should verify that customers can complete or safely retry transactions, that balances and payment states remain consistent, and that queued work can be processed after recovery. Results also depend on realistic test data, representative system configuration and current dependency information. Environment drift can make a test pass in a test environment while a live configuration fails under the same scenario.
Worked example: payment service outage
Suppose a bank tests the loss of a payment-processing dependency. The scenario states which component becomes unavailable, how long it remains unavailable and which customer channels continue operating. Testers submit a payment, trigger the outage, then restore the dependency and allow queued requests to resume.
The team checks whether the customer receives an accurate status, whether retries avoid duplicate payment, and whether the ledger and payment records reconcile after recovery. It also checks alerts, staff escalation and the time taken to return the service to its agreed operating level. A test fails if the bank restores the application but leaves transactions with ambiguous status or an unreconciled backlog.
How it differs from disaster recovery testing
Disaster recovery testing focuses on restoring technology and data after an outage, often through backup restoration or site failover. Digital operational resilience testing has a broader service view: it can include recovery, response decisions, business workarounds, suppliers and customer outcomes. Disaster recovery tests can form part of a resilience programme, while resilience scenarios can expose weaknesses beyond the recovery infrastructure.
Testing also has operational risk. A production exercise may affect customers or expose sensitive data, while a non-production environment may not represent real dependencies or capacity. Banks should choose the environment and test depth according to the scenario, risk and applicable requirements, then record limitations that affect confidence in the result.
Verifying the outcome
Evidence should connect the scenario and its expected outcomes to observed results. Capture relevant system events, transaction identifiers, recovery timings, decisions, defects and reconciliation results. Record assumptions and any deviations from the plan. Follow-up actions need owners and retesting criteria, so teams can confirm that fixes address the underlying weakness rather than only the observed symptom.
Frequently asked questions
Who is responsible for digital operational resilience testing in a bank?
Responsibility is shared across technology, operational resilience, business service owners, risk and relevant third-party managers. The bank should assign clear ownership for test approval, execution, evidence review and remediation.
Does every bank have to conduct threat-led penetration testing?
No. DORA’s threat-led penetration testing requirements apply to entities identified under the applicable criteria and supervisory process. A bank should confirm its obligations with its compliance and regulatory teams.
Can a bank run resilience tests in production?
Some tests may use production systems, but the decision depends on the scenario, risk controls and applicable requirements. The bank should assess customer and data impact, obtain approvals, define stop conditions and prepare recovery procedures before execution.