The Digital Operational Resilience Act (Regulation (EU) 2022/2554) harmonizes how EU financial entities manage information and communication technology (ICT) risk, replacing a patchwork of national rules and sector guidance with one binding framework. DORA has applied since 17 January 2025, so for most firms this is no longer a preparation exercise. It is about staying compliant, closing gaps supervisors are now actively probing, and keeping pace with the technical standards that continue to arrive.
Who is in scope
DORA casts a deliberately wide net. It applies to roughly 20 categories of financial entity operating in the EU, including credit institutions, payment and electronic money institutions, investment firms, crypto-asset service providers, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision, credit rating agencies, trading venues, central securities depositories, central counterparties, crowdfunding service providers, and account information service providers, among others.
Proportionality is built in. Microenterprises and certain small entities face a simplified ICT risk-management framework, while the full weight of the regime falls on larger, more systemically important firms. But scope is broad, and being "small" does not mean being exempt. It means applying a lighter version of the same obligations.
The second population DORA reaches is ICT third-party providers. Any provider of ICT services to financial entities is affected indirectly through the contractual and risk-management duties DORA places on its clients. A subset, those designated as critical ICT third-party providers (CTPPs) such as major cloud and core-technology vendors, fall under a new direct EU oversight framework run by the European Supervisory Authorities (ESAs), with a lead overseer assigned to each. If your firm depends on a hyperscaler or a dominant core-banking vendor, DORA is now shaping that relationship from both ends.
The five pillars explained
DORA organizes its requirements into five interlocking pillars. Treating them as separate compliance projects is a common mistake; they share data, governance, and reporting plumbing, and supervisors expect them to be joined up.
| Pillar | What it requires | Key obligation |
|---|---|---|
| ICT risk management | A documented, board-owned framework to identify, protect against, detect, respond to, and recover from ICT risk across all systems and functions. | Maintain an ICT risk-management framework with clear management-body accountability and mapping of ICT assets to critical or important functions. |
| ICT-related incident reporting | Classify ICT-related incidents by severity and report major incidents to competent authorities on a fixed schedule. | Submit initial, intermediate, and final reports for major incidents using the harmonized templates. |
| Digital operational resilience testing | A risk-based testing programme spanning vulnerability assessments, scenario testing, and (for significant entities) advanced threat-led testing. | Run a proportionate testing programme, including threat-led penetration testing (TLPT) at least every three years for in-scope entities. |
| ICT third-party risk management | Govern the full lifecycle of ICT outsourcing and dependency, with mandatory contractual terms and concentration-risk controls. | Maintain a register of information on all ICT third-party arrangements and embed DORA-required clauses in contracts. |
| Information sharing | Enable voluntary exchange of cyber-threat intelligence among financial entities within trusted communities. | Participate in threat-intelligence sharing on a voluntary basis, within data-protection limits. |
The first pillar, ICT risk management, is the foundation. It requires the management body (not just the technology function) to own an ICT risk-management framework covering strategy, policies, tools, asset inventories, and business-continuity and recovery arrangements. Critical and important functions must be identified so that the rest of the regime can be scoped against them.
Incident reporting turns operational events into supervisory data. Resilience testing proves the framework works rather than merely existing on paper. Third-party risk management extends control to the vendors that now run much of the sector's infrastructure. Information sharing, the only voluntary pillar, encourages firms to pool threat intelligence so the whole system learns faster than any single firm could alone.
The ICT third-party register and oversight of critical providers
Third-party risk is where many firms have the most work to do. DORA requires each entity to maintain a register of information documenting all contractual arrangements for the use of ICT services: provider identity, the functions supported, whether those functions are critical or important, subcontracting chains, and more. National competent authorities collect these registers annually (the reference submission point is by 30 April), and the standardized machine-readable format (xBRL-CSV) makes data quality unforgiving: incomplete or inconsistent registers are visible immediately.
Contracts must carry DORA's mandatory provisions, including rights to access, inspect, and audit; clear service-level descriptions; assistance during incidents; exit strategies; and data-handling terms. For arrangements supporting critical or important functions, the bar is higher still.
At EU level, the ESAs designate critical ICT third-party providers and subject them to direct oversight through a lead overseer that can issue recommendations, request information, and conduct inspections. Financial entities cannot outsource their way out of accountability: even where a CTPP is overseen centrally, the entity remains responsible for managing its own concentration and dependency risk.
Incident classification and reporting timelines
DORA replaces divergent national incident regimes with a single classification-and-reporting flow. Firms first assess whether an ICT-related incident is major using criteria set out in the technical standards, factors such as clients affected, data losses, duration and service downtime, geographical spread, economic impact, and criticality of services affected.
Once an incident is classified as major, three reports follow to the competent authority:
- Initial notification: within 4 hours of classifying the incident as major, and no later than 24 hours after the entity became aware of it.
- Intermediate report: within 72 hours of the initial notification, updating status and impact; an updated intermediate report is expected once regular activities are restored.
- Final report: within one month, delivered when the root-cause analysis is complete, covering causes, impact, and remediation.
Two practical points catch firms out. First, the clock starts at classification, not at leisurely internal escalation, so classification has to be fast and defensible. Second, incidents originating at a third party still count: if a major incident at a provider affects your critical or important functions, the reporting obligation is yours even when you learn of it indirectly. DORA also introduces a voluntary channel for notifying significant cyber threats, distinct from mandatory incident reports.
Threat-led penetration testing (TLPT)
Every entity must run a proportionate testing programme: vulnerability scans, network security assessments, penetration tests, scenario-based tests, and reviews of source code where relevant. Sitting above the baseline is threat-led penetration testing (TLPT): advanced, intelligence-driven red-team testing against live production systems, modelled on the TIBER-EU framework.
TLPT is not for everyone. Competent authorities identify the entities required to perform it based on size, risk profile, and systemic importance, and those entities must run a TLPT exercise at least every three years, covering the critical or important functions in scope. Tests may use internal or external testers, subject to independence conditions, and can be pooled where several entities share the same ICT provider. Because TLPT touches production and reaches third-party systems, coordination with providers and overseers has long lead times. Firms in scope should be planning cycles well ahead of their deadlines rather than treating each test as a one-off.
Ongoing RTS and ITS to watch
DORA is a framework regulation: much of the operative detail lives in Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) developed by the ESAs and adopted by the European Commission. These are not static. New and amended standards continue to be published, and they change what "compliant" means in concrete terms, from the fields in the register of information to incident-report templates and classification thresholds.
Areas where the technical standards are especially load-bearing include:
- Incident reporting: the harmonized content and templates for major-incident reports and the classification thresholds that decide what counts as major.
- Register of information: the exact taxonomy and machine-readable format entities must submit.
- ICT risk management: the detail behind policies, tools, and simplified frameworks for smaller entities.
- Third-party risk: subcontracting conditions for services supporting critical or important functions.
- Oversight: how CTPPs are designated and how oversight fees and processes operate.
Because these instruments arrive on their own schedule and amend earlier ones, tracking them is a continuous obligation rather than a launch-day checklist. Missing an amendment can quietly put a previously compliant process out of line with the current text.