DORA, the Digital Operational Resilience Act, is Regulation (EU) 2022/2554. It creates a common EU framework for how financial entities manage ICT risk, report major ICT-related incidents, test resilience, manage ICT third-party risk, and share information about cyber threats. The regulation has applied since 17 January 2025.
For a financial organization, the practical point is simple: security controls are only part of the job. DORA expects the organization to understand which financial services depend on technology, prepare for ICT disruption, recover in a controlled way, and keep third-party dependencies inside the same risk model.
This page explains DORA at the regulation level. Detailed incident timelines, Register of Information requirements, operational-resilience design, third-party risk, and DORA/NIS2 overlap have their own guides, so each question has one clear owner.
DORA sets uniform requirements for the security and resilience of the network and information systems that support financial entities. Its legal name is the Digital Operational Resilience Act, but the regulation is much easier to understand when read as an operating model: identify ICT risk, protect services, detect and manage disruption, recover, test the model, and control dependencies on ICT providers.
The official text of Regulation (EU) 2022/2554 is available on EUR-Lex. It entered into force on 16 January 2023 and has applied since 17 January 2025. That distinction matters because older DORA articles still describe 2025 as a future compliance date.
A quick regulation-level view is useful before moving into the specialist requirements.
| DORA at a glance | What it means |
| Legal instrument | Regulation (EU) 2022/2554 on digital operational resilience for the financial sector |
| Application date | 17 January 2025 |
| Primary objective | A common EU framework for managing ICT risk and maintaining digital operational resilience in financial services |
| Core regulated areas | ICT risk management; ICT-related incident management and reporting; resilience testing; ICT third-party risk; information sharing |
| Third-party dimension | Financial entities remain responsible for ICT third-party risk, while designated critical ICT providers can be subject to EU-level oversight |
| Technical detail | Delegated and implementing acts, including RTS and ITS, specify parts of the DORA framework |
Before DORA, ICT and cyber risk in finance were covered through a mix of sector-specific rules, supervisory expectations, national approaches, and outsourcing guidance. That made it harder for cross-border financial groups to work from one consistent ICT risk model, and it left important dependencies on technology providers spread across different regulatory frameworks.
The EU response was to create one financial-sector framework focused on digital operational resilience. The European Commission describes the policy objective as strengthening financial firms' ability to prevent ICT incidents, limit disruption, and recover quickly when incidents occur. The framework also addresses the sector's growing dependence on external technology providers, including large cloud and infrastructure providers.
That policy background explains why DORA is broader than a security-control standard. A financial entity can have mature security tooling and still fail operationally if it cannot restore a payment service, classify an incident, coordinate a provider outage, or show management how ICT risk affects critical services.
DORA did not create every ICT risk practice from zero. Financial institutions already had cybersecurity, business continuity, outsourcing, and incident management obligations. The change is that DORA brings those areas into one directly applicable EU regulation and makes their relationship much more explicit.
The most important shift is from separate control domains toward a connected resilience model. The same service dependency can now appear in ICT risk management, continuity planning, incident handling, testing, the Register of Information, and third-party oversight. That creates a stronger need for shared data and ownership across security, IT, risk, compliance, procurement, continuity, and business teams.
At a high level, the regulation changes the operating expectation in several ways.
| Earlier fragmented approach | DORA-era expectation |
| ICT risk managed through sector or local frameworks | A common EU digital-operational-resilience framework for in-scope financial entities |
| Incident reporting differed across financial sectors | Harmonised DORA classification and reporting rules for major ICT-related incidents |
| Outsourcing records often sat in procurement or vendor-management systems | ICT third-party arrangements become part of the ICT risk framework and Register of Information |
| Continuity and security testing could run as separate assurance activities | Resilience testing is tied to the wider ICT risk framework and remediation cycle |
| Major technology providers were mainly governed through customer contracts | DORA adds an EU oversight framework for designated critical ICT third-party providers |
DORA applies to a broad set of financial entities listed in Article 2. The list spans banking, payments, investment and market infrastructure, insurance, pensions, crypto-assets, crowdfunding, and other regulated financial activities. Scope should be checked against the legal entity and authorization, not against a company's marketing label.
Representative in-scope categories include the following. The regulation contains the complete list and also sets specific exclusions and proportionality rules.
| Entities in the DORA scope | Examples |
| Banking and payments | Credit institutions, payment institutions, account information service providers, electronic money institutions |
| Investments and markets | Investment firms, trading venues, central counterparties, central securities depositories, trade repositories |
| Funds and asset management | Alternative investment fund managers and management companies |
| Insurance and pensions | Insurance and reinsurance undertakings, certain intermediaries, institutions for occupational retirement provision |
| Digital finance | Crypto-asset service providers and issuers of asset-referenced tokens, crowdfunding service providers |
| Other regulated financial infrastructure | Credit rating agencies, critical benchmark administrators, data reporting service providers, securitisation repositories |
ICT service providers sit in a different position. DORA regulates how financial entities select, contract with, monitor, and exit ICT providers, and it creates an EU oversight framework for providers designated as critical. A software or cloud supplier does not simply become equivalent to a bank because one customer is DORA-regulated.
DORA requirements are easiest to navigate as a set of major areas. Each area creates a different operational problem, so the detailed rules are covered in dedicated guides.
| Requirement area | What DORA expects at a high level | Detailed guide |
| ICT risk management | Governance, ICT risk framework, protection and prevention, detection, response and recovery, backup, learning, communication | Operational Resilience: What It Means Under DORA |
| ICT-related incidents | Management, classification, and reporting of major ICT-related incidents; voluntary notification of significant cyber threats | DORA Incident Reporting Timeline and Workflow |
| Digital operational resilience testing | A testing program appropriate to the entity, with advanced threat-led penetration testing for entities that meet the applicable criteria | DORA Penetration Testing and TLPT |
| ICT third-party risk | Due diligence, contractual requirements, monitoring, concentration risk, subcontracting considerations, and exit planning | DORA ICT Third-Party Risk Management |
| Register of Information | Structured information on contractual arrangements with ICT third-party providers | DORA Register of Information Readiness |
| Information sharing | Voluntary exchange of cyber-threat information and intelligence within trusted communities under DORA conditions | Covered on this page |
| Technical standards | RTS and ITS that specify implementation details for parts of the regulation | DORA RTS and ITS: Complete Technical Standards List |
DORA places ICT risk inside the organization's wider risk governance rather than treating it as a security team-side process. The management body has direct responsibilities, and the ICT risk management framework has to connect strategy, assets, protection, detection, continuity, recovery, learning, and communication.
For a service-level view of how governance, continuity, recovery, testing, and dependencies fit together, see our guide to operational resilience under DORA.
DORA requires financial entities to manage and classify ICT-related incidents and report major incidents to the relevant competent authority. The classification criteria, reporting content, and reporting time limits are specified through the regulation and current technical standards.
For the current classification-to-notification sequence and reporting deadlines, see our DORA incident reporting timeline and workflow.
DORA requires a digital operational resilience testing program that matches the entity's risk and regulatory position. Testing can include vulnerability assessments, scenario-based tests, compatibility and performance testing, end-to-end testing, penetration testing, and other techniques. Certain financial entities are also subject to threat-led penetration testing requirements.
The purpose is evidence, not ceremony. Tests should expose whether protection, continuity, recovery, people, and dependencies work as assumed, then feed findings back into remediation and risk governance.
DORA places the management body inside the ICT risk framework rather than treating ICT resilience as a technical delegation. Article 5 requires the management body to define, approve, oversee, and remain responsible for the arrangements related to the ICT risk management framework. It also has responsibilities around roles, policies, continuity, audit follow-up, budget, and ICT third-party arrangements.
The practical consequence is that DORA evidence cannot stop at security-team activity. Management needs information that supports decisions: which services carry the most ICT risk, which dependencies create concentration or recovery problems, which incidents changed the risk profile, which testing findings remain open, and where resilience investment is needed.
Financial entities often depend on cloud platforms, software vendors, telecommunications, managed services, and other ICT providers to deliver regulated services. DORA keeps responsibility with the financial entity even when technology is outsourced. That is why third-party risk sits inside the ICT risk framework rather than only in procurement.
Our DORA ICT third-party risk management guide covers provider due diligence, contract requirements, critical or important functions, concentration risk, subcontracting, monitoring, and exit planning. The Register of Information guide separately owns the structured record of ICT contractual arrangements.
DORA requires financial entities to maintain and update a Register of Information covering contractual arrangements for ICT services. The register supports entity-level third-party risk management, supervisory work, and the EU process for identifying critical ICT third-party providers.
The register has a prescribed reporting structure and its own data-quality problems, so it deserves more than a paragraph in a general DORA article. For the reporting structure, data relationships, tooling options, and preparation work, see our DORA Register of Information Readiness guide.
DORA also allows financial entities to exchange cyber-threat information and intelligence through trusted arrangements. The purpose is to improve collective awareness of threats, indicators of compromise, tactics, techniques, procedures, and defensive measures without turning information sharing into a mandatory reporting channel.
This part of DORA is easy to overlook because it does not create the same deadline-driven workflow as incident reporting. It still matters for mature security operations because threat information can improve detection and defensive decisions across participating financial entities.
DORA does not revolve around one compliance document. Evidence is distributed across the operating model: ICT risk assessments, asset and dependency information, policies, incident records, continuity and recovery documentation, testing results, third-party contracts, the Register of Information, remediation records, management reporting, and supervisory submissions.
The useful question is whether those records tell the same story. If a financial service is described as critical in one system but the corresponding provider, recovery dependency, or incident path is missing elsewhere, the documentation may exist without proving operational resilience. That is why the detailed DORA guides interlink around the same service and dependency model rather than standing as isolated compliance articles.
Regulation (EU) 2022/2554 establishes the main legal framework. Delegated and implementing acts then specify parts of that framework, including technical rules on ICT risk management, incident classification and reporting, the Register of Information, third-party arrangements, and other DORA areas.
The European Commission maintains the current list of DORA delegated and implementing acts. Because the standards have their own search intent and are easy to confuse, we maintain a separate reference page rather than packing a changing catalog into this hub.
For the adopted technical standards and the DORA requirement each one supports, see our DORA RTS and ITS technical standards list.
DORA and NIS2 overlap in some areas, but the answer cannot be reduced to "DORA replaces NIS2." For relevant financial entities, DORA acts as the sector-specific EU framework for equivalent ICT risk management and incident-reporting obligations, while group structures and other entities can still create separate NIS2 questions.
If your entity or group may fall under both frameworks, our DORA vs NIS2 comparison explains which obligations are displaced and where NIS2 still requires separate attention.
DORA supervision follows the competent-authority structure of the financial sector. The relevant authority can investigate compliance, require remediation, issue orders, and apply the administrative penalties or remedial measures available under DORA and national law. Article 50 requires those measures to be effective, proportionate, and dissuasive.
There is no single EU-wide DORA fine ceiling that can be quoted for every financial entity. Member States provide the sanctioning framework for breaches by financial entities, while DORA contains a separate EU oversight regime for designated critical ICT third-party providers. Under that regime, a Lead Overseer can issue recommendations and, in defined circumstances, impose periodic penalty payments on a critical provider that does not comply with oversight measures.
The important point is accountability rather than a headline fine number. Financial entities need to be able to show the competent authority that the ICT risk framework exists in practice, that known weaknesses are addressed, and that third-party dependence has not removed management responsibility.
DORA does not require every financial entity to implement every measure at identical depth. Article 4 applies proportionality across key parts of the framework, taking account of size, overall risk profile, and the nature, scale, and complexity of services, activities, and operations.
Proportionality does not remove the underlying obligation. It changes how an organization designs and evidences the framework. A smaller financial entity may need a simpler operating model than a large cross-border institution, but it still needs to understand its ICT risks, dependencies, incident processes, continuity arrangements, and applicable reporting duties.
A useful starting point is to establish scope and ownership before collecting policies. The goal is to understand which legal entities and financial services are affected, which ICT dependencies support them, and which DORA workstreams already have usable evidence.
From there, the work can branch into the specialist areas without creating duplicate documentation. A sensible sequence is to confirm scope and governance, map critical services and ICT dependencies, assess the ICT risk framework, check incident management and reporting, review testing, and map third-party arrangements and the Register of Information; then close evidence gaps against the applicable technical standards.
That sequence is an implementation approach, not a legal checklist.
The master DORA question is settled once the organization can connect scope, governance, ICT risk, incidents, recovery, testing, and third-party dependencies around the financial services it must keep reliable. The next step is to move into the workstream that carries the actual gap rather than expanding the same general DORA document again.
Turn DORA requirements into evidence your teams can operate
Assess ICT risk, strengthen detection and response, review third-party security, and build evidence around DORA requirements.
These short answers cover the broad questions that belong with the master page. Detailed workflow questions stay with their dedicated guides.
DORA stands for the Digital Operational Resilience Act. Its main legal instrument is Regulation (EU) 2022/2554 on digital operational resilience for the financial sector.
DORA is an EU regulation, so Regulation (EU) 2022/2554 is directly applicable. A companion directive, Directive (EU) 2022/2556, amended several financial-services directives to align them with DORA.
DORA has applied since 17 January 2025. The regulation entered into force earlier, on 16 January 2023.
Yes. Credit institutions are explicitly within DORA scope. The regulation also covers many other financial entities, including payment institutions, investment firms, insurers, market infrastructures, and certain crypto-asset providers.
No. DORA includes cybersecurity controls, but it also covers governance, business continuity, recovery, incident reporting, resilience testing, ICT third-party risk, and information sharing.
DORA governs financial entities' ICT third-party relationships and creates EU oversight for designated critical ICT providers. Not every software or cloud supplier is regulated in the same way as an in-scope financial entity.
RTS and ITS are technical standards that specify how parts of DORA are implemented or reported. They sit underneath Regulation (EU) 2022/2554 and should be checked for the workstream they govern.
No. DORA is the financial-sector digital operational resilience framework. NIS2 is a broader cybersecurity directive covering many sectors. Their interaction for dual-scope entities depends on the entity and obligation involved.