Short answer
The , has applied since 17 January 2025. Covered financial entities must prepare for, contain, recover from and learn from ICT incidents. The management body remains responsible despite outsourcing.
After a cyber incident or service outage, the entity must activate documented continuity, response, recovery and communication arrangements; preserve records; restore secure services and data; assess impact; classify the incident; inform affected clients where their financial interests are affected; and conduct a root-cause and lessons-learned review. A major ICT-related incident triggers an initial notification as early as possible—within four hours of major classification and no later than 24 hours after awareness—an intermediate report within 72 hours of the initial notification, and a final report within one month after the intermediate or latest updated report.
DORA also requires resilience testing, a register of ICT contracts, vendor due diligence, concentration-risk assessment, contract controls, exit plans and subcontracting oversight. Providers designated “critical” face an EBA, ESMA or EIOPA Lead Overseer, without displacing entity-level duties.
Which entities and incidents are covered?
DORA covers the financial entities listed in Article 2, subject to targeted exclusions. Some smaller entities use Article 16’s simplified framework, while proportionality applies more broadly.
An ICT-related incident is an unplanned event, or linked series, that compromises system security and adversely affects data or services. “Major” means a high adverse impact on systems supporting a critical or important function. DORA also covers operational or security payment incidents for specified banking and payment entities. It is a sector-specific Union act for the NIS2 overlap described in Article 1(2), but separate GDPR personal-data-breach duties can still apply.
Governance does not move to the cloud provider
DORA Article 5 makes the allocation explicit:
“The management body of the financial entity shall define, approve, oversee and be responsible for the implementation of all arrangements related to the ICT risk management framework” —
The management body sets ICT risk tolerance and approves the resilience strategy, continuity plans, audit programme, budget and third-party policy. It must receive information on major incidents and corrective action. Non-microenterprises also require independent risk control and regular internal audit.
The framework must be documented, normally reviewed at least yearly and after a major incident. It connects prevention and detection with response, recovery, communication and learning. A serious outage therefore triggers reassessment and remediation.
What must happen during and after the outage?
The entity must preserve critical functions, contain damage, restore secure operations, estimate losses, manage communications and retain accessible records.
Backups need documented scope and frequency, tested restoration, secure separation and criticality-based recovery objectives. Recovery includes data-integrity checks. Plans for critical or important systems, including outsourced systems, must be tested yearly and after substantive changes.
Article 13 requires a post-incident review when a major incident disrupts core activities. It must examine causes, response speed, forensic analysis where appropriate, escalation and communications, then feed lessons into the risk assessment. Senior ICT staff report findings and recommendations to the management body at least yearly.
When does an incident become reportable?
Article 18 assesses affected clients, counterparties and transactions; reputation; duration and downtime; geographical spread; data loss; service criticality; and economic impact. supplies the thresholds.
The incident must affect a critical service and either involve successful malicious unauthorised access that may cause data loss, or meet at least two other thresholds. These include 24 hours’ duration; two hours’ critical-function downtime; impact in at least two Member States; likely costs or losses above EUR 100,000; and specified client, transaction, reputation or data impacts. Related same-root-cause incidents occurring twice within six months can be aggregated, subject to small-entity exclusions.
The reporting clock in is exact:
“for the initial report: as early as possible, but in any case, within four hours from the classification of the ICT-related incident as a major ICT-related incident and no later than 24 hours from the moment the financial entity has become aware of the ICT-related incident” —
The intermediate report is due within 72 hours of the initial notification, even if status has not changed, with updates without undue delay and when normal activities recover. The final report is due within one month of the intermediate or latest updated report. If classification occurs after 24 hours, the initial notification is due within four hours of classification. Delay must be explained to the authority by the applicable deadline. supplies the standard forms and submission procedures.
If a major incident affects clients’ financial interests, they must be informed without undue delay about the incident and mitigation. Significant cyber-threat notification is voluntary, although potentially affected clients should receive appropriate protective measures where applicable.
Testing is continuous, with TLPT for selected entities
Non-microenterprises need risk-based vulnerability, scenario, end-to-end and penetration testing as appropriate. Critical or important systems require yearly testing, independent execution and tracked remediation.
Selected entities must conduct threat-led penetration testing (TLPT) on live production systems at least every three years, subject to supervisory adjustment. specifies selection, scoping, tester, methodology, remediation and cooperation requirements. Outsourced systems remain within scope; providers may have to participate in individual or pooled testing, while the entity remains responsible.
Vendor contracts, registers and subcontractors
Outsourcing does not dilute responsibility:
“financial entities that have in place contractual arrangements for the use of ICT services to run their business operations shall, at all times, remain fully responsible for compliance with, and the discharge of, all obligations under this Regulation” —
Before contracting, the entity must classify the function, assess risk and concentration, perform due diligence and identify conflicts. It must maintain entity-level—and where relevant consolidated—registers of every ICT arrangement, distinguishing critical or important support. Supervisors can request the register; specified arrangement data is reported yearly, and planned critical-function arrangements require timely notice. prescribes the templates.
Every contract needs written service and data locations, security protections, data access and return, service levels, incident assistance, authority cooperation and termination rights. Critical-function contracts add quantitative service levels, contingency testing, TLPT participation, audit rights and a transition period supporting a tested exit strategy.
develops the third-party policy lifecycle. requires visibility, due diligence, access rights, monitoring and advance notice for material subcontracting changes affecting critical services. The entity must assess the change and retain termination rights where risk exceeds its tolerance.
What changes when the provider is designated critical?
Criticality is a formal ESA designation based on systemic impact, financial-sector reliance, critical-function dependence and substitutability, further specified by . It is not simply a description chosen in a contract.
The Lead Overseer assesses security, continuity, governance, incident handling, testing and subcontracting. It may request information, investigate, inspect and recommend action. A provider has 60 days to accept a recommendation or explain why not. Continued deficiencies can lead authorities to require suspension or termination. A designated third-country provider must establish an EU subsidiary within 12 months.
governs oversight information requests, remediation plans, progress reports, subcontracting data and recommendation follow-up. structures the joint examination teams that support oversight plans, investigations, inspections and recommendation monitoring. These oversight mechanics do not transfer the financial entity's duties.
Direct provider oversight does not make the Lead Overseer the incident manager and does not replace the financial entity’s report. Provider contracts and oversight must ensure prompt incident information, cooperation, access and recovery assistance so the financial entity can meet its own deadlines.
No Court of Justice judgment interpreting DORA was located through 31 July 2026. The should therefore be rechecked for later developments rather than borrowing conclusions from older operational-risk cases.
Conclusion
DORA treats an outage as a full governance and resilience event. Covered financial entities must contain and recover, classify and report when thresholds are met, inform affected clients, preserve evidence, review root causes and remediate. They must prove preparedness through testing and control vendors through complete registers, due diligence, enforceable contracts, subcontractor visibility and tested exit plans. Critical providers face additional ESA oversight, but the financial entity remains accountable for continuity, compliance and reporting throughout the disruption.
Sources
This article provides general legal information, not advice for a specific matter. Laws, facts and procedural deadlines may change the result. Follow the linked primary sources and obtain local advice before acting.