DORA Incident Response Governance: Enterprise Guide

DORA's incident management chapter, primarily Articles 17 to 23, creates a uniform framework for identifying, classifying, and reporting major ICT-related incidents across EU financial services. Before DORA, incident reporting obligations were fragmented: the Network and Information Security Directive (NIS) applied to some entities, sectoral rules applied to others, and national requirements varied significantly across member states. DORA replaced that patchwork for financial entities in scope with a single, consistent framework.

The regulatory technical standards (RTS) on incident classification, Commission Delegated Regulation (EU) 2024/1772, set out the criteria and thresholds for determining whether an ICT incident qualifies as major and therefore triggers reporting obligations. Article 18(1) and the RTS require evaluation across six dimensions: the number and relevance of clients or counterparties affected; the duration of disruption; geographic spread, particularly where more than two member states are affected; data losses affecting availability, authenticity, integrity or confidentiality; criticality of the services affected; and economic impact in both absolute and relative terms. Meeting materiality thresholds across these dimensions triggers the major incident classification and starts the reporting clock. For large organisations, that classification decision is itself a governance challenge.

The scale of DORA's incident reporting framework became apparent quickly after applicability. The EBA reported receiving more than 1,200 major ICT incident reports in the first four months of 2025 alone, affecting primarily IT systems, payment services, and online banking. ECB Banking Supervision data for the full year 2025 showed that 38% of major incidents reported by directly supervised banks had IT change (system updates, migrations, and configuration changes) as their root cause, underscoring that major incident classification is not limited to cyberattacks and that classification governance must be embedded in change management processes as well as crisis response procedures. 

The 4-hour initial notification deadline runs from the point at which an incident is classified as major, not from the point at which it is first detected. DORA Article 19 sets out the reporting obligation, with specific time limits established under Article 20 and the implementing technical standards. The deadline starts on classification. This distinction matters for governance design.

In practice, there is a period between incident detection and formal classification during which technical teams are assessing severity. The RTS classification criteria require an evaluation across multiple dimensions. A large institution's incident response procedure must define who has authority to make the major incident declaration, what evidence threshold is required, and what escalation path applies if that authority is unavailable. Delay in making the classification decision, because the authority is unclear or the assessment process is protracted, directly compresses the time available to prepare the initial notification.

The implication is that classification authority cannot sit exclusively with a technical team that has no sight of the regulatory reporting obligation. Equally, it cannot sit with a compliance team with no real-time access to the technical picture. Effective governance requires a defined handoff point: a structured moment at which the technical incident commander and the regulatory compliance function jointly confirm classification and trigger the notification chain.

The table below maps the four DORA reporting stages to ownership, triggers, and required outputs within a large financial institution. The EBA joint technical standards on major incident reporting confirm the time limits: initial notification no later than 4 hours from classification (24 hours from first awareness), intermediate report within 72 hours, and final report within one month. 

The Board Notification Obligation

DORA Article 17(1) requires financial entities to have in place an ICT-related incident management process. Article 5(2) requires the management body to approve and oversee the entity's ICT risk management framework. Under Article 17(3)(e), the incident management process must 'inform the management body of at least major ICT-related incidents, explaining the impact, response and additional controls to be established as a result of such ICT-related incidents.' In practical terms, this means the management body notification must happen in parallel with, or immediately prior to, the initial supervisory notification. It is not a post-incident debrief obligation.

Article 17(3)(e) establishes a two-tier internal notification obligation: major incidents must first be reported to relevant senior management, and the management body must separately be informed. For large institutions with executive committees sitting below board level, the governance design must define both notification steps before an incident occurs: who constitutes relevant senior management for this purpose, and which body constitutes the management body under Article 5. The two steps are distinct governance obligations and must each be documented separately in the incident response procedure.

For large institutions with board committees and delegated risk oversight structures, the governance question is: which body receives the initial notification, the full board, the risk committee, or an executive subcommittee? The answer depends on each entity's governance framework, but DORA's management body obligation under Article 5 refers to the body with ultimate responsibility for the ICT risk management framework. Briefing only an executive committee where the board has not delegated ICT risk oversight would not satisfy the obligation. Legal and governance advisers should clarify the structure before a major incident occurs.

Multi-Entity and Cross-Jurisdictional Incidents

For financial groups operating multiple entities across EU member states, or operating in both the EU and the UK, a single ICT incident affecting shared infrastructure creates parallel reporting obligations that are not synchronised by DORA. Each legal entity with its own competent authority has its own 4-hour notification deadline from the point that entity classifies the incident as major. The entity-level obligation does not pause to await group-level coordination.

This creates three governance challenges for large groups:

1. Multiple entities may classify the same underlying incident at different times, creating staggered notification deadlines that run concurrently across different competent authorities.
2. Competent authorities in different member states may have different preferred notification formats or supplementary requirements, requiring parallel document preparation under time pressure.
3. Internal communication between entities, particularly where legal entity boundaries restrict information sharing, must be planned in advance and not improvised during an active incident.

The practical solution is a group incident management protocol that defines a 'major incident trigger point' applicable to the group as a whole, initiates entity-level classification assessments simultaneously, and runs parallel notification preparation tracks under central coordination. The group compliance function coordinates but does not absorb entity-level notification responsibility.

The period between major incident classification and submission of the final report, which may span one month, is the period during which the institution is most exposed to reputational, regulatory, and operational risk simultaneously. Internal communication governance during this window is frequently underplanned.

What the Management Body Needs at Each Stage

The information provided to the management body at initial notification (within 4 hours of classification) will necessarily be incomplete. DORA does not require the institution to have a full root cause analysis at that stage. The supervisory framework acknowledges that initial assessments are provisional. The management body briefing must, however, include:

1. Confirmation that the incident has been classified as major and the classification basis
2. The ICT services and functions affected
3. A preliminary assessment of client, counterparty, or market impact
4. The incident response actions underway and the identity of the incident commander
5. The regulatory notification timeline and who owns each stage

The intermediate report (within 72 hours) provides an opportunity to update the management body with a more developed picture. Board-level remediation discussion is the work of the final report stage (within one month); during the acute incident phase, executive focus should remain on containment and continuity.

Communication Security and Audit Trail

Internal communications about a major ICT incident, particularly communications with the management body, will be subject to supervisory review if the competent authority conducts a post-incident examination. DORA Article 20 establishes the harmonisation framework for incident reporting, with competent authorities using incident reports as inputs to supervisory oversight. Institutions should ensure that board briefings and internal escalation communications are documented, version-controlled, and retained in a way that demonstrates the governance chain operated correctly. This is evidence that the management body fulfilled its obligations under Article 17.

Based on the design of DORA's incident management framework, and the governance challenges organisations faced implementing equivalent obligations under the EBA Guidelines on ICT and Security Risk Management before DORA, several failure patterns are predictable in large institutions:

1. Classification authority is unclear: technical incident commanders do not know they have the power to make the major incident declaration, and await escalation from management while the notification clock runs.
2. Compliance and technology functions operate on different incident management platforms with no real-time integration, creating information lag between the technical picture and the regulatory notification.
3. Board notification procedures assume working hours. Major incidents do not, and the 4-hour window does not accommodate an overnight delay pending a board meeting.
4. Multi-entity groups have entity-level procedures but no overarching group protocol, meaning parallel notification obligations are discovered reactively rather than managed proactively.
5. Notification templates are drafted for the competent authority audience rather than the management body. The internal briefing document and the supervisory notification should be different artefacts with different levels of technical detail.