DORA: Will your recovery plan work when several systems fail?

An application can restart while the business service remains unavailable. For financial entities, effective recovery testing must examine dependencies across systems, data, identities and third-party providers.1

Restarting servers is not the same as restoring a service

A bank may have daily backups, redundant infrastructure and a documented recovery plan. Yet payments may remain unavailable after a major incident. The application is running, but identity services are down; the database has been restored, but a provider connection is unavailable; or recovered data cannot safely support new transactions.

It is important to distinguish restoring individual technical components, restoring their dependencies, and demonstrating that the business function works again.

What DORA requires

Regulation (EU) 2022/2554, applicable since 17 January 2025, addresses ICT business continuity, response and recovery arrangements, backups and digital operational resilience testing. Articles 11 and 12 are especially relevant to continuity and recovery, while Article 24 concerns resilience testing programmes.1

Commission Delegated Regulation (EU) 2024/1774 further specifies ICT risk management policies and procedures, including relevant scenarios, third-party dependencies and testing transitions to backup or redundant capacity.2

The rules do not prescribe one identical recovery exercise for every organisation. Applicable obligations, criticality and risk must shape the approach.

Start with the critical function

Consider a payment service. Its operation may depend on an application, transaction database, identity provider, network controls, infrastructure services and external ICT providers. A shared dependency can create a common point of failure across several business functions.

Mapping those relationships helps teams establish a sensible recovery sequence. Bringing an application back online before the identity service it relies on does not restore access for its users.

Scenario: the central directory is compromised

Imagine a bank whose central directory has been compromised while its payment servers and databases remain operational. Staff can no longer access the tools needed to process payments.

A recovery exercise should ask whether emergency administrator access is independent, whether the backup environment relies on the same directory, whether teams can retrieve recovery procedures under degraded conditions, whether control transactions succeed after restoration, and whether affected providers can assist within the expected timeframe.

This is a fictional scenario. It illustrates why successful server restarts are not sufficient evidence of business recovery.

Five checks during the exercise

1. Define the business outcome: which operation must work again, and for whom?
2. Identify dependencies: which internal and external components are essential?
3. Test recovery order: which steps must precede others?
4. Check integrity: are recovered data and transactions consistent?
5. Record gaps: actual timings, obstacles, owners and corrective actions.

A controlled business transaction provides evidence that a technical availability indicator cannot provide on its own.

Three useful measures—not regulatory thresholds

Actual time to restore the business function, integrity of recovered data and coverage of verified dependencies can help evaluate an exercise. These are practical measurements, not an official DORA compliance scorecard.

Results should be assessed against the organisation's recovery objectives, business impact analysis and applicable requirements.

The value of end-to-end recovery testing

A recovery-oriented dependency map goes beyond an asset list. It connects business functions to the systems and providers that support them and highlights potential common failures. It must also be kept current: an omitted dependency can undermine the test scenario.

The key question is not only whether each system can restart, but whether the critical business function can demonstrably resume.