The Digital Operational Resilience Act (DORA) is a European Union regulation that sets common rules for how financial entities manage the risk of their information and communication technology (ICT). It covers ICT risk management, reporting of major ICT-related incidents, digital resilience testing, management of ICT third-party providers and information sharing on cyber threats. As a regulation, it applies directly across the EU. It is unrelated to the “DORA metrics” used to measure software delivery. This entry is an overview for buyers, not legal advice.
At a glance
- DORA applies to around twenty types of EU financial entities, including banks, insurers, investment firms, payment and e-money institutions and crypto-asset service providers.
- It has applied since 17 January 2025.
- Financial entities must keep an ICT risk management framework, classify and report major ICT incidents, test resilience and maintain a register of ICT third-party arrangements.
- Contracts with ICT providers must include specific terms, with more for services supporting critical or important functions.
- Providers designated as critical ICT third-party providers come under direct EU oversight.
What problem it solves
Financial services now run on technology, much of it supplied by a small number of cloud, data center and software providers. Before DORA, rules on ICT risk were spread across different sector guidelines and national practices, and supervisors had little visibility into the providers that many firms shared. An outage or attack at one large provider could hit many institutions at once.
DORA sets one rulebook for operational resilience and gives supervisors a view of, and oversight over, the most important providers. For mid-market buyers, it matters in two ways: EU financial firms must meet it directly, and anyone selling technology to them will be asked to support it.
How it works
ICT risk management. Financial entities maintain a documented framework covering identification, protection, detection, response, recovery, backup and communication, owned and approved by the management body.
Incident reporting. ICT-related incidents are classified by set criteria, and major ones are reported to the competent authority in stages: initial, intermediate and final reports.
Resilience testing. Entities run a testing program, such as vulnerability assessments, scenario testing and penetration testing. Some are required to perform threat-led penetration testing.
Third-party risk. Entities assess providers before contracting, keep a register of information on all ICT arrangements, include required contract terms, such as service descriptions, data locations, audit rights, incident assistance and exit provisions, and plan exits for critical services.
Oversight of critical providers. The European Supervisory Authorities designate critical ICT third-party providers and oversee them directly.
Scope and roles
| Category | Who it covers | What is required | Typical evidence |
|---|---|---|---|
| Financial entity | In-scope EU banks, insurers, investment firms, payment institutions and others | Full ICT risk framework, incident reporting, testing, third-party risk management | Framework documents, register of information, incident reports, test results |
| Simplified regime | Certain smaller or less complex financial entities named in DORA | A lighter ICT risk management framework | Simplified framework documentation |
| Entity selected for threat-led testing | Financial entities identified by authorities based on impact and risk | Advanced threat-led penetration testing on a recurring cycle | Test attestation |
| ICT third-party service provider | Technology providers serving financial entities | Contract terms required by DORA; support for audits, incidents and exit | Contract addenda, security reports, exit support |
| Critical ICT third-party provider | Providers designated by the European Supervisory Authorities | Direct EU oversight, including inspections and recommendations | Oversight engagement with the lead overseer |
When it matters for buyers
- When you are an EU financial entity. DORA applies to you directly; your providers’ contracts and registers are part of it.
- When you sell technology to EU financial firms. Expect DORA contract addenda, audit rights and incident-assistance terms.
- When choosing cloud and data center providers for critical functions. Exit plans, data location and concentration risk need answers.
- When planning business continuity. Testing and recovery need evidence, not just a plan.
Our governance, risk and compliance, public cloud, disaster recovery as a service and penetration testing overviews cover providers that support DORA programs.
Questions to ask vendors
- Will you sign a DORA-compliant contract addendum, including audit and access rights for us and our supervisor?
- Where are our data and the service processed, and which subcontractors support critical functions?
- How quickly will you notify us of ICT incidents, and what information will you provide for our reports?
- Will you take part in our resilience testing, including threat-led testing if we’re selected?
- What exit support will you provide, and how long will data and services remain available during transition?
- Have you been designated as a critical ICT third-party provider?
How it differs from NIS2
The Network and Information Security Directive (NIS2) covers many sectors through national laws and focuses on cybersecurity measures and incident reporting. DORA is a directly applicable regulation for the financial sector and goes further on ICT third-party risk, contract content, resilience testing and oversight of critical providers. For financial entities in DORA’s scope, its rules generally take precedence over NIS2’s equivalent requirements. DORA builds on familiar practice: business continuity and disaster recovery (BCDR), incident response (IR) and provider commitments of the kind found in a service level agreement (SLA). A governance, risk and compliance (GRC) program maps these together.