DORA Incident Reporting in 2026: Deadlines, Classification and Compliance Checklist
The Digital Operational Resilience Act has changed how financial organizations in the European Union classify, manage, and report serious technology incidents.
DORA has applied since 17 January 2025 and establishes a harmonized framework for ICT risk management, operational resilience, third-party risk, testing, and incident reporting across the financial sector.
For incident-response teams, one of the most important requirements is the reporting of major ICT-related incidents.
The reporting process is time-sensitive.
Under Commission Delegated Regulation (EU) 2025/301, a financial entity must submit its initial notification:
- as early as possible;
- within four hours after the incident is classified as major; and
- no later than 24 hours after the entity becomes aware of the ICT-related incident.
The intermediate report is due within 72 hours after the initial notification, while the final report is due no later than one month after the intermediate report or latest updated intermediate report.
That means DORA incident reporting is not simply a compliance-form exercise.
It requires the organization to know, in advance:
- which incidents could qualify as major;
- which services are critical or important;
- who has authority to classify an incident;
- which competent authority receives the report;
- who owns each reporting stage;
- which evidence must be preserved;
- how suppliers provide incident information;
- which other regulatory obligations may run in parallel.
The central question is:
Can your organization move from detection to classification to regulatory notification quickly enough to meet the DORA clock?
DORA Reporting Deadlines at a Glance
| Reporting stage | Deadline |
|---|---|
| Incident awareness | Record immediately |
| Major-incident classification | As soon as enough information is available |
| Initial notification | As early as possible; within 4 hours of major classification and no later than 24 hours from awareness |
| Intermediate report | Within 72 hours from the initial notification |
| Updated intermediate report | Without undue delay when material information changes; in any event when regular activities are restored |
| Final report | Within 1 month of the intermediate or latest updated intermediate report |
If an incident is not classified as major during the first 24 hours but is classified as major later, the entity must submit the initial notification within four hours of that classification.
If a financial entity cannot meet one of the deadlines, Regulation 2025/301 requires it to notify the competent authority without undue delay—and no later than the applicable reporting deadline—explaining the reason for the delay.
Table of Contents
What Is DORA?
DORA is Regulation (EU) 2022/2554, the EU’s framework for digital operational resilience in the financial sector.
It applies to a broad range of financial entities rather than only traditional banks.
Depending on the entity type and applicable provisions, this includes organizations such as:
- credit institutions;
- payment institutions;
- electronic money institutions;
- investment firms;
- insurance and reinsurance undertakings;
- insurance intermediaries;
- crypto-asset service providers;
- central securities depositories;
- central counterparties;
- trading venues;
- fund managers;
- pension institutions;
- credit-rating agencies;
- crowdfunding service providers;
- other financial entities listed in DORA.
DORA also creates significant obligations around ICT third-party providers and operational dependency.
For a broader sector-level security review, see Finance Sector Cybersecurity Checklist 2026.
What Is an ICT-Related Incident?
DORA treats an ICT-related incident as an event that compromises the security of network and information systems and adversely affects:
- availability;
- authenticity;
- integrity;
- confidentiality
of data or services provided by the financial entity.
Not every technology incident becomes reportable.
A service interruption, supplier failure, software defect, network outage, malicious intrusion, ransomware event, or data compromise may all require assessment, but only incidents meeting the DORA major-incident classification criteria must be reported under Article 19.
That makes classification one of the most important steps.
When Does an ICT Incident Become “Major”?
Commission Delegated Regulation (EU) 2024/1772 sets out the classification logic.
An incident is considered major when:
- it affects critical services; and
- either:
- the specified serious data-loss threshold is met; or
- two or more of the other materiality thresholds are met.
The regulation also provides special treatment for malicious unauthorized access to systems supporting critical or important functions, recognizing that such intrusions can create serious risk even before full impact is known.
This is an important improvement over simply creating a checklist of standalone percentages.
The thresholds must be applied through the regulatory classification logic.
What Counts as a Critical Service?
Under the DORA classification framework, critical services include ICT services or network and information systems supporting:
- critical or important functions; or
- financial services requiring authorization.
Malicious unauthorized access to systems supporting critical or important functions receives particularly serious treatment under the rules.
Before an incident happens, financial entities should therefore know which:
- applications;
- business processes;
- third-party platforms;
- networks;
- cloud services;
- identity systems
support critical or important functions.
Without that mapping, fast classification becomes difficult.
DORA Major-Incident Thresholds
Commission Delegated Regulation 2024/1772 contains several materiality thresholds.
Clients, Financial Counterparts and Transactions
The threshold may be met where, for example:
- more than 10% of clients using the affected service are impacted;
- more than 100,000 clients are affected;
- more than 30% of relevant financial counterparts are affected;
- more than 10% of the daily average number of relevant transactions is affected;
- more than 10% of the daily average value of relevant transactions is affected.
Where exact figures are not yet available, the regulation allows financial entities to use reasonable estimates based on available data.
Duration and Service Downtime
The materiality threshold is met where:
- the incident lasts longer than 24 hours; or
- service downtime exceeds 2 hours for ICT services supporting critical or important functions.
Geographical Spread
The threshold is met when the incident has an impact in two or more EU Member States under the regulatory assessment criteria.
Economic Impact
A further materiality threshold concerns the economic impact of the incident.
The regulation requires financial entities to assess relevant direct and indirect costs and losses and permits estimates where final amounts are unavailable at reporting time.
This is why financial evidence should be collected from the beginning of an incident rather than reconstructed weeks later.
Data Loss
DORA considers the effect on:
- availability;
- authenticity;
- integrity;
- confidentiality
of data.
Particular attention is given to data-loss impacts affecting the entity’s business objectives or ability to comply with regulatory obligations.
Cybersecurity Time DORA Classification Matrix
A useful operational decision path looks like this:
| Question | Example | Action |
|---|---|---|
| Is this an ICT-related incident? | Payments platform outage | Open DORA assessment |
| Does it affect a critical/important function? | Payment processing unavailable | Continue classification |
| Is malicious unauthorized access involved? | Intrusion into privileged systems | Immediate senior escalation |
| Client/transaction threshold met? | >10% affected | Record threshold |
| Downtime threshold met? | Critical service unavailable >2h | Record threshold |
| Geographic threshold met? | Two Member States affected | Record threshold |
| Economic/data threshold met? | Significant losses/data impact | Record threshold |
| Regulatory major-incident test met? | Critical service + required thresholds | Report under Article 19 |
This is a practical reader framework; the binding classification test remains the DORA Regulation and Delegated Regulation 2024/1772.
Record Three Different Times
One of the most important operational improvements you can make is to record separate timestamps for:
Detection time
When monitoring, users, a vendor, or another source first identified the event.
Awareness time
When the financial entity became aware that an ICT-related incident existed.
Major-classification time
When the organization formally determined that the incident met the major-incident criteria.
These times should not be casually collapsed into one “incident start time.”
The initial-notification rule depends specifically on both awareness and major classification.
The Initial DORA Notification
The initial notification is designed to provide early supervisory awareness.
The financial entity does not need to wait for a complete forensic investigation.
Commission Implementing Regulation 2025/302 explicitly recognizes that complete information may not be available during the first stage. Where exact information is unavailable, the entity may provide estimated values based on available data, to the extent possible.
That is an important operational principle:
Do not wait for perfect certainty before reporting a major incident.
The reporting model is deliberately progressive.
What the Initial Notification Should Establish
Depending on the required template fields and information available, teams should be ready to establish:
- reporting entity;
- affected entity/entities;
- incident identification;
- awareness timing;
- classification timing;
- affected functions or services;
- current incident status;
- preliminary impact;
- initial mitigation measures.
Use the official competent-authority reporting route rather than maintaining an internally invented DORA form as the final regulatory submission mechanism.
Commission Implementing Regulation 2025/302 establishes the common reporting template and associated data glossary.
The Intermediate Report
The intermediate report is due no later than 72 hours from submission of the initial notification, even where the status or handling of the incident has not materially changed.
An updated intermediate report must be submitted without undue delay when appropriate and, in any case, when regular activities have been restored.
By this point, incident responders should aim to provide a clearer picture of:
- scope;
- affected services;
- affected clients;
- transaction impact;
- geographic impact;
- data impact;
- incident cause;
- ongoing containment;
- recovery status.
This is where disciplined incident chronology becomes very valuable.
Cybersecurity Time’s Data Breach Timeline Template and Cybersecurity Incident Response Timeline provide related operational guidance.
The Final Report
The final report is due no later than one month after the intermediate report or latest updated intermediate report.
This stage should document the mature incident picture.
Typical information includes:
- detailed incident description;
- root cause;
- final impact;
- resolution;
- recovery timing;
- affected functions;
- costs and losses;
- corrective actions.
Organizations should begin gathering this evidence during the incident rather than trying to recreate it during the final week.
DORA Reporting Timeline Example
Consider this example.
08:00 — Monitoring detects severe instability.
09:00 — Incident response confirms a material ICT incident.
11:30 — Business assessment shows a critical payment service is affected.
13:00 — Regulatory team classifies the event as a major ICT-related incident.
The initial notification should be submitted as early as possible and no later than:
17:00, because that is four hours from major classification.
The separate outer limit of 24 hours from awareness also applies.
After the initial filing:
Intermediate report: within 72 hours from submission.
Final report: within one month from the intermediate/latest updated intermediate report.
This example is illustrative rather than legal advice.
What If the Incident Is Classified Major After 24 Hours?
This situation is expressly addressed in Regulation 2025/301.
If an entity does not classify an ICT-related incident as major during the first 24 hours following awareness but later determines that it is major, it must submit the initial notification within four hours from classification.
That means organizations should preserve classification decisions throughout the incident.
A decision such as:
“Threshold not currently met—continue monitoring”
should be documented.
If the situation changes later, the organization can show how and when the classification evolved.
Recurring Incidents Can Become Major Collectively
A useful DORA program should not look only at isolated incidents.
Under Regulation 2024/1772, recurring incidents can collectively qualify as a major incident where they:
- occur at least twice within six months;
- have the same apparent root cause; and
- collectively meet the major-incident classification test.
Financial entities covered by the requirement must assess recurring incidents on a monthly basis.
That is particularly important for:
- repeated payment outages;
- recurring authentication failures;
- recurring supplier disruptions;
- recurring network instability.
Individually minor incidents may reveal a larger resilience problem.
Third-Party Incidents Still Require Internal Governance
DORA does not allow a financial entity to ignore an event merely because the technical cause sits with:
- cloud provider;
- payment processor;
- SaaS provider;
- managed service provider;
- telecommunications supplier;
- software vendor.
Third-party dependencies can still affect the financial entity’s critical or important functions.
Your incident process therefore needs predefined supplier escalation requirements.
See the Third-Party Risk Assessment Checklist and Supplier Cybersecurity Contract Template for supporting controls.
Outsourced DORA Reporting
DORA reporting can involve third parties acting on behalf of financial entities, but outsourcing the submission activity does not remove the organization’s responsibility for governance.
Commission Implementing Regulation 2025/302 includes procedures for third parties reporting on behalf of financial entities and requires competent authorities to receive appropriate identifying information.
If outsourced reporting is used, define in advance:
- reporting provider;
- authority to submit;
- secure communication method;
- contact information;
- backup arrangement;
- data-transfer process.
Do not discover these details while the deadline is running.
Use the Official DORA Reporting Template
Commission Implementing Regulation 2025/302 creates a single reporting template for:
- initial notification;
- intermediate report;
- final report.
The entity completes the fields appropriate to the reporting stage and can supply information early if it is already available. Later reports update information previously submitted.
The regulation also allows combined submission of stages in certain circumstances—for example where recovery or root-cause analysis is already complete—provided the applicable deadlines are respected.
That is useful for incidents that are discovered late in their lifecycle or resolved unusually quickly.
Significant Cyber Threats Can Be Reported Voluntarily
DORA distinguishes major ICT-related incidents from significant cyber threats.
Financial entities may voluntarily notify significant cyber threats when they consider them relevant to:
- the financial system;
- service users;
- clients.
Implementing Regulation 2025/302 provides a separate template for those voluntary notifications.
This creates another useful workflow distinction:
actual major incident → mandatory reporting
significant cyber threat → voluntary notification framework
Client Notification Can Also Be Required
Regulatory filing is not necessarily the only communication obligation.
DORA states that where a major ICT-related incident has an impact on the financial interests of clients, the financial entity must inform those clients without undue delay after becoming aware of the incident and explain measures taken to mitigate the adverse effects.
This means incident communications should consider:
- regulator notification;
- client notification;
- contractual notification;
- privacy obligations;
- other sectoral duties.
One report does not automatically satisfy every obligation.
Track Costs and Losses From the Start
Incident economics can become relevant to classification and final reporting.
Create an incident cost ledger early.
Potential costs may include:
- forensic consultants;
- external legal support;
- overtime;
- emergency infrastructure;
- replacement hardware;
- compensation;
- lost revenue;
- third-party remediation.
The regulation allows estimates where exact values are not yet known.
A disciplined record is much more reliable than asking finance teams to reconstruct everything at the end of the month.
DORA First-24-Hours Checklist
0–1 Hour: Establish the Incident
- assign incident ID;
- preserve evidence;
- record detection time;
- identify affected service;
- activate incident leadership.
1–4 Hours: Establish Regulatory Context
- identify critical/important function;
- assess malicious access;
- estimate clients and transactions affected;
- estimate downtime;
- identify Member States affected;
- assess data impact.
Classification Point
Record:
- classification decision;
- exact classification time;
- approver;
- thresholds triggered.
Reporting Stage
If major:
- notify competent authority as early as possible;
- do not exceed four hours from classification;
- verify the 24-hour awareness limit.
Continue Investigation
Start collecting the information required for the 72-hour intermediate report immediately.
Cybersecurity Time DORA Reporting RACI
| Activity | Primary owner | Supporting teams |
|---|---|---|
| Technical detection | SOC / IT Operations | Vendor |
| Incident command | Incident Response | Business |
| Critical-function assessment | Business Resilience | Operations |
| Major classification | Regulatory/Compliance + Incident Lead | Legal, Security |
| Reporting template | Regulatory Affairs | IR, Legal |
| Competent-authority submission | Authorized Reporting Owner | Compliance |
| Supplier evidence | Third-Party Risk | Procurement |
| Cost tracking | Finance | IR |
| Client communication | Communications/Legal | Business |
| Root-cause report | Technical Owner | Vendor/IR |
This is an example operating model, not a DORA-mandated organizational structure.
What the First Year of DORA Reporting Shows
The reporting regime is now producing substantial real-world supervisory data.
On 3 June 2026, the European Supervisory Authorities published their first annual overview of DORA major ICT-related incidents and emphasized that ICT incidents are increasingly interconnected across borders and institutions.
The EBA’s June 2026 Risk Assessment Report says it had received more than 18,000 DORA-related incident reports through March 2026.
It also reported that:
- system failures were the dominant incident category;
- payment institutions showed relatively greater exposure to external events than credit institutions;
- DDoS, identity theft, and data exfiltration/manipulation were among common techniques in reported cyber incidents involving credit institutions.
This reinforces an important point:
DORA reporting is not just about ransomware.
Operational resilience reporting must also capture serious failures involving:
- infrastructure;
- availability;
- dependencies;
- technology failure;
- third-party disruption.
Common DORA Reporting Mistakes
Waiting for Full Certainty
DORA deliberately uses staged reporting.
The initial notification can be followed by progressively better information.
Do not delay a required notification simply because root cause is not yet confirmed.
Treating Every Threshold Independently
The major-incident test is based on the combination of critical-service impact plus the regulatory threshold logic.
Do not simply create a spreadsheet where one number automatically means “major” without applying the full rule in Regulation 2024/1772.
Confusing Awareness With Classification
These are separate timestamps.
The 24-hour and four-hour rules depend on that distinction.
Ignoring Recurring Incidents
Repeated apparently minor incidents may become a major incident collectively.
Treating Supplier Failures as “The Vendor’s Problem”
The financial entity still needs to assess its own business and regulatory impact.
Using an Old PSD2 Incident Workflow
DORA replaced the previous EBA PSD2 major-incident reporting framework for relevant payment service providers when it became applicable in January 2025. Your original article correctly identifies this transition.
Review legacy playbooks and terminology.
Forgetting Parallel Notification
DORA does not eliminate obligations under other laws, contracts, client relationships, or sector frameworks.
Practical DORA Readiness Checklist
Before the next major incident, verify that your organization has:
Scope
- documented DORA entity classification;
- identified competent authority.
Critical Functions
- mapped critical/important functions;
- mapped supporting ICT systems;
- mapped important suppliers.
Classification
- implemented Regulation 2024/1772 thresholds;
- documented major-incident logic;
- established monthly recurring-incident review.
Reporting
- official templates available;
- reporting portal/channel tested;
- primary and backup reporting owners named.
Timing
- detection timestamp captured;
- awareness timestamp captured;
- classification timestamp captured.
Third Parties
- emergency contacts established;
- incident evidence requirements written into contracts;
- reporting cooperation tested.
Evidence
- chronology process;
- impact estimates;
- costs/loss ledger;
- root-cause evidence.
Communications
- client notification workflow;
- legal/privacy review;
- executive escalation.
Frequently Asked Questions
When did DORA become applicable?
DORA has applied since 17 January 2025.
When must the initial DORA incident notification be filed?
As early as possible and:
- within 4 hours from classification as major; and
- no later than 24 hours after awareness of the ICT incident.
If major classification occurs after the initial 24-hour period, notification is due within four hours from classification.
When is the intermediate report due?
Within 72 hours after submission of the initial notification.
When is the final report due?
No later than one month after the intermediate report, or after the latest updated intermediate report where applicable.
Must every ICT incident be reported?
No.
All relevant incidents need appropriate management and classification, but Article 19 reporting applies to incidents classified as major according to DORA’s regulatory criteria.
Can recurring smaller incidents become reportable?
Yes.
Recurring incidents can collectively become a major incident if the criteria in Regulation 2024/1772 are satisfied, including at least two occurrences within six months with the same apparent root cause and cumulative satisfaction of the major-incident test.
Can a third party submit a DORA report?
Yes, reporting procedures allow third-party submission arrangements, but the financial entity still needs clear governance and proper coordination with its competent authority.
Can significant cyber threats be reported before an incident occurs?
Yes.
DORA permits voluntary notification of significant cyber threats when the financial entity considers them relevant to the financial system, service users, or clients.
Must clients also be informed?
Where a major ICT incident affects clients’ financial interests, DORA requires the financial entity to inform affected clients without undue delay and explain mitigation measures.
Final Takeaway
A strong DORA incident-reporting process is not a document created for an annual compliance audit.
It is an operational decision system.
The organization needs to move quickly through:
detect → establish awareness → assess critical services → classify → notify → investigate → update → close
while maintaining reliable evidence throughout the incident.
The essential deadlines are:
4 hours from major classification
24 hours from awareness
72 hours after initial notification
1 month for final reporting
But the hardest work happens before any form is submitted.
Financial institutions need:
- critical-function mapping;
- regulatory classification logic;
- reliable timestamps;
- supplier evidence;
- reporting ownership;
- cost tracking;
- client-communication procedures;
- root-cause documentation.
DORA’s first full year of incident reporting has already generated thousands of regulatory submissions across the financial sector, showing that this is a live operational framework rather than a theoretical compliance exercise.
The fastest regulatory report is usually produced by the organization that prepared its decision process before the incident began.
Primary External Sources
For the WordPress version, use this compact source section:
- DORA — Regulation (EU) 2022/2554
- DORA Incident Classification — Delegated Regulation (EU) 2024/1772
- DORA Reporting Deadlines — Delegated Regulation (EU) 2025/301
- DORA Reporting Templates — Implementing Regulation (EU) 2025/302
- ESAs First DORA Major-Incident Report — June 2026
- EBA Risk Assessment Report — June 2026
These should be your principal references rather than generic compliance blogs.
