DORA: The EU’s Digital Operational Resilience Act

Introduction

The EU’s Digital Operational Resilience Act, DORA, heralds a new era in compliance. This may sound like a bold pronouncement but is actually an informed statement of fact.

Digital operational resilience is the ability of a financial entity to build, assure and review its operational integrity and reliability for the full range of ICT-related capabilities needed to address the security of network and information systems for continued provision and quality of financial services, including through disruptions.

Unlike regulatory guidance, DORA is an Act with full legal force. It is legally binding and enforceable in court and can result in associated penalties and other legal consequences. Another important differentiator is that DORA is prescriptive, in contrast to most regulations that are principles-based. DORA cites “will, shall, and must” throughout, which means that its very specific directives and requirements are not optional. These considerations amplify the importance thoughtful implementation, and of compliance.

Until now, regulators for different segments of the financial services sector have published separate regulatory guidance, according to the sector they govern. DORA does not bifurcate the types of financial entities in this way, but it does cite oversight by one primary regulator for each covered entity. This may come as a relief for entities that are subject to regulatory guidance from more than one regulator.

DORA has a very broad brush. Compliance is mandated for the covered entity’s internal operations for its critical and important activities, and its critical and important ICT third parties. In DORA “ICT” means information and communication technologies. I suspect that the term “ICTs” will be interpreted quite broadly - now or over time.

The list of twenty-one types of covered entities in Article 2 includes traditional entities such as banks and credit institutions and goes on to list virtually every type of financial entity that you can name.

This includes payment institutions previously exempted from EU Directive 2015/22355; account information providers; insurance and reinsurance organizations; crowdfunding service providers; ICT third party service providers; fund management companies; trading and securities-related entities; and crypto-asset service providers. Article 2 presents the full list of covered entities, and there are very few exclusions.

DORA encompasses the organization’s entire extended enterprise, regardless of which party is in the lead. Like most sectors, financial entities are powered by a complex set of networked and/or connected systems and services, accessing sensitive and protected data. DORA does not distinguish between internal operations and third party information and communication technology providers (ICTs).

DORA doesn’t leave it up to the financial entities to push compliance into the critical and important third party ICTs that provide networks, connectivity, and infrastructure services they rely on. Third party ICTs include hardware, software, network services, connectivity, data centers, cloud service providers, security tools, and any other technology dependent products or services that the covered entity relies on to deliver its critical and important services including core operations.

DORA doesn’t leave anything to chance.

DORA Marks a New Era

When analyzing DORA, Regulatory Technical Standards, and associated regulatory guidance for Third Party Risk Institute’s Certified DORA Practitioner (CDP) program, I asked myself why the European Banking Authority (EBA) published a prescriptive Act, instead of perpetuating a long history of principles-based regulatory guidance. The answer became clear as my understanding of its scope and requirements grew.

Regulatory guidance is typically principles-based, subject to a reasonable degree of interpretation according to the size and complexity of the covered entity, the businesses it is in, and prevailing practices in its peer group. Regulatory guidance provides a clear indication of supervisory expectations. but is not actually a law or a regulation.

In contrast, DORA is a legally binding Act with a long list of specific requirements. It applies to a long list of financial entities that are examined by different regulators according to their businesses, and their third parties that deliver ICT services in the EU. DORA bridges laws, regulatory guidance, financial entities, and ICT third parties. Although financial services regulators can bind third party ICTs indirectly through regulated entities, they don’t directly regulate them. DORA changes this.

Regulatory Guidance is typically principles-based and subject to interpretation, so it may be that regulators have grown weary of “asking” organizations to implement regulatory guidance. DORA’s requirements are risk-informed, practical and feasible, a compendium of best practices that have proven to be effective over the years. DORA holds covered entities and members of their boards of directors accountable for compliance, thereby embedding proven best practices across the sector.

Mandated Requirements

The scope of mandated requirements is equally broad. DORA defines requirements for the risk management framework, governance, security policies, asset management, encryption, network security, identify and access controls, data management, project and change management, HR policies, vulnerability and patch management, incident detection and response, business continuity and contingency plans, concentration risk, and testing, to name a few.

The Act is organized by topic but doesn’t follow a lifecycle management operating model. As a result, you’ll need to consult more than one Article to address a single topic. The accompanying Regulatory Technical Standards (RTS) offer more detail to support implementation. Plus, related regulatory guidance must be considered.

Getting Started

A full analysis of requirements is a great way to start. You may wish to create a list of Articles relating to each major topic. This is what I did when developing the content for our Certified DORA Practitioner program. For example, extensive business continuity management requirements are addressed in Articles 11, 12 and 28, and incident management requirements are addressed in Articles 13, 14, 17 and 18.

If this hasn’t been done, the next step is documenting your organization’s critical and important activities. Being thoughtful in your definition of these terms mean to your organization is essential for determining in-scope activities and ICTs and provides consistency across business segments and core operations. In my experience, describing operational dependency and the impact of a serious interruption on operations, clients, fiduciary responsibilities, and financial impact on revenues and recovery at the enterprise and business segment level is really helpful.

This information should inform DORA-mandated Business Impact Analysis, a formal process that will be new in many covered entities. Business Impact Analysis (BIA) is a systematic analysis of a business segment’s operations, BIAs help determine how serious disruptions affect operations, priorities, Recovery Time Objectives, Recovery Point Objectives, and resource requirements.

An enterprise-level definition of critical and important activities serves as a guide for the business segment to identify its critical and important activities, and the critical and important third parties that support them. It is particularly important to identify those that are a single point of failure or do not have workarounds. Notably, critical and important third parties must be inventoried and reported to the covered entity’s primary regulator in a prescribed format. Over time, this information will be put to good use by regulators to govern serious risk events that can affect the safety and security of the sector and identify higher levels of concentration risk.

“New” Requirements

While not new to financial entities with mature non-financial risk practices, complying with the many stringent requirements such as documenting risk management strategies and frameworks, documenting and testing business continuity plans and exit plans, 4th party due diligence and risk oversight, risk monitoring, threat-level penetration testing, assessing concentration risk, and classifying and reporting major incidents will undoubtedly challenging, particularly for third party ICT. Fortunately, DORA’s principle of “proportionality” helps to align work effort with benefits.

Treating risk management as a compliance exercise is akin to wilful blindness. If your organization has a habit of taking the path of least resistance by narrowly interpreting regulatory guidance, those days are over. DORA sets a new standard.

Join the Webinar

Ready to operationalize DORA for 2026? Join our webinar on April 29 featuring Linda Tuck Chapman for her in-depth review on Operationalizing DORA for 2026: Scaling Digital Risk Resilience and Compliance. Master vendor tiering, continuous monitoring, remediation SLAs, and audit-ready reporting. Register today.