| 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%. |
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
Chris Ekai is a Risk Management expert with over 10 years of experience in the field. He has a Master’s(MSc) degree in Risk Management from University of Portsmouth and is a CPA and Finance professional. He currently works as a Content Manager at Risk Publishing, writing about Enterprise Risk Management, Business Continuity Management and Project Management.