Skip to main content
Readiness Authority
Category: Regulatory & Privacy Compliance

Major ICT-Related Incident Reporting

Also known as: Major ICT Incident Reporting, DORA Major Incident Reporting
Simply put

Under the EU's Digital Operational Resilience Act (DORA), financial entities must tell their supervisory authority when a serious technology-related incident occurs. An incident counts as 'major' when it has a high adverse impact on the network and information systems that support the entity's important business functions. This is a mandatory reporting duty, separate from any insurance obligation, and does not by itself reduce the likelihood or cost of an incident.

Formal definition

A regulatory notification obligation established under DORA whereby financial entities must detect, classify, manage, and notify ICT-related incidents to the relevant competent authority. A 'major ICT-related incident' is defined as an ICT incident that has a high adverse impact on the network and information systems supporting critical or important functions of the financial entity. DORA Article 17 requires entities to define, establish, and implement an ICT-related incident management process to detect, manage, and notify such incidents; incidents meeting the 'major' classification threshold trigger the reporting duty to the supervisory authority, which may act on the basis of the notification. This is a supervisory reporting and operational-resilience requirement, distinct from insurance coverage triggers, sublimits, or claims-notification conditions under a cyber policy; the specific classification thresholds, timelines, and templates are governed by DORA and its implementing measures rather than by any insurer's policy wording.

Why it matters

Major ICT-Related Incident Reporting is a mandatory supervisory obligation, not a form of protection. Under DORA, financial entities operating in the EU must notify their competent authority when an ICT-related incident is classified as major, meaning it has a high adverse impact on the network and information systems supporting critical or important functions. This duty exists to give supervisory authorities visibility into operational disruptions across the financial sector so they can act on the basis of the notification. It does not reduce the likelihood of an incident occurring, nor does it lessen the resulting loss.

For risk and resilience professionals, the significance lies in the interaction between this regulatory duty and other obligations that arise from the same incident. A single technology event may simultaneously trigger a DORA notification to a supervisory authority, a claims-notification condition under a cyber insurance policy, and potentially other regulatory reporting duties. These are distinct obligations with distinct recipients, thresholds, and timelines. Meeting the DORA reporting threshold does not establish that a loss is covered under a cyber policy, and satisfying an insurer's notification condition does not discharge the supervisory reporting duty.

Because the classification thresholds, timelines, and templates are set by DORA and its implementing measures rather than by any insurer, entities must maintain an internal capability to detect and classify incidents against the regulatory criteria. Failure to report a major incident, or to report it correctly and on time, is a supervisory compliance matter that is generally not remedied by insurance. This distinction, between a regulatory reporting failure and an insurable loss, is where firms most often need clear internal ownership and process.

Who it's relevant to

Compliance and legal professionals
Responsible for ensuring the entity meets its DORA notification duties, including correctly classifying incidents as major and reporting to the relevant competent authority within the required timelines. They must treat this as a supervisory compliance obligation distinct from any insurance notification, and confirm the applicable thresholds and templates against current DORA implementing measures.
CISOs and resilience planners
Own the incident management process required under DORA Article 17, the capability to detect, manage, and classify ICT-related incidents. They must build detection and classification against the regulatory 'high adverse impact on critical or important functions' criterion into operational-resilience workflows, recognizing that this reporting duty does not itself reduce incident likelihood or impact.
Risk managers and insurance buyers
Need to map how a single incident may create parallel obligations: a supervisory notification under DORA and a separate claims-notification condition under a cyber policy. They should not assume that meeting the DORA major-incident threshold establishes coverage, nor that a regulatory reporting failure would be covered, and should coordinate internal ownership of both duties.
Insurance brokers and underwriters
Should understand that DORA major-incident reporting is a regulatory obligation independent of policy wording, and that its thresholds and timelines are not coverage triggers. When advising or underwriting EU financial entities, they may assess how an insured's incident management and classification processes function, while keeping regulatory reporting distinct from claims notification and coverage terms.

Inside Major ICT-Related Incident Reporting

Incident Classification and Materiality Thresholds
Criteria used to determine whether an ICT-related incident qualifies as 'major' and therefore triggers a reporting obligation. These typically consider factors such as the number of clients or counterparts affected, the geographical spread, the duration and service downtime, data losses, and the economic impact. The precise thresholds and weighting are defined by the applicable regulatory regime rather than by any insurance policy, and materiality tests can differ across regimes and supervisory authorities.
Reporting Timelines and Phased Submissions
Many regimes structure reporting into phases, such as an initial notification, an intermediate update as the situation develops, and a final report once root cause and remediation are understood. Each phase has its own deadline. The specific time windows and content requirements depend on the governing regulation and should be confirmed against the current applicable rules rather than assumed.
Recipients and Reporting Channels
The competent authorities or supervisory bodies designated to receive reports, and the prescribed format or portal for submission. This is distinct from any notification made to an insurer under a cyber policy; regulatory reporting and insurance claim notice are separate processes with separate recipients, deadlines, and purposes.
Report Content Elements
The substantive information typically required, which may include incident description, affected systems and services, timeline of events, impact assessment, root cause where known, and remediation and recovery actions taken. Content requirements vary by regime and by reporting phase.
Relationship to Incident Response and Crisis Management
Reporting is one output of the broader incident response process and, where escalation is warranted, crisis management. Detecting, classifying, and reporting an incident does not by itself contain or remediate it; reporting is an obligation that runs alongside technical response and business continuity activities, not a substitute for them.

Common questions

Answers to the questions practitioners most commonly ask about Major ICT-Related Incident Reporting.

Is submitting a major ICT-related incident report to a regulator the same as filing a claim with my cyber insurer?
No. Regulatory incident reporting and insurance claim notification are distinct processes with different recipients, purposes, timelines, and consequences. A report to a supervisory authority is a compliance obligation intended to inform oversight and, in some regimes, to enable coordinated response; it does not by itself trigger any coverage. Notification to your insurer is a separate step governed by the policy's conditions, and many policies treat prompt notification as a condition precedent to coverage. Meeting a regulatory deadline does not satisfy your notification obligations to an insurer, and vice versa. You typically need to manage both tracks in parallel, and the wording, content, and audience for each will differ.
Does classifying an incident as 'major' for regulatory reporting mean it will be covered by my cyber policy?
Not necessarily. The threshold that makes an incident 'major' for reporting purposes is a regulatory classification, not a coverage trigger. Whether any resulting loss is covered depends on the specific policy wording, applicable sublimits and retentions, any waiting period for business interruption, and exclusions such as war, infrastructure, or failure-to-maintain-standards provisions. An incident can be reportable yet fall outside coverage, and conversely a covered loss may not meet a regulator's materiality threshold. Treat the regulatory classification and the coverage analysis as separate assessments, each subject to its own criteria.
How do reporting deadlines typically interact with our incident response process?
Reporting deadlines often begin to run from the point of detection or classification rather than from full resolution, so the obligation can arise while the incident is still being investigated and contained. In practice this means incident response and reporting workflows run concurrently: the response team works to contain and understand the event while a designated function assembles and submits the required notifications. Many regimes contemplate a phased approach, an initial notification followed by intermediate and final reports, precisely because complete information is rarely available at the outset. The exact triggers, phases, and clocks depend on the applicable regime and should be confirmed against the specific rules that bind your organization.
Who inside our organization should own the reporting decision and submission?
Ownership is usually shared, and it helps to pre-assign roles before an incident. Technical staff typically supply the facts about scope and impact, but the classification and reporting decision often sits with a compliance, legal, or risk function that understands the applicable thresholds and can weigh regulatory exposure. Crisis management leadership may coordinate across these functions. Because reporting can carry legal consequences, involving legal counsel early is common. Documenting who is authorized to classify an incident and to submit reports, and ensuring those individuals are reachable outside business hours, reduces the risk of missed deadlines.
What should we prepare in advance to meet reporting obligations under time pressure?
Preparation generally includes identifying which regimes and reporting channels apply to your organization, understanding the relevant thresholds and phased timelines, and maintaining current contact details and any required registration for the applicable authorities. Pre-drafted report templates aligned to the required data fields, a decision framework for classifying incidents, and a documented escalation path all help. It is also useful to rehearse these steps through exercises so the reporting workflow is familiar. Note that preparation for regulatory reporting is a compliance and readiness activity; it does not substitute for the separate steps needed to preserve insurance coverage.
How should we align regulatory reporting with insurer notification to avoid prejudicing coverage?
Because both obligations can arise from the same event but serve different ends, coordination matters. Review your policy's notification conditions to understand what triggers the duty to notify the insurer and how quickly it must occur, since delays can, subject to the wording, affect coverage. Consider how information disclosed in a regulatory report may be used, and involve legal counsel on questions of privilege and consistency across submissions. Keeping a clear record of what was reported, to whom, and when supports both tracks. The precise interaction depends on the specific policy wording and the applicable regulatory regime, so confirm the requirements rather than assuming one submission covers the other.

Common misconceptions

Notifying the cyber insurer satisfies the regulatory reporting obligation.
Regulatory incident reporting and insurance claim notification are distinct. Reporting to a supervisory authority does not constitute notice to an insurer, and notice to an insurer does not discharge any regulatory duty. Each has its own recipients, deadlines, and content requirements, and failing one does not excuse the other. Practitioners should treat them as parallel, independent obligations.
Every ICT incident must be reported as a major incident.
Only incidents meeting the defined materiality or classification thresholds typically trigger the major-incident reporting obligation. Lesser incidents may fall under different, lighter, or no reporting requirements depending on the regime. Because thresholds differ across regulatory regimes and supervisory authorities, the classification test must be applied against the specific applicable rules.
Submitting the required reports means the incident is resolved.
Reporting is a compliance and transparency mechanism, not a remediation activity. Meeting reporting deadlines does not reduce the likelihood or impact of the incident and does not restore systems or data. Containment, recovery, and resilience objectives such as RTO and RPO are pursued through incident response and disaster recovery, which are separate from the reporting workflow.

Best practices

Maintain a documented classification procedure that maps incidents against the materiality thresholds of each applicable regulatory regime, so that the reporting decision is consistent and defensible rather than ad hoc.
Build a phased reporting timeline into incident response playbooks, tracking initial, intermediate, and final submission deadlines separately and assigning clear ownership for each.
Treat regulatory reporting and insurer notification as distinct workstreams, and confirm the recipients, channels, and deadlines for each before an incident occurs rather than during one.
Pre-identify the competent authorities and their submission formats or portals for every jurisdiction in which the organization operates, since requirements can differ across regimes.
Preserve incident evidence, timelines, and decision logs contemporaneously so that report content can be assembled accurately and updated across reporting phases as understanding of root cause matures.
Verify current reporting thresholds and timelines against the applicable regulation before relying on them, as these are set by the governing regime and can change independently of internal policy or insurance wording.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide