DORA Incident Reporting 2026: Timeline, Classification and Evidence
DORA incident reporting in 2026: 4h after classification, 24h detection ceiling, 72h intermediate report, 1-month final report and a full evidence workflow.
In this article ↓
- What must be reported
- Who reports
- Major incident classification
- The timestamp problem
- Initial notification
- Intermediate report
- Final report
- Operating workflow
- Vendor incidents
- Common mistakes
- One-hour tabletop scenario
- FAQ
- What is the DORA incident reporting deadline in 2026?
- Does every ICT incident need to be reported?
- Who reports a major ICT-related incident?
- Are significant cyber threats mandatory to report?
- Do reporting channels differ by country?
- Related reading
- Primary sources
Last reviewed: 29 April 2026
DORA incident reporting is now an operating requirement, not a future design task. The Joint Technical Standards on major incident reporting are published in the Official Journal and apply from 12 March 2025. In 2026, financial entities need to show that classification, escalation, reporting and evidence capture work under time pressure.
The practical timeline for a major ICT-related incident is:
| Stage | Timing | What starts the clock |
|---|---|---|
| Initial notification | Within 4 hours after classification as major, and no later than 24 hours after detection/awareness | Classification timestamp and detection/awareness timestamp |
| Intermediate report | At the latest within 72 hours from the initial notification | Initial notification submission |
| Further intermediate updates | When status changes materially or regular activities recover where relevant | Material status change / recovery event |
| Final report | No later than 1 month from the latest intermediate report | Latest intermediate report |
| Significant cyber-threat notification | Voluntary | Entity decision to notify |
The key DORA incident reporting problem is not memorising the numbers. It is producing a defensible classification decision quickly enough to make the timeline feasible.
What must be reported
DORA Article 19 requires financial entities to report major ICT-related incidents to the relevant competent authority. Significant cyber threats may be notified voluntarily.
| Event type | Mandatory? | Reporting route | Main decision |
|---|---|---|---|
| ICT-related incident | Not every incident is externally reportable | Internal incident process | Does it meet major incident criteria? |
| Major ICT-related incident | Yes | Relevant competent authority | Submit initial, intermediate and final reports |
| Significant cyber threat | Voluntary | Relevant competent authority where the entity chooses to notify | Is notification useful and proportionate? |
| Third-party ICT incident | Not automatically reported by the vendor to the authority | Vendor notifies/supports the financial entity under contract | Does the impact make it major for the financial entity? |
The financial entity remains responsible for reporting even if a third party supports or submits the report on its behalf.
Who reports
| Actor | Role in DORA incident reporting |
|---|---|
| Financial entity | Primary reporting obligation to the relevant competent authority |
| Competent authority | Receives reports through national or sector-specific submission channels |
| ICT third-party provider | Notifies and assists the financial entity under Article 30 contractual duties |
| Outsourced reporting provider | May submit on behalf of the financial entity under Article 19(5), but responsibility remains with the financial entity |
| Management body | Oversees ICT risk, material incidents and remediation decisions |
Submission channels can vary by competent authority and Member State. A fintech operating in Latvia, Lithuania, Sweden, Denmark, Cyprus or Ireland should confirm the local portal/process before an incident occurs.
DORA by competent authority
DORA applies as EU law, but day-to-day reporting, evidence and supervisory dialogue runs through your National Competent Authority (NCA). Pick the jurisdiction-specific guide that matches your authorisation:
| Jurisdiction | DORA competent authority | Guide |
|---|---|---|
| Cyprus | CBC | Cyprus guide → |
| Denmark | Finanstilsynet | Denmark guide → |
| Estonia | Finantsinspektsioon | Estonia guide → |
| France | ACPR | France guide → |
| Germany | BaFin | Germany guide → |
| Ireland | Central Bank of Ireland | Ireland guide → |
| Italy | Banca d'Italia | Italy guide → |
| Latvia | Latvijas Banka | Latvia guide → |
| Lithuania | Lietuvos bankas | Lithuania guide → |
| Luxembourg | CSSF | Luxembourg guide → |
| Malta | MFSA | Malta guide → |
| Netherlands | DNB | Netherlands guide → |
| Sweden | Finansinspektionen | Sweden guide → |
See the DORA National Competent Authorities selected-jurisdictions hub for the full directory and the difference between NCAs and the EU ESAs (EBA, ESMA, EIOPA).
Major incident classification
Major-incident classification follows Commission Delegated Regulation (EU) 2024/1772. The classification process should be embedded into the incident runbook and used during drills.
| Classification area | Evidence to collect fast |
|---|---|
| Critical services affected | Which critical or important function is impacted |
| Clients affected | Number/type of clients, users or counterparties affected |
| Transactions affected | Volume, value and service impact |
| Duration / downtime | Start time, recovery time, degraded-service period |
| Geographical spread | Member States, branches, customers or jurisdictions affected |
| Data losses | Confidentiality, integrity, availability and authenticity impact |
| Economic impact | Direct and indirect costs where known |
| Reputational impact | Complaints, media, public visibility, partner-bank concerns |
| Recurrence | Related incidents with common root cause |
The classification record should explain why the incident is major or not major. A bare severity label is weak evidence.
The timestamp problem
Two timestamps matter for the initial notification:
| Timestamp | Why it matters |
|---|---|
| Detection / awareness time | Sets the outer 24-hour ceiling for the initial notification |
| Major classification time | Starts the 4-hour clock after classification |
Many firms record "incident opened" but not "aware of incident" or "classified as major". That creates reporting risk. The incident record should keep detection, awareness, classification, escalation, notification, recovery and closure as separate timestamps.
Initial notification
The initial notification is not expected to contain a perfect root-cause analysis. It should give the competent authority enough early information to understand the incident, affected services and preliminary impact.
| Initial notification input | Practical source |
|---|---|
| Entity identification | Legal/compliance records |
| Incident reference | Incident management system |
| Detection and classification timestamps | Incident timeline |
| Incident type and nature | Technical triage |
| Affected services/functions | Service map and critical function inventory |
| Preliminary impact | Operations, customer support, payment ops, engineering |
| Business continuity / disaster recovery activation | Crisis or continuity lead |
| Third-party involvement | Vendor owner and supplier records |
Intermediate report
The intermediate report updates the competent authority after the initial notification. The first intermediate report is due at the latest within 72 hours from the initial notification. Further updates may be required where status changes materially or regular activities recover.
| Intermediate report focus | Evidence |
|---|---|
| Updated impact | Client, transaction, service and data impact |
| Current status | Ongoing, contained, recovered, workaround in place |
| Root-cause hypothesis | Engineering/security investigation |
| Actions taken | Containment, recovery, communications, vendor escalation |
| Critical function impact | Business owner assessment |
| Third-party role | Supplier updates and commitments |
| Expected next steps | Remediation, monitoring and next update |
Final report
The final report closes the regulatory reporting cycle. It should explain what happened, why it happened, what impact occurred and what the entity changed as a result.
| Final report focus | Evidence |
|---|---|
| Root cause | Technical and process analysis |
| Full impact | Clients, transactions, data, financial and operational impact |
| Timeline | Detection, classification, reporting, recovery and closure |
| Remediation | Actions completed and actions still open |
| Lessons learned | Control, policy, vendor and training changes |
| Management review | Escalation and management-body reporting evidence |
| Risk/control updates | Updated risk register, control map and testing plan |
Operating workflow
| Step | Owner | Output |
|---|---|---|
| Detect event | Engineering / SOC / provider | Alert or incident ticket |
| Start incident record | Incident manager | Timeline and initial facts |
| Triage severity | Security / technology | Preliminary severity |
| Assess DORA criteria | ICT risk owner / compliance / incident manager | Major / not major decision |
| Escalate if major | Incident manager | Management and compliance notification |
| Prepare initial notification | Compliance with technical input | Draft report |
| Submit via authority channel | Authorised reporter | Submission evidence |
| Maintain updates | Incident manager | Intermediate report inputs |
| Close and learn | Incident owner / management | Final report and remediation tracker |
For smaller fintechs, this can be lightweight. It cannot be informal.
Vendor incidents
Many DORA incidents start outside the financial entity: cloud outage, payment processor disruption, SaaS breach, managed service failure or outsourced support failure. Vendor contracts need to make incident reporting possible.
| Vendor contract point | Why it matters |
|---|---|
| Prompt notification of ICT incidents | Financial entity may need to classify within hours |
| Impact information | Classification requires affected services, duration and data impact |
| Cooperation with reporting | Entity needs facts for initial/intermediate/final reports |
| Subcontractor incident flow | Incidents may originate below the direct provider |
| Post-incident report | Final DORA report needs root cause and remediation |
| Testing and exercises | Supplier readiness should be tested before a real incident |
Article 30 contract clauses should support the incident workflow, not sit separately in legal files.
Common mistakes
| Mistake | Why it creates risk | Fix |
|---|---|---|
| One timestamp only | 4h and 24h clocks cannot be proven | Record detection, awareness and classification separately |
| Legal joins too late | Reporting path starts after technical recovery begins | Include compliance in incident escalation thresholds |
| Vendor facts arrive slowly | Classification lacks impact evidence | Contract for rapid supplier notification and cooperation |
| Final report is only root cause | Lessons learned and remediation are missed | Include impact, controls, management review and remediation |
| Significant cyber threats treated as mandatory | Over-reporting and process confusion | Keep voluntary threat-notification path separate |
| Local portal unknown | Deadline can be missed during access setup | Confirm authority channel and authorised users in advance |
One-hour tabletop scenario
Use this simple drill to test readiness:
| Minute | Inject | Expected output |
|---|---|---|
| 0 | Payment service outage detected | Incident record opened; awareness timestamp captured |
| 10 | Processor confirms degraded service across two countries | Supplier incident path activated |
| 20 | Customer complaints and failed transactions increase | Impact assessment begins |
| 30 | Critical function impact likely | DORA classification decision made or escalated |
| 40 | Incident classified as major | 4-hour initial notification clock recorded |
| 50 | Draft notification prepared | Owner and submission path confirmed |
| 60 | Management update prepared | Decisions, gaps and next steps captured |
The goal is not to finish the entire report in one hour. The goal is to prove that ownership, facts, timestamps and authority route are clear.
FAQ
What is the DORA incident reporting deadline in 2026?
For major ICT-related incidents, the initial notification is due within 4 hours after classification as major and no later than 24 hours after detection/awareness. The first intermediate report is due at the latest within 72 hours from the initial notification. The final report is due no later than 1 month from the latest intermediate report.
Does every ICT incident need to be reported?
No. DORA requires reporting of major ICT-related incidents. Other ICT incidents should still be logged, classified and reviewed internally.
Who reports a major ICT-related incident?
The financial entity reports to its relevant competent authority. A third party may support reporting or submit on behalf of the entity under an outsourced arrangement, but the financial entity remains responsible.
Are significant cyber threats mandatory to report?
No. Significant cyber-threat notification under DORA is voluntary.
Do reporting channels differ by country?
Yes. DORA creates an EU framework, but competent authority submission channels and access procedures may vary. Confirm the local route before an incident occurs.
Related reading
- DORA Requirements in 2026: Operating Controls and Evidence Checklist
- DORA Business Continuity and Disaster Recovery: Articles 11-12 Roadmap for 2026
- DORA Register of Information: 2026 Guide for ICT Third-Party Risk
- DORA National Competent Authorities — selected jurisdictions hub
- 7 DORA Compliance Mistakes EU Financial Firms Still Need to Fix in 2026