DORA regulation: pillars, entities involved, and compliance

What is the DORA regulation?

Definition and origin of the European regulation

DORA stands for Digital Operational Resilience Act. It refers to Regulation (EU) 2022/2554, adopted by the European Parliament and the Council on December 14, 2022, and published in the Official Journal of the European Union on December 27, 2022.

It is accompanied by a directive, Directive (EU) 2022/2556, which amends several existing sectoral texts (CRD, Solvency II, MiFID II, PSD2, etc.) to align them with the new requirements. Because it is a regulation, DORA applies directly in all Member States without the need for transposition: the same rules apply in Paris, Madrid, or Frankfurt.

The text was born from a simple observation. Before DORA, IT security requirements for financial institutions were scattered across numerous directives, guidelines, and national practices. This fragmentation created blind spots, particularly regarding the growing reliance on third-party ICT providers, such as cloud service providers.

Objectives of digital operational resilience

Digital operational resilience refers to a financial entity's ability to build, ensure, and review its operational integrity in the face of ICT-related risks. In other words: to withstand an incident, limit its impact, and then quickly resume business operations.

The DORA regulation pursues four main objectives:

• Harmonize rules for managing ICT risks across the entire European financial sector.
• Strengthen the ability of companies to detect, contain, and resolve ICT-related incidents.
• Regulate relationships with ICT providers, including the most critical ones, which are now subject to direct European oversight.
• Hold accountable management: the governing body bears final responsibility for the ICT risk management framework.

The core idea is to shift from a defensive compliance mindset to one of continuity: it is no longer just about preventing attacks, but about ensuring that critical functions continue to operate when an incident occurs.

Effective date and regulatory context

DORA entered into force on January 16, 2023, and has been applicable since January 17, 2025. The two-year interim period allowed the European Supervisory Authorities (EBA, ESMA, and EIOPA) to publish the Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) that specify the requirements: incident classification, contract content, information registers, penetration testing, and more.

DORA is part of a broader regulatory landscape, alongside the NIS 2 Directive on the cybersecurity of essential and important entities, the GDPR for data protection, and the Cyber Resilience Act for digital products. For financial entities, DORA acts as the specific legislation: where its provisions overlap with those of NIS 2, DORA takes precedence.

Which financial entities are covered by DORA?

Article 2 of the regulation lists around twenty categories of entities covered by DORA. The scope is intentionally broad: it covers almost the entire European financial ecosystem, as well as the service providers that keep it running. However, the text applies a principle of proportionality: requirements are scaled according to the size, risk profile, and complexity of each entity's activities.

Banking and financial institutions

The primary target of the regulation is credit institutions, i.e., banks. But DORA goes well beyond large banking groups. It also applies to payment institutions, electronic money institutions, account information service providers, and crypto-asset service providers authorized under the MiCA regulation.

Market infrastructures are also within the scope: central counterparties, central securities depositories, trading venues, and trade repositories. Their central role in the functioning of the financial system makes them particularly closely monitored actors.

Insurance and reinsurance undertakings

Insurance and reinsurance undertakings are fully covered, as are insurance and reinsurance intermediaries, with the exception of the smallest ones (micro, small, and medium-sized structures according to the text's criteria). Institutions for occupational retirement provision are also among the targeted financial entities.

For insurers, the challenge is twofold: protecting massive volumes of sensitive data (health, assets, claims) and ensuring the continuity of critical functions such as claims settlement or contract management.

Investment service providers

Investment firms, UCITS management companies, and alternative investment fund managers (AIFMs) must also comply with DORA. The regulation also targets credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, and securitization repositories.

For these actors, who are often mid-sized, the difficulty lies less in the technical nature of the requirements than in their formalization: documenting, testing, and proving what was sometimes managed informally.

Third-party ICT service providers

This is one of DORA's major innovations. Third-party ICT service providers (hosting services, cloud providers, software publishers, managed service providers, security service providers) are affected in two ways.

All are affected indirectly, through the contractual requirements that their financial clients must impose on them. The most significant ones, designated as critical third-party providers by European authorities, are also subject to direct oversight: inspections, requests for information, recommendations, and, in the event of non-compliance, financial penalties. A company that is not itself a financial entity can therefore find itself at the heart of DORA regulation.

The 5 pillars of DORA regulation

The regulation is organized around five complementary pillars. Together, they cover the entire digital risk lifecycle: prevent, detect, respond, test, and learn.

ICT risk management

This is the foundation of DORA. Every financial entity must have a robust, comprehensive, and documented ICT risk management framework. This framework must enable the entity to:

• Identify information assets, the business functions that depend on them, and the associated risks.
• Protect and prevent through tailored security measures: access management, encryption, updates, and securing workstations and networks.
• Detect abnormal activity quickly.
• Respond and recover business activities through continuity, backup, and restoration policies.
• Learn and evolve from past incidents.

The governing body defines, approves, and oversees this framework. It must also receive regular training on ICT risks: cybersecurity is no longer just an IT department issue.

Reporting major incidents

DORA mandates a harmonized process for detecting, classifying, and reporting ICT-related incidents. Each incident is evaluated based on specific criteria: number of affected clients, duration, geographical spread, data loss, criticality of affected services, and economic impact.

When an incident is classified as major, the entity must report it to its competent authority according to a strict schedule, detailed later in this article. Entities may also voluntarily report significant cyber threats they identify.

Operational resilience testing

A security system that is never tested remains theoretical. DORA therefore requires the implementation of a digital operational resilience testing program, proportionate to the entity's size: vulnerability assessments, source code reviews, performance testing, scenario-based testing, and penetration testing.

Systems supporting critical functions must be tested at least once a year. The most significant entities, as designated by authorities, must also conduct threat-led penetration tests (TLPT) every three years, based on the European TIBER-EU framework. These tests simulate real-world attacks on production systems.

Managing third-party provider risks

Financial entities remain fully responsible for their compliance, even when outsourcing. They must therefore adopt a strategy for managing ICT third-party risk that covers the entire relationship: pre-contractual assessment, mandatory contractual clauses, continuous monitoring, and exit strategies.

They must also maintain an information register documenting all contractual agreements with ICT providers. This register is submitted to authorities, allowing them to identify dependencies and concentration risks across the market.

Cyberthreat intelligence sharing

The final pillar: cooperation. DORA encourages financial entities to share information and intelligence on cyberthreats with one another, including indicators of compromise, attacker tactics, security alerts, and detection tools.

These exchanges take place within trusted communities, in compliance with confidentiality requirements and the GDPR. Participating entities must notify their competent authority. The goal is for an attack detected at one firm to help protect all others.

How to achieve DORA compliance?

DORA compliance is not a one-off project, but an ongoing process integrated into your overall cyber-compliances trategy. Here are the five key steps to structure your implementation.

Conduct an audit of existing systems and identify gaps

Everything starts with an assessment. The goal is to compare your current practices against the requirements of the regulation and its technical standards, pillar by pillar. This audit covers governance, security policies, existing tools, incident management processes, and contracts with service providers.

The expected outcome is a clear gap analysis: what is already compliant, what needs to be strengthened, and what is completely missing. Each gap is then prioritized based on its risk level and the effort required to address it. This roadmap will guide the rest of the project.

Map critical functions and ICT service providers

DORA focuses on critical or important functions: those whose disruption would compromise the entity's financial performance, service continuity, or regulatory compliance. You must identify these and link each one to the systems, data, equipment, and providers that support them.

This mapping includes your entire IT infrastructure: servers, applications, as well as workstations and mobile devices, which are often entry points for attacks. It serves as the basis for the ICT provider information register and reveals hidden dependencies, such as multiple critical services relying on the same cloud provider.

Establish an ICT risk management framework

Once risks are identified, they must be managed. The ICT risk management framework formalizes your policies (information security, access management, patch management, backup, encryption), individual roles and responsibilities, and monitoring indicators.

There is no need to start from scratch: existing frameworks provide a solid foundation. An organization already certified to ISO 27001 has an information security management system that covers a large portion of DORA's requirements. However, it will need to be supplemented to address the regulation's specifics: incident classification, notification timelines, contractual clauses, and testing programs.

Establish a digital business continuity plan

DORA requires an ICT business continuity policy, supported by response and recovery plans. For each critical function, these plans define recovery objectives: the maximum tolerable downtime (RTO) and the maximum acceptable data loss (RPO).

In practical terms, this requires regular, isolated, and tested backups, fallback sites or environments, documented restoration procedures, and a crisis communication plan. These plans must be tested at least once a year and updated after every significant incident.

Training teams and raising stakeholder awareness

Technology alone is not enough if employees cannot recognize a phishing email or react to an incident. DORA mandates ICT security awareness programs and digital operational resilience training for all staff, including members of the management body.

These actions may also extend to third-party ICT providers where relevant. Attack simulations, crisis exercises, and short, regular modules: the goal is to establish a lasting culture of security, rather than a one-off annual training session that is quickly forgotten.

Reporting obligations and relations with competent authorities

Reporting ICT-related incidents

Reporting a major incident follows three stages, with deadlines set by European technical standards:

These very tight deadlines require prior preparation: ready-to-use classification procedures, designated leads, pre-filled reporting templates, and tools capable of providing technical data quickly. When an incident impacts clients' financial interests, the entity must also inform them without delay, along with the measures taken.

Communication with the ACPR and the AMF in France

In France, DORA supervision is primarily handled by two competent authorities. The Autorité de contrôle prudentiel et de résolution (ACPR), backed by the Banque de France, supervises banks, payment and electronic money institutions, and insurers. The Autorité des marchés financiers (AMF) is responsible for management companies, certain investment and digital asset service providers, and market infrastructures.

These authorities receive incident notifications and the information register, and they may request additional documents, conduct audits, and impose sanctions. It is therefore essential to clearly identify your lead authority and follow their publications, which specify the practical procedures for submission.

Documentation and traceability of measures

Under DORA, if it isn't documented, it doesn't exist. Entities must be able to prove their compliance at any time: policies approved by management, up-to-date mapping, test results and remediation plans, incident history, contracts, and the information register.

Furthermore, the ICT risk management framework must be reviewed at least once a year and after every major incident. Rigorous traceability facilitates audits and supports continuous improvement: it allows you to measure progress and justify investments to management.

Solutions and tools to facilitate DORA compliance

IT management and cybersecurity platforms

You can only protect what you know. Yet, in many organizations, the IT inventory is incomplete: unreferenced computers, accounts of former employees that are still active, or software installed without validation. These are all vulnerabilities that complicate the mapping required by DORA.

IT management platforms centralize this information in a single tool: equipment inventory, mobile device management (MDM), update tracking, and access management for onboarding and offboarding employees. Coupled with the right cybersecurity tools (EDR, password managers, multi-factor authentication, disk encryption), they provide a clear and up-to-date view of your risk exposure.

This is the rzilient approach: managed and secure IT, where every workstation is inventoried, protected, and monitored from a single platform. A concrete foundation to support your ICT risk management framework.

Automated reporting and monitoring

The notification deadlines imposed by DORA make manual monitoring difficult to sustain. Automation allows for faster detection of abnormal behavior, centralized alerts, and instant access to the information needed to classify an incident.

Key levers include real-time compliance dashboards, alerts for outdated or unencrypted workstations, centralized event logging (SIEM), and automated report generation. These tools reduce the burden on teams and ensure the reliability of the documentation required by authorities.

Support from operational resilience experts

DORA requires a diverse range of skills: legal for contracts, technical for security and testing, and organizational for governance. Few organizations possess all this expertise in-house, especially mid-sized companies.

Relying on external experts (specialized firms, auditors, managed service providers, penetration testers) can accelerate compliance and provide an independent perspective. However, be aware that these partners are themselves ICT providers who must be included in your register and governed by compliant contracts.

Frequently asked questions about DORA

What is the difference between DORA and NIS 2?

NIS 2 is a cross-sector directive that strengthens cybersecurity across many essential or important sectors: energy, health, transport, digital, public administration, etc. DORA is a regulation specific to the financial sector, which is more detailed and directly applicable.

When a financial entity falls under both, DORA takes precedence for ICT risk management, incident reporting, and testing. Both texts share the same philosophy: governance, risk management, incident reporting, and supply chain control. To find your way around, check out our article on the various cybersecurity standards.

What are the penalties for non-compliance with DORA?

For financial entities, DORA leaves it to member states to define administrative sanctions and corrective measures. In France, these are issued by the ACPR or the AMF in accordance with the Monetary and Financial Code: warnings, reprimands, injunctions, potentially very high financial fines, and the publication of the decision.

For critical third-party providers, the regulation directly provides for periodic penalty payments of up to 1% of the average daily worldwide turnover for each day of non-compliance, for a maximum of six months. Beyond sanctions, the main risk remains reputational and operational: a poorly managed incident can cost far more than a fine.

Are SMEs affected by DORA?

Yes, in two cases. An SME that carries out a financial activity covered by the regulation (fintech, payment institution, management company, significant insurance broker, etc.) is directly affected. However, micro-enterprises benefit from a simplified ICT risk management framework, in accordance with the principle of proportionality.

An SME that provides IT services to financial players (software publishers, hosting providers, managed service providers, IT consulting firms) is indirectly affected: its clients will require contractual guarantees, audits, and the ability to participate in their tests. Anticipating these requirements becomes a real competitive advantage.

How does DORA impact contracts with IT providers?

Article 30 of the regulation establishes a list of mandatory clauses for all ICT service contracts. These include a comprehensive description of services, data processing and storage locations, commitments regarding availability, integrity, and security, incident support, cooperation with authorities, and termination rights.

For services supporting critical or important functions, requirements are more stringent: precise and measurable service levels, notice periods, mandatory tested business continuity plans, participation in penetration testing, audit rights, and exit strategies. Many existing contracts will therefore need to be renegotiated. This is an opportunity to select IT partners capable of demonstrating their own level of security.