DORA Regulations and Business Continuity

For many financial organizations, the critical issue is not whether the DORA regulation and business continuity are linked, but to what extent that link has already been translated into verifiable operational frameworks. When an ICT incident disrupts essential services, it is not the policy document that makes the difference, but the ability to keep processes, decisions, and recovery times within thresholds compatible with regulatory, customer, and market requirements.

DORA does not replace business continuity. However, it makes business continuity more demanding, more measurable, and much more integrated with ICT risk management, the technology supply chain, and incident response capabilities. For this reason, the issue is not limited to compliance, IT, or cybersecurity. It involves governance, operations, control functions, procurement, crisis management, and critical third parties.

DORA Regulations and Business Continuity: The Real Common Ground

EU Regulation 2022/2554 on digital operational resilience requires financial institutions to have a structured framework in place to prevent, withstand, respond to, and recover from ICT incidents.Business continuitycomes into play when digital resilience ceases to be a technical issue and becomes the ability to ensure service continuity.

This step is crucial. A business continuity plan based solely on traditional scenarios—such as office unavailability, local infrastructure failure, or the absence of key personnel—is insufficient if it does not account for the compromise of core platforms, loss of data integrity, unavailability of cloud providers, or prolonged disruption of outsourced services. DORA calls for an approach that integrates business continuity and digital dependencies, with much stricter criteria for severity, impact, and tolerance to disruption.

In practical terms, business continuity becomes one of the mechanisms through which an organization demonstrates its ability to maintain critical functions even in the event of serious ICT incidents. However, to be credible, it must be coordinated with incident response, disaster recovery, crisis communication, and third-party risk management.

What Really Changes for Continuity Programs

The most common mistake is to treat DORA as a new layer of documentation on top of an existing program. This rarely works. Where continuity frameworks are mature, DORA accelerates integration and raises the level of evidence. Where continuity has instead been managed as a periodic compliance task, the regulation quickly exposes gaps in governance and testing.

The first change concerns the scope. It is no longer enough to identify critical processes in general terms. Business services, ICT resources, applications, information flows, decision-making roles, and third-party suppliers must be linked together in a traceable chain of dependencies. If an essential service depends on a single provider or a non-redundant platform, the vulnerability is not merely theoretical. It is an operational risk that must be understood, managed, and, if necessary, mitigated.

The second change concerns the thresholds. RTO and RPO cannot be historical values that are never reevaluated. They must reflect the actual tolerance for service disruption, regulatory and reputational impacts, and the actual recovery capacity. In many organizations, this is precisely where the gap lies: formally approved recovery objectives that are not supported by appropriate architectures, procedures, and roles.

The third change concerns testing. DORA promotes demonstrable resilience. This means exercises that more closely mirror real-world scenarios, verification of external dependencies, escalation simulations, validation of decision-making timelines, and monitoring the effectiveness of crisis communications. A plan that exists but fails to hold up in an exercise does not build resilience. It creates a false sense of control.

Governance, Roles, and Accountability

One of the most significant aspects of the regulation is the increased accountability of the management body. Digital operational resilience cannot be delegated entirely to technical functions. This also has a direct impact on business continuity plans.

When responsibilities are ambiguously distributed, response times lengthen and critical decisions come to a standstill. Clear governance is therefore needed: who decides to switch to crisis mode, who authorizes workarounds and degraded solutions, who assesses the return to normal operations, and who interacts with authorities, customers, and strategic stakeholders. In this context, business continuity is not merely aboutmaintaining process continuity. It is about command and control.

Furthermore, unproductive overlap between functions should be avoided. Information security, IT operations, operational risk, compliance, and business continuity must maintain distinct areas of expertise while working within a coherent framework. If each function assesses criticality, impact, and priority using different metrics, the system loses effectiveness precisely when it should be accelerating.

Business Impact Analysisand ICT Dependency Mapping

BIA remains a key tool, but under DORA it must evolve. It is no longer enough to collect data on maximum downtime or alternative manual activities. We need a deeper understanding of the digital dependencies that underpin essential services.

This involves at least three considerations. The first concerns granularity: a service may appear to be managed by multiple applications but may in fact be exposed to a single point of failure, such as an identity provider, middleware, data repository, or external vendor. The second concerns data integrity: in some scenarios, the problem is not unavailability, but the unreliability of the information. The third concerns the interdependencies between processes, which, in the event of a cyber incident, tend to propagate the impact far beyond the initial perimeter.

An updated BIA in line with DORA must therefore establish relationships between critical processes, key services, ICT assets, external dependencies, and tolerance levels. It is both a technical and organizational task. If carried out superficially, it compromises the entire planning chain.

Testing: Putting the DORA Regulation to the Test and Business Continuity

Testing reveals the true maturity of an organization. DORA requires testing programs that are proportionate to the organization’s size, risk profile, and operational complexity. For business continuity, this means moving away from a approach based on formal, scheduled testing and toward one focused on substantive verification.

A well-designed tabletop exercise can be useful for validating roles, escalation procedures, and communication. However, it is not sufficient to demonstrate the ability to recover from outages in complex digital services. Technical tests, controlled failovers, cross-functional drills, and scenarios involving third parties, prolonged downtime, data corruption, and decision-making under conditions of incomplete information are also required.

There is also an often-overlooked factor: testing isn’t just about confirming that something works. It’s about identifying where it doesn’t work. That’s why the results must lead to corrective actions, investment priorities, and a review of plans. If an organization conducts tests but fails to address the gaps that emerge, it remains compliant only in appearance.

Third-Party ICT Providers and Service Continuity

DORA places great emphasis on third-party ICT providers, a decision that is consistent with the operational realities of the financial sector. Many significant outages are not caused by internal failures, but by poorly managed outsourced dependencies.

For business continuity, this means that plans cannot be limited to the company’s boundaries. They must take into account supplier response times, escalation procedures, access to information during an incident, contractual clauses, exit options, and the sustainability of alternatives. An economically justifiable redundant solution is not always available. But the risk must at least be understood and consciously accepted—not discovered during a crisis.

This is where the methodological approach makes all the difference. A thorough assessment of critical dependencies makes it possible to distinguish between transferable risk, mitigable risk, and risk that requires true internal continuity capabilities. Continuitaly often focuses precisely on this intersection between compliance, operational preparedness, and a concrete assessment of exposures.

From Compliance to Operational Resilience

The goal is not to produce more documents. It is to build a system that continues to function—even in a degraded state—when the digital component comes under stress. This requires consistency across policies, architectures, roles, testing, and reporting. It also requires a certain degree of organizational honesty: not all organizations have the same level of maturity, and not all gaps can be closed quickly.

For some organizations, the priority will be to realign governance and clarify accountability. For others, it will be to review BIAs and recovery strategies. For still others, the critical issue will be dependence on third parties or poor integration between crisis management and incident response. DORA does not impose a single solution. However, it does require that the chosen model be proportionate, traceable, and defensible.

When DORA regulations and business continuity are treated as separate disciplines, the result is fragile compliance. When, on the other hand, they are integrated into an operational resilience program, the organization improves its responsiveness, reduces decision-making uncertainty, and enhances the credibility of its risk management efforts in the eyes of regulators, customers, and the market.

Ultimately, the value does not lie in having one more plan. It lies in knowing which services must remain operational—for how long, with what resources, and under what decision-making structure—when the incident is no longer a hypothetical scenario but an operational reality.

This post is also available in: