What is DORA?

Why financial services need a resilience law

Banks, payment providers, insurers and investment firms now run on software, cloud services and outsourced technology. When a core system stops, a payment cannot be made, a trade cannot settle and customers lose access to their money, and an attack on a single technology supplier can affect many institutions at the same time.

This is why the European Union adopted DORA. Before it, ICT risk was covered by scattered rules, guidelines and supervisory practices that differed between countries and sectors. DORA consolidates and upgrades them into one harmonized regulation for the financial sector. Who is accountable when a critical system fails? How quickly must a major incident be reported? Which suppliers does the entity depend on? DORA answers these questions with legal obligations.

What is DORA?

DORA is Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector. It entered into force in January 2023 and has applied since 17 January 2025.

Because it is a regulation, it applies directly in all EU Member States without being transposed into national law, which is the main difference from a directive such as NIS 2. DORA is considered a sector-specific rule for financial entities, so where it applies it takes precedence over the general cybersecurity rules for the same subject matter. Supervisory authorities, not certification bodies, decide whether an entity complies.

DORA builds on earlier work of the European Supervisory Authorities (ESAs): the European Banking Authority, the European Securities and Markets Authority and the European Insurance and Occupational Pensions Authority.

Who must comply with DORA?

DORA applies to a wide range of financial entities operating in the EU, and also to ICT third-party service providers that serve them. Article 2 of the regulation lists the entities in scope, which include:

• Credit institutions and payment institutions
• Electronic money institutions
• Investment firms and trading venues
• Crypto-asset service providers
• Insurance and reinsurance undertakings and insurance intermediaries
• Managers of alternative investment funds and management companies
• Central securities depositories, central counterparties and trade repositories
• ICT third-party service providers, including critical ICT third-party providers designated by the ESAs
• The obligations are proportionate: smaller and microenterprises follow a simplified ICT risk management framework, so confirm which regime applies to your entity

The five pillars of DORA

The requirements of DORA are organized into five pillars. An entity should plan its programme around them because each one will be examined by supervisors.

• ICT risk management (Chapter II): a documented ICT risk management framework, with the management body approving and overseeing it. The framework covers identification, protection, detection, response and recovery, business continuity and backup, and learning from incidents
• ICT-related incident management, classification and reporting (Chapter III): a process to detect, classify and report major ICT-related incidents to the competent authority, normally as an initial notification, an intermediate report and a final report after root cause analysis
• Digital operational resilience testing (Chapter IV): a risk-based testing programme, including vulnerability assessments, scenario-based tests and, for entities identified by authorities, threat-led penetration testing (TLPT) at defined intervals
• ICT third-party risk management (Chapter V): a strategy, a register of information of all contractual arrangements, due diligence, mandatory contract provisions and exit strategies. Critical ICT third-party providers fall under an EU oversight framework with a Lead Overseer
• Information sharing (Chapter VI): voluntary arrangements for sharing cyber threat information and intelligence between financial entities

The management body's responsibility

One of the clearest changes introduced by DORA is that the management body of the financial entity carries the final responsibility for managing ICT risk. In the scope of Article 5, the management body defines, approves, oversees and is accountable for the implementation of the ICT risk management framework.

This means that digital resilience cannot be left only to the IT department. The management body must set the risk tolerance, allocate adequate budget, approve the digital resilience strategy and the policy on the use of ICT third-party services, and keep sufficient knowledge of ICT risk, including through training. Is the board actually reviewing ICT incident and third-party data, or only receiving an annual summary?

Incident reporting under DORA

Reporting of major ICT-related incidents is one of the most operational requirements. The entity must have processes to monitor, log, classify and, where the incident is major, report it to the competent authority. Classification uses criteria such as the number of clients affected, the duration, the geographical spread, the data losses, the criticality of the services and the economic impact.

Reporting follows stages: an initial notification, an intermediate report as the situation develops, and a final report once the root cause analysis is complete. The exact content and time limits are set in implementing and delegated acts adopted under DORA, so confirm the current timelines with your supervisory authority. DORA also allows voluntary notification of significant cyber threats. Is the incident response plan tested, and does the team know who decides that an incident is major?

ICT third-party risk and the register of information

Financial institutions rely heavily on cloud, software and outsourcing providers, and DORA treats this dependency as a core risk. The entity remains fully responsible for compliance even where functions are outsourced.

• Register of information: a maintained record of all contractual arrangements with ICT third-party providers, distinguishing those that support critical or important functions
• Due diligence: assessment of providers before the contract and during its life, including concentration risk
• Contract provisions: mandatory clauses on service levels, security, audit and access rights, incident support, sub-contracting and termination
• Exit strategies: tested plans to move away from a provider without disrupting critical functions
• Critical providers: ICT providers designated as critical by the ESAs are overseen directly by a Lead Overseer, in addition to the entity's own supervision

DORA, ISO 27001 and NIS 2

DORA and ISO 27001 are related but different. ISO 27001 is a voluntary international standard for an information security management system, while DORA is a binding EU regulation with specific obligations on incident reporting, testing and third-party management. An ISO 27001 system gives an entity a strong base of risk assessment, policies, internal audit and management review, but it does not cover every DORA requirement and certification is not proof of compliance.

NIS 2 is the general EU cybersecurity directive for essential and important entities. For financial entities in scope, DORA is the specific framework, and its requirements are treated as the sector-specific rules. Entities that also fall under other regimes, such as GDPR for personal data, need to align the processes so that one incident can be handled consistently under all of them.

How to prepare for DORA

A gap analysis is the first practical step, because most entities already have some of the measures in place. A reasonable sequence is:

• Scope: confirm whether your entity, or your services, fall under DORA and which proportionality regime applies
• Governance: assign management body responsibility and define the ICT risk management framework
• Gap analysis: compare current ICT risk, incident, testing and third-party practices with the requirements
• ICT asset and function mapping: identify critical or important functions and the systems and providers that support them
• Incident process: set classification criteria, reporting channels and roles, and test them
• Testing programme: plan regular testing and prepare for threat-led penetration testing where required
• Third-party programme: build the register of information, review contracts and prepare exit plans
• Evidence and review: keep records, train staff and the management body, and review the framework at least annually and after major incidents

How ComplyEncrypt helps with DORA

DORA is on the ComplyEncrypt roadmap. ComplyEncrypt is built to bring ICT risk records, policy and procedure drafts, incident and testing documentation, third-party registers and evidence into an AI-assisted workflow, and to connect them with ISO 27001, GDPR and NIS 2 work so evidence is not duplicated.

AI assistance applies to documentation work. People still approve the framework, classify and report incidents, run resilience tests and manage suppliers, and compliance remains the judgement of the supervisory authority, not of any tool or certificate. A vigorous resilience programme protects customers first and the institution second. See the DORA framework page for current availability.