Operational Resilience After DORA: What Banks Need to Change

Featured answer: After DORA, banks should move from compliance documentation to demonstrable resilience. That means mapping critical services end to end, setting impact tolerances, linking incident severity to decision rights, testing recovery under plausible disruption, measuring third-party concentration and giving boards evidence that important functions can remain within tolerance.

DORA has applied since 17 January 2025, so 2026 is not a preparation year. It is the first full year in which banks must show that registers, policies, contracts and testing programmes operate as one control system. The regulation creates uniform EU rules across ICT risk management, incident reporting, digital operational-resilience testing and third-party risk. The practical challenge is integration.

Key takeaways

• Map services from customer outcome to applications, infrastructure, data, people and providers.
• Set disruption tolerances separately from conventional risk limits.
• Test recovery capability, not merely whether a plan was followed.
• Connect incident classification to regulatory reporting and executive decisions.
• Measure provider concentration at service, group and sector-relevant levels.

Start from critical services, not assets

Asset inventories are necessary but do not explain how disruption harms customers or the financial system. A service map should begin with a critical or important business function and trace the applications, interfaces, data stores, identities, infrastructure, facilities, staff and third parties needed to deliver it. The map should expose common dependencies that are invisible when systems are reviewed separately.

For a payments service, for example, authentication, sanctions screening, fraud controls, messaging, settlement, customer notification and reconciliation may rely on different technology stacks. Resilience fails if the bank restores the payment engine but cannot authenticate users or reconcile balances.

Impact tolerance and recovery objectives

Risk appetite usually describes acceptable exposure or loss; operational-resilience tolerance describes how much disruption can be endured before unacceptable harm occurs. Banks should define measurable dimensions such as maximum outage, maximum data loss, transaction backlog and affected customers. Recovery time objectives are technical targets and should support—not replace—the business impact tolerance.

A useful control metric is the resilience margin: M = T - R, where T is the disruption tolerance and R is demonstrated recovery time under test. A positive margin indicates headroom. Because recovery performance is uncertain, management should examine a distribution rather than a single best-case result.

Incident management and reporting

Incident processes should distinguish detection, classification, containment, restoration, recovery and improvement. Severity thresholds need operational data that can be assembled quickly: affected services, duration, geographic reach, customers, transactions, data loss and economic impact. The FSB's 2025 Format for Incident Reporting Exchange is not EU law, but it provides a useful global reference for consistent information exchange.

A strong process separates regulatory notification from technical investigation. Early reports will contain uncertainty; governance should permit timely notification while facts are refined, with version control and a record of judgement.

Resilience testing as evidence

Scenario tests should combine technology failure with realistic complications: loss of privileged access, corrupted backups, unavailable staff, a provider outage, misinformation and simultaneous customer demand. Tabletop exercises can test decisions and communication, but they cannot demonstrate system recovery. Banks need a portfolio of vulnerability assessments, scenario tests, failover exercises and, where applicable, threat-led penetration testing.

Success criteria should include service outcomes. A system restart is not a successful recovery if transactions are duplicated, balances cannot be reconciled or customers remain unable to use the service.

Third-party dependencies and exit

DORA places ICT third-party risk within the financial entity's overall framework and introduces oversight of critical ICT third-party providers by the European Supervisory Authorities. In 2025 the ESAs published the first list of designated critical providers. That designation does not remove the bank's own responsibility.

Exit planning should distinguish substitutability from portability. Another provider may exist, but data, configurations, interfaces and staff capability may prevent timely migration. Banks should estimate time to exit, transition capacity, data-extraction time, parallel-run requirements and concentration created by shared subcontractors.

Hypothetical practical example

Assume a bank sets a four-hour impact tolerance for retail payments. Its disaster-recovery test restores the core platform in 110 minutes, but authentication takes another 70 minutes and reconciliation 100 minutes. The true service recovery is therefore 280 minutes—outside tolerance—even though each technical team reports that its own target was met. The lesson is to measure the customer service chain, not isolated components.

Board oversight

Boards do not need a catalogue of vulnerabilities. They need the services at risk, the tested margin to tolerance, unresolved single points of failure, material provider concentration, incident trends and management decisions. Reporting should identify uncertainty and distinguish planned capability from demonstrated capability.

What CROs should do now

1. Reconcile business-function maps with ICT and third-party registers.
2. Approve explicit impact tolerances and evidence how they were calibrated.
3. Test full service recovery, including data integrity and backlog clearance.
4. Integrate regulatory reporting into incident command without slowing response.
5. Quantify provider concentration and practical exit constraints.
6. Track remediation from testing to closure with accountable owners.
7. Give boards a service-level resilience view rather than a technology inventory.

Conclusion

DORA's value will not be measured by the number of completed templates. It will be measured during disruption, when a bank must understand dependencies, make decisions with incomplete information and restore a critical service without creating new harm. The post-DORA task is to convert legal compliance into tested operational capability.

References

• European Union, Regulation (EU) 2022/2554 (DORA), 14 December 2022
• European Supervisory Authorities, designation of critical ICT third-party providers under DORA, 2025
• Financial Stability Board, Format for Incident Reporting Exchange: Final Report, 15 April 2025