DORA Regulation: What It Really Changes

A cyber incident that disrupts a critical service is no longer just an IT security issue. For financial institutions and their essential service providers, the DORA regulation redefines the issue as one of operational resilience, governance, and the demonstrable ability to continue, scale back, or resume operations. It is this shift in perspective that explains its scope.

The text does not simply add yet another layer of regulation. It seeks to address a well-known weakness in mature organizations: systems that may perform well in isolation but are insufficiently integrated across IT risk management, business continuity, crisis management, third-party oversight, and testing. For those responsible for business continuity plans (BCPs), disaster recovery plans (DRPs), information security systems (ISS), risk management, or compliance, the challenge is therefore less about producing new documents than about aligning existing practices—which are often only partially in place.

What the DORA Regulation Covers

The Digital Operational Resilience Act applies to the European financial sector with a clear goal: to make digital resilience a consistent focus of management. In practice, the regulation organizes these expectations into five closely related areas.

The first component concerns ICT risk management. This involves not only identifying cyber threats, but also establishing a governance framework, roles, policies, and processes for detection, protection, response, and recovery. The expected level of compliance depends on the entity’s size, risk profile, and complexity. This point is essential, as DORA does not impose blind standardization. It requires a demonstrable and proportionate approach.

The second section focuses on the management and reporting of major incidents. Many organizations already have a process in place for reporting security incidents. DORA takes this a step further by requiring classification criteria, escalation procedures, coordination among business units, compliance, legal, IT, and communications teams, as well as the ability to report incidents according to a formalized framework. The challenge is not merely theoretical. It often lies in the timing, the quality of the incident classification, and the consistency of the information shared.

The third section addresses digital operational resilience testing. This is a particularly foundational aspect for teams. Testing can no longer be viewed as an isolated technical verification. They must reflect critical services, plausible scenarios, internal and external dependencies, as well as the organization’s actual ability to operate in degraded mode. For some entities, advanced tests—including threat-led tests—fall within the scope.

The fourth section addresses risk management related to third-party ICT service providers. This is often where discrepancies are most evident. An organization may have robust internal procedures but still rely on providers that have not been adequately assessed, are not properly contracted, or represent an excessive concentration of risk. DORA requires a more rigorous approach to outsourcing and digital dependencies, with particular attention paid to critical providers.

Finally, the fifth area focuses on sharing information about cyber threats within an organized framework. This aspect is sometimes given secondary importance in roadmaps, even though it contributes to the sector’s collective maturity.

Why DORA Directly Affects Business Continuity

Many stakeholders initially interpreted DORA as a cybersecurity regulation. This is a common misinterpretation. The regulation refers to digital operational resilience, which immediately places business continuity and crisis management at the heart of the framework.

A service can be protected by robust security controls and yet still lack sufficient resilience. All it takes is for an application dependency to be poorly mapped, for a cloud provider to be insufficiently integrated into the crisis response plan, or for no degraded operation scenarios to have been thoroughly tested. DORA requires that availability, recovery, crisis decision-making, communication, and third-party governance be linked.

For thoseresponsible for the PCAand PRA, this changes the nature of the work expected. The plans must no longer simply exist; they must be consistent with the ICT architecture, business impacts, tolerance thresholds, escalation procedures, and notification requirements. This alignment is crucial during an inspection or audit, as this is often when the gap between documentation and operational capability becomes apparent.

The most common discrepancies in the field

In organizations that are already well-structured, challenges do not always stem from a lack of systems. More often than not, they stem from a lack of alignment.

The first gap relates to governance. Responsibilities exist, but remain scattered across IT security, production, risk management, compliance, procurement, business continuity, and business units. However, DORA requires clear decision-making, active oversight, and management’s ability to understand critical dependencies. Without this cross-functional coordination, decisions are slow and priorities are conflicting.

The second gap relates to mapping. Many companies understand their critical processes but lack a sufficiently actionable view of their IT resources, supporting applications, workflows, third parties, and points of concentration. This limitation results in incomplete impact analyses and weakens test scenarios.

The third discrepancy is evident in the exercises. Tests are sometimes too technical, or conversely, too theoretical. Yet a useful exercise must test the entire chain: detection, assessment, decision-making, crisis coordination, recovery, communication, and lessons learned. A test is only valuable if it highlights real-world trade-offs.

The fourth gap lies in supplier relationships. Contractual provisions, audit rights, notification requirements, exit plans, and ongoing monitoring mechanisms do not always meet expectations. This issue becomes critical when a small number of service providers support a large portion of essential operations.

How to Implement the DORA Regulation in a Credible Manner

It is very tempting to launch a DORA program as a traditional regulatory project focused on producing evidence. That would be too narrow an approach. A credible approach begins with an operations-oriented maturity assessment.

First, you must identify critical services and processes, then verify that the associated IT assets, applications, data, vendors, and crisis roles are properly mapped. This step may seem basic, but it sets the stage for everything else. Without it, it is impossible to prioritize tests, assess impacts, or reliably classify a major incident.

Next comes the work of aligning existing frameworks. In many organizations, ISO 22301, ISS policies, disaster recovery plans (DRPs), crisis management procedures, and outsourcing requirements still operate at different paces. DORA does not necessarily require starting from scratch. It requires demonstrating that these building blocks work together. This is an important distinction, as it helps avoid cumbersome and unproductive programs.

The tests must then be reviewedfrom a business perspective. A good test plan does not attempt to cover everything at the same level. It targets the most critical scenarios, the most sensitive dependencies, and the most difficult decisions. Depending on the situation, it may be more useful to test a degraded service mode than a complete, idealized recovery that is unrealistic within the expected timeframe.

When it comes to third parties, an effective approach combines contract review, concentration analysis, criticality assessment, and monitoring mechanisms. Here again, it all depends on the context. The level of effort required is not the same for a peripheral supplier as it is for a service provider supporting a critical function. Proportionality remains a useful principle, provided it is properly justified.

Finally, training plays a role that is often underestimated. DORA establishes a requirement for collective competence, not just documentary compliance. Teams responsible for business continuity, crisis management, risk management, IT, and cybersecurity must share a common language, common criteria, and common reflexes. It is precisely in this area that professionalization makes the difference between a formal system and a capability that can actually be mobilized.

DORA Regulations and Oversight: What the Authorities Will Be Looking For

The authorities will not limit themselves to verifying the existence of policies. They will look for evidence of leadership, consistency, and continuous improvement. This involves useful indicators, documented decisions, regular reviews, documented exercises, and action plans that are followed through.

A mature organization is not one that claims to have everything under control. It is one that understands its dependencies, its limitations, its failure scenarios, and its resilience. From this perspective, the DORA regulation acts as a litmus test. It distinguishes between systems designed to look good on paper and those designed to hold up under stress.

For resilience professionals, this is therefore a strategic issue. It is not merely a matter of meeting regulatory requirements, but of strengthening a framework for decision-making and action in the face of incidents that now involve technology, operations, suppliers, and reputation.Specialized training programs, such as those offered by DRI France, can effectively structure this skill-building process when it comes to transforming cross-functional requirements into well-managed operational practices.

The right approach isn’t to ask whether DORA creates more work. It’s to ask what weaknesses in coordination, testing, or governance the document finally brings to light—and which ones your organization can address systematically right now.

This post is also available in: