DORA Incident Classification and Reporting: Timelines and Templates

Key Takeaways

DORA mandates a structured four-stage incident reporting process: initial notification (4 hours from classification), initial report (24 hours from detection), intermediate report (72 hours), and final report (1 month after resolution).

Incident classification hinges on six materiality criteria defined in Delegated Regulation (EU) 2024/1772, including client impact, economic loss exceeding EUR 100,000, service duration, geographical spread, data losses, and criticality of affected services.

An ICT incident becomes reportable as major when it affects critical or important functions AND meets the data-loss threshold or at least two other materiality thresholds simultaneously.

The European Supervisory Authorities (ESAs) require all reports in standardised XML format under ITS 2025/302, with qualified electronic certificates (eIDAS) for submission.

Financial entities must maintain an incident register, conduct root-cause analysis within the final report, and retain records for at least five years for supervisory review.

DORA applies as lex specialis over NIS2 for financial entities, but coordination between both reporting regimes remains essential to avoid duplication.

A structured 90-day implementation roadmap helps organisations move from gap analysis to tested, production-ready incident reporting capabilities.

The European Union Agency for Cybersecurity (ENISA) analysed 488 publicly reported cyber incidents targeting European financial institutions between January 2023 and June 2024, with banks accounting for 46% of all attacks.

Against that backdrop, the Digital Operational Resilience Act (DORA) went live on 17 January 2025, introducing the most prescriptive ICT incident reporting requirements the financial sector has ever faced.

DORA replaces a patchwork of national reporting rules with a single, harmonised framework.

Every bank, insurer, investment firm, payment institution, and crypto-asset service provider operating in the EU must now classify ICT-related incidents against defined materiality thresholds and report major incidents to competent authorities within strict deadlines.

The penalties for non-compliance are substantial, and supervisors have signalled that enforcement will be proactive.

This compliance guide breaks down the DORA incident classification criteria, walks through the four-stage reporting timeline step by step, provides ready-to-use templates, and delivers a 90-day roadmap to get your incident management process production-ready.

Along the way, you will find actionable tables, KRI thresholds, and pitfalls drawn from early adopter experience.

Understanding the DORA Incident Management Framework

DORA Article 17 establishes the overarching obligation: financial entities must implement an ICT risk management framework that includes capabilities for detecting, managing, and reporting ICT-related incidents. The framework rests on two reporting tracks.

Mandatory reporting covers major ICT-related incidents. Once an entity classifies an incident as major, the clock starts ticking on a four-stage notification sequence to the relevant competent authority.

Voluntary notification applies to significant cyber threats. Entities may choose to report threats that have not yet materialised into incidents but carry high potential impact. The ESAs encourage voluntary reporting to strengthen cross-border threat intelligence sharing.

DORA operates as lex specialis relative to NIS2 for financial entities. That means DORA’s incident reporting requirements take precedence, but entities still need to coordinate with NIS2 obligations where overlapping services exist.

A clear compliance risk assessment mapping DORA to NIS2 touchpoints should be part of every compliance programme.

Framework Element	DORA Requirement	Reference
ICT incident management process	Detect, classify, manage, report all ICT incidents	Article 17
Major incident reporting	Mandatory four-stage reporting to competent authority	Article 19
Voluntary threat notification	Encouraged for significant cyber threats	Article 19(2)
Incident register	Maintain log of all ICT incidents with root-cause data	Article 17(3)
Lessons learned	Post-incident review and corrective action tracking	Article 17(4)
Record retention	At least five years for supervisory review	Article 17(3)

DORA Incident Classification: The Six Materiality Criteria

Delegated Regulation (EU) 2024/1772 codifies the criteria and materiality thresholds that determine whether an ICT-related incident qualifies as major.

Classification is not subjective; the regulation prescribes quantitative thresholds for each criterion. A thorough risk assessment process underpins accurate and timely classification.

Primary Gate: Criticality of Services Affected

Before evaluating materiality thresholds, the entity must confirm that the incident affects critical or important functions.

An incident qualifies for major classification consideration when it affects ICT services or network and information systems supporting critical business functions, affects financial services requiring authorisation or registration, or constitutes a successful, malicious, and unauthorised access to the entity’s network and information systems.

Materiality Thresholds

Once the primary gate is satisfied, the incident is classified as major if the data-loss or unauthorised-access threshold alone is met, or at least two of the remaining five criteria thresholds are breached simultaneously.

Criterion	What It Measures	Materiality Threshold	Evidence Required
Clients, counterparts & transactions	Breadth of impact on customers and financial markets	Exceeds 10% of all clients using the affected service, or affects clients above entity-defined significance threshold	Client impact registers, transaction logs
Economic impact	Direct and indirect financial losses from the incident	Costs and losses exceed or are likely to exceed EUR 100,000	Cost tracking logs, loss estimates, insurance claims
Duration & service downtime	Length of disruption to critical services	Service downtime exceeds 2 hours for critical functions, or 24 hours for important functions	Service monitoring logs, SLA breach records
Geographical spread	Cross-border or multi-jurisdiction impact	Incident affects operations in two or more EU Member States	Jurisdiction mapping, affected-entity register
Data losses	Compromise of confidentiality, integrity, or availability	Any confirmed breach of confidentiality or integrity of data supporting critical functions	Forensic reports, data-loss event logs
Criticality of services	Importance of disrupted functions to financial stability	Disruption to services identified as critical in the entity’s BIA or operational resilience mapping	BIA documentation, service criticality register

DORA Incident Reporting Timelines: The Four-Stage Process

The EBA’s technical standards on major incident reporting prescribe four sequential reporting stages. Each stage has a defined deadline, content requirement, and submission format. Missing any deadline exposes the entity to supervisory action.

Stage	Deadline	Content Requirements	Submission Format
1. Initial Notification	Within 4 hours of classifying the incident as major (no later than 24 hours from detection)	Incident identifier, classification rationale, affected services, preliminary impact estimate, whether the incident is ongoing	XML via national competent authority portal (ITS 2025/302), authenticated with eIDAS-qualified certificate
2. Intermediate Report	Within 72 hours of submitting the initial notification	Updated impact assessment, root-cause hypothesis, affected clients and counterparts count, containment measures taken, estimated time to resolution	Same XML schema, incremental update to the initial submission
3. Updated Intermediate Report(s)	As material new information emerges before the final report	Revised impact data, corrective actions underway, any escalation to other authorities or cross-border notifications	Same XML schema, versioned updates
4. Final Report	Within 1 month of submitting the latest intermediate report	Confirmed root cause, total impact metrics, lessons learned, corrective and preventive actions (CAPA), any changes to risk appetite or control design	Same XML schema, final closure submission

Weekend and Holiday Relief

Only significant or systemically important institutions must submit notifications during non-working days.

All other regulated entities get relief: any deadline falling on a non-working day is pushed to 12:00 pm on the next working day.

Build this logic into your operational resilience playbook so on-call teams know exactly when the clock pauses.

DORA Incident Report Content Template

The ITS 2025/302 prescribes standardised XML fields for every reporting stage. The table below translates those fields into a practical checklist that your incident response team can use during a live incident.

Map each data element to an internal owner so there are no gaps under pressure.

Data Element	Description	Stage Required	Responsible Role
Incident reference ID	Unique identifier assigned by the entity at detection	Stage 1	Incident Manager
Date and time of detection	Timestamp when the entity first became aware	Stage 1	SOC / NOC Analyst
Date and time of classification	Timestamp when the incident was classified as major	Stage 1	Risk / Compliance Officer
Classification rationale	Which materiality thresholds were breached, with supporting data	Stage 1	Risk / Compliance Officer
Affected services and functions	List of impacted critical or important functions mapped to the BIA	Stage 1	Business Continuity Manager
Estimated number of affected clients	Count or percentage of clients impacted	Stage 1-2	Operations / Client Services
Geographical scope	Member States and jurisdictions affected	Stage 1-2	Legal / Compliance
Containment measures	Actions taken to limit spread and restore services	Stage 2	IT Operations / CISO
Root-cause hypothesis	Preliminary technical finding on the cause	Stage 2	IT Security / Forensics
Confirmed root cause	Final validated cause supported by forensic evidence	Stage 4	IT Security / Forensics
Total economic impact	Aggregated costs and losses (direct + indirect)	Stage 4	Finance / Risk
Lessons learned	Post-incident review findings and improvement actions	Stage 4	Risk Committee
CAPA actions	Corrective and preventive actions with owners and deadlines	Stage 4	Risk / Compliance Officer

Voluntary Reporting of Significant Cyber Threats

DORA Article 19(2) allows financial entities to voluntarily notify competent authorities of significant cyber threats, even before they materialise into incidents.

Participation strengthens the collective defence posture by feeding threat intelligence into the ESA cross-border sharing mechanism.
Entities with mature cybersecurity KRI programmes are best positioned to identify reportable threats early.

Element	Guidance	Example
Threat description	Technical summary of the threat vector, TTP mapping to MITRE ATT&CK where possible	Targeted spear-phishing campaign exploiting zero-day in financial messaging middleware
Potential impact	Estimated scope if the threat were to materialise, mapped to BIA criticality tiers	Could disrupt SWIFT settlement processing for 48+ hours across three Member States
Indicators of compromise (IOCs)	Hash values, IP ranges, domain names, malware signatures	SHA-256: abc123…, C2 server: 192.168.x.x
Mitigating actions taken	Containment or hardening steps already implemented	Blocked IOCs at perimeter, patched middleware, notified SWIFT ISAC

Key Risk Indicators for DORA Incident Reporting Readiness

Supervisors expect financial entities to demonstrate ongoing monitoring of their incident reporting capability, not just compliance at the point of audit.

A well-designed KRI dashboard should track leading indicators that predict reporting failures before they happen. The following KRIs align with ISO 31000 principles and DORA-specific expectations.

KRI	Green	Amber	Red	Data Source
Mean time to classify (MTTC)	< 2 hours	2-4 hours	> 4 hours	Incident management system
Initial notification on-time rate	> 98%	90-98%	< 90%	Regulatory filing tracker
Intermediate report on-time rate	> 95%	85-95%	< 85%	Regulatory filing tracker
Final report on-time rate	> 95%	85-95%	< 85%	Regulatory filing tracker
Incident register completeness	> 99%	95-99%	< 95%	Quarterly register audit
Drill/exercise completion rate	100% per year	1 missed	2+ missed	BCM exercise log
Root-cause analysis turnaround	< 3 weeks	3-4 weeks	> 4 weeks	Post-incident tracker
Open CAPA ageing	< 30 days avg.	30-60 days	> 60 days	CAPA register

90-Day Implementation Roadmap

Building a DORA-compliant incident reporting capability does not happen overnight, but it does not need to take a year either. The roadmap below sequences activities into three 30-day phases, moving from gap analysis through process design to live testing.

Each phase maps to deliverables and measurable success metrics. Pair this roadmap with your risk management lifecycle to ensure incident reporting is embedded, not bolted on.

Phase	Actions	Deliverables	Success Metrics
Days 1-30: Gap Analysis & Governance	Map current incident processes against DORA Articles 17-19 and Delegated Regulation 2024/1772. Identify classification criteria gaps. Assign RACI for each reporting stage. Review existing BIA for critical function alignment.	Gap analysis report with prioritised remediation items. Updated RACI matrix. Incident classification decision tree (draft). Regulatory mapping (DORA vs NIS2 vs sector-specific rules).	100% of critical functions mapped to DORA classification criteria. RACI approved by CRO/CISO. Gap report presented to risk committee.
Days 31-60: Process Design & Tooling	Design four-stage reporting workflow with escalation paths. Configure incident management tooling for XML report generation (ITS 2025/302). Build report templates pre-populated with entity-specific data. Establish eIDAS certificate for submission. Define KRI thresholds and dashboard.	Incident reporting playbook (v1). Configured tooling with XML export capability. Report templates (initial, intermediate, final). KRI dashboard (draft). Weekend/holiday relief procedures.	Playbook reviewed by legal and compliance. XML test submissions accepted by sandbox (where available). All report templates validated against ITS schema.
Days 61-90: Testing & Go-Live	Run tabletop exercise simulating a major ICT incident end-to-end. Test classification decision tree with three scenario variants. Validate report submission workflow including eIDAS authentication. Conduct lessons-learned session and refine playbook. Train front-line SOC/NOC staff and business continuity teams.	Exercise report with observations and corrective actions. Final playbook (v2) incorporating exercise findings. Training completion records. Supervisory readiness pack for competent authority engagement.	Tabletop exercise completed with all RACI stakeholders. Mean time to classify under 2 hours in exercise. All corrective actions assigned owners and deadlines. Staff training completion > 95%.

DORA Incident Classification and Reporting: Questions Practitioners Ask

What is DORA incident classification and reporting?

DORA incident classification and reporting is the framework in Articles 17-19 of the EU’s Digital Operational Resilience Act that requires financial entities to detect, classify, and report ICT-related incidents. Firms must judge each incident against defined materiality thresholds and report any major incident to their competent authority on a strict four-stage timeline.

Who must comply with DORA incident reporting, and since when?

Every bank, insurer, investment firm, payment institution, and crypto-asset service provider operating in the EU must comply, and the rules have applied since 17 January 2025. DORA replaced a patchwork of national reporting regimes with one harmonised standard. US firms are caught wherever they run EU-authorised entities, and supervisors have signalled that enforcement will be proactive.

What are the DORA incident reporting deadlines?

DORA incident reporting runs on four stages. The initial notification is due within 4 hours of classifying an incident as major, and no later than 24 hours after detection; the intermediate report within 72 hours; further updates as material facts emerge; and the final report within one month of the last intermediate report.

What are the six materiality criteria for DORA incident classification?

Delegated Regulation (EU) 2024/1772 sets six criteria: clients and transactions affected (over 10%), economic impact above EUR 100,000, service downtime (over 2 hours for critical functions), geographical spread across two or more Member States, data losses, and the criticality of the disrupted services. These thresholds make DORA incident classification quantitative rather than subjective.

When is an ICT incident classified as ‘major’ under DORA?

An incident is major when it first passes a primary gate, affecting critical or important functions or involving malicious unauthorised access. It then qualifies if the data-loss threshold is met on its own, or if at least two of the remaining five materiality criteria are breached at the same time. Otherwise it is not classified as major.

What format must DORA incident reports use?

All DORA incident reports must be filed in a standardised XML format under the implementing technical standards (ITS 2025/302) through the national competent authority’s portal.

Each submission must be authenticated with an eIDAS-qualified electronic certificate. The same schema is reused across the initial, intermediate, and final stages as incremental, versioned updates.

How does DORA incident reporting relate to NIS2?

For financial entities, DORA acts as lex specialis over NIS2, so its incident reporting rules take precedence. Firms still need to coordinate with NIS2 where services overlap, mapping shared fields to avoid duplicate filings.

A single workflow with branching logic for both regimes keeps legal and compliance teams from double-handling the same incident.

What incident records must firms keep under DORA, and for how long?

Under Article 17, firms must maintain an incident register that logs every ICT incident with root-cause data, and retain those records for at least five years for supervisory review.

The final report must confirm the root cause, total impact, lessons learned, and corrective actions. Supervisors expect a closed feedback loop, not a filed-and-forgotten log.

Common Pitfalls and How to Avoid Them

Early adopters of DORA incident reporting have surfaced recurring failure patterns. The pitfalls below draw on supervisory feedback and practitioner experience across the EU banking and insurance sectors.

A proactive risk register should track these as operational risk events.

Pitfall	Root Cause	Remedy
Classification paralysis: teams debate severity instead of filing	No decision tree; classification criteria not translated into operational language	Build a binary decision flowchart with clear yes/no gates for each materiality threshold. Pre-assign a classification owner with authority to escalate.
Missed 4-hour window for initial notification	Detection and classification treated as one step; no separation of duties between SOC and risk	Separate detection (SOC alerts) from classification (risk/compliance). Automate classification-trigger alerts to compliance team at detection + 2 hours.
Incomplete intermediate reports	Incident data scattered across siloed tools (SIEM, ITSM, email)	Centralise incident data in a single platform with pre-built fields mapped to ITS 2025/302 XML schema. Run weekly data-quality audits.
Final reports filed without root-cause analysis	Forensic investigation runs longer than the 1-month deadline; no interim sign-off process	Set a root-cause hypothesis deadline at Day 14. If full forensics are incomplete, file a qualified final report with a clear follow-up timeline.
Duplicate reporting under DORA and NIS2	No regulatory mapping; legal and compliance teams operate independently for each regime	Create a single incident reporting workflow with branching logic for DORA and NIS2. Map overlapping fields to avoid double-handling.
Weekend incidents go unreported for 48+ hours	On-call teams unaware of weekend relief rules and which entity categories must still file	Publish a clear weekend/holiday decision matrix. Train on-call teams quarterly. Automate deadline calculators that factor in non-working days.
Record retention gaps in incident register	Manual logging; no automated capture of timestamps, classifications, and actions	Implement automated audit trails in the incident management system. Run quarterly completeness checks against the five-year retention requirement.
No lessons-learned loop after final report	Post-incident review seen as optional; no governance mandate to close the feedback cycle	Make post-incident review a standing agenda item for the risk committee. Track CAPA closure rates as a KRI with board-level visibility.

Looking Ahead: DORA Incident Reporting Trends for 2025-2027

DORA’s incident reporting regime is a living framework. The ESAs have built review mechanisms into the regulation, and supervisory expectations will evolve as data from the first reporting cycles flows in.

Three trends stand out for risk professionals planning beyond initial compliance.

Cross-border threat intelligence sharing will accelerate. DORA’s voluntary cyber threat notification mechanism is a stepping stone toward a pan-EU financial threat intelligence platform. The ESAs have signalled intent to use aggregated incident data to identify systemic vulnerabilities.

Entities that invest in third-party risk management and threat intelligence capabilities now will be ahead of the curve when sharing becomes semi-mandatory in future regulatory cycles.

Supervisory use of incident data will sharpen. Competent authorities will benchmark incident classification consistency across entities.

Outliers, those reporting significantly fewer or more major incidents than peers, will face deeper supervisory scrutiny. Calibrating your classification thresholds against industry norms, supported by a robust RCSA process, reduces the risk of unwelcome supervisory attention.

Automation will become non-negotiable. The 4-hour classification window and XML-based submission requirement push entities toward automated detection-to-classification pipelines.

Manual classification processes will not scale, especially for entities managing high volumes of ICT alerts. Integration between SIEM, incident management, and regulatory reporting platforms will move from nice-to-have to baseline.

Organisations already building enterprise risk management technology stacks that include automated incident workflows will find the transition far smoother.

AI-driven incident triage is emerging. Leading financial institutions are piloting AI-assisted risk assessment tools that pre-classify incidents based on historical patterns and real-time impact data.

While DORA does not mandate AI, the efficiency gains from automated triage against the six materiality criteria will drive adoption. Entities exploring this path should also consider their AI governance framework to ensure the triage models are transparent and auditable.

Ready to build your DORA incident reporting capability? Visit riskpublishing.com/services for consulting support on DORA compliance, incident management frameworks, and operational resilience programme design. Need a conversation first? Contact us here.

References

1. Regulation (EU) 2022/2554 (DORA) – Full Text – European Parliament and Council

2. DORA Article 17 – ICT-Related Incident Management Process – Official DORA Text

3. DORA Article 18 – Classification of ICT-Related Incidents – Official DORA Text

4. Delegated Regulation (EU) 2024/1772 – Classification Criteria and Materiality Thresholds – EUR-Lex

5. Commission Delegated Regulation (EU) 2025/301 – RTS on Incident Reporting – EUR-Lex

6. EBA Joint Technical Standards on Major Incident Reporting – European Banking Authority

7. Final Report on Draft RTS and ITS on Incident Reporting (JC 2024-33) – ESMA

8. ESAs Publish First Set of Rules Under DORA – ESMA Press Release

9. RTS on Classification of ICT-Related Incidents – European Banking Authority

10. ENISA Threat Landscape: Finance Sector (January 2023 – June 2024) – ENISA

11. EIOPA – Digital Operational Resilience Act (DORA) – EIOPA

12. Central Bank of Ireland – Reporting Major ICT-Related Incidents Under DORA – Central Bank of Ireland

13. CSSF – Entry into Application of DORA Regulation – CSSF Luxembourg

14. NIST Cybersecurity Framework 2.0 – National Institute of Standards and Technology

15. ISO 27001 – Information Security Management – International Organization for Standardization