Category: Incident Management
Major ICT-Related Incident
Also known as: Major ICT Incident, Major ICT-Related Incident (DORA)
Simply put
Under the EU's Digital Operational Resilience Act (DORA), a major ICT-related incident is a technology-related disruption that seriously affects the systems supporting a financial entity's critical or important functions. When an incident meets this threshold, the financial entity is required to report it to its supervisory authority. It is a specific regulatory classification, not a general term for any IT problem.
Formal definition
Within the DORA framework, a major ICT-related incident is an ICT-related incident that has a high adverse impact on the network and information systems supporting critical or important functions of a financial entity. The classification as 'major' depends on the incident meeting defined thresholds, the detailed classification criteria and materiality thresholds are established separately in the framework rather than within a single provision, and triggers mandatory notification to the relevant competent authority. Financial entities are required to define, establish, and implement an ICT-related incident management process to detect, manage, and notify such incidents. This term applies specifically to financial entities within the EU regulatory scope under DORA; it is distinct from a general operational or security incident and from a 'significant cyber threat', which is a separate reportable category. Note that this definition reflects the DORA regime and does not necessarily correspond to incident classifications used in other jurisdictions or non-financial sectors.
Why it matters
The classification of an ICT-related incident as "major" is the trigger that converts an internal operational event into a regulatory reporting obligation. Under DORA, financial entities cannot treat every technology disruption the same way; they must assess whether an incident has a high adverse impact on the network and information systems supporting critical or important functions. Getting this classification right matters because it determines whether, when, and to what level of detail an entity must notify its competent authority, and misjudging the threshold can expose an entity to both under-reporting and unnecessary over-reporting.
Who it's relevant to
Operational Resilience and Incident Management Teams
These teams own the ICT-related incident management process that DORA requires entities to establish. They must build detection, triage, and classification capabilities that can reliably distinguish major incidents from routine faults and apply the classification criteria consistently under time pressure and incomplete information.
Regulatory Compliance and Reporting Functions
Compliance teams are responsible for ensuring that major ICT-related incidents are notified to the competent authority within the expected timelines and that reporting is separated correctly from the distinct category of significant cyber threats. They also need to track how classification criteria and thresholds are elaborated in supporting technical standards, since these determine what crosses the reporting threshold.
Third-Party and ICT Vendor Risk Managers
Because incidents affecting critical or important functions frequently originate with ICT third-party service providers, vendor risk managers need contractual and monitoring arrangements that surface provider-side incidents in time to support classification and reporting. The reporting obligation rests with the financial entity, so visibility into third-party events is a prerequisite for meeting it, though visibility beyond the direct provider is often limited.
Financial Entities Within EU Scope
The classification applies specifically to financial entities subject to DORA. Firms operating across multiple jurisdictions should not assume this definition or its thresholds map onto incident-reporting regimes elsewhere, and should reconcile DORA obligations with any parallel sectoral or national reporting duties.
Inside Major ICT-Related Incident
Classification thresholds
Criteria used to determine whether an ICT-related incident qualifies as 'major' rather than routine, typically considering factors such as the number of clients or counterparts affected, duration, geographical spread, data losses, and the criticality of services impacted. Under DORA, the detailed classification criteria for ICT-related incidents reside in Article 18, distinct from the incident management and reporting process itself.
Reporting obligation
The requirement placed on affected financial entities to notify competent authorities when an incident meets the 'major' threshold. Under DORA, the obligation to report major ICT-related incidents is set out in Article 19, which is distinct from the general incident management and classification provisions.
Incident management process
The underlying process for detecting, managing, and logging ICT-related incidents from which classification and reporting flow. This process establishes how incidents are identified and handled before a 'major' determination is made.
Reporting timeline and phases
Typically structured as an initial notification followed by intermediate and final reports, allowing authorities to be alerted quickly while more complete information is gathered over time. Exact deadlines and phase content depend on applicable regulatory technical standards rather than being fully specified in the base legislative text.
Scope boundary
The term addresses ICT-related incidents (disruptions to information and communication technology and associated services) and does not by itself cover non-ICT operational disruptions, financial risk events, or third-party contractual failures unless those manifest as ICT-related incidents meeting the classification criteria.
Common questions
Answers to the questions practitioners most commonly ask about Major ICT-Related Incident.
Is a major ICT-related incident reported under Article 17 of DORA?
No. This is a common point of confusion. The obligation to report major ICT-related incidents to the relevant competent authority is set out in Article 19, not Article 17. Article 17 addresses the ICT-related incident management process more broadly. When referencing the reporting obligation specifically, cite Article 19 to avoid misattributing the requirement.
Does Article 17 define how an incident is classified as 'major'?
No. The classification of ICT-related incidents and the criteria and thresholds used to determine whether an incident qualifies as 'major' reside in Article 18, not Article 17. Treating classification and thresholds as governed within Article 17 conflates the incident management process with the distinct classification criteria set out separately.
How should a third-party risk program align supplier obligations with the classification criteria for major incidents?
Depending on the risk tier of the relationship, contracts and service arrangements with ICT third-party providers should typically require timely notification of incidents in terms that map to the classification criteria. Because the criteria and thresholds sit within their own provisions, programs generally reference those criteria directly rather than embedding a static definition, so that supplier notification triggers remain aligned as the criteria are applied.
What information should firms collect from providers to support timely incident reporting?
In many programs, providers are expected to supply incident details sufficient to assess classification against the established criteria and to meet subsequent reporting obligations. This can include the nature and timing of the incident, affected services, and impact indicators. Firms should verify that contractual notification timelines leave adequate margin for their own assessment and reporting steps, since provider-reported information may be incomplete at first notification and subject to update.
How does visibility beyond the direct provider affect major incident detection?
Direct contractual arrangements typically give the clearest visibility into the immediate provider, but incidents may originate with subcontractors or further-tier dependencies where visibility is more limited. Programs often address this by requiring providers to pass through relevant incident information from their own subcontractors, while recognizing that assurance beyond the first tier is generally weaker and depends on the flow-down terms actually in place.
Should incident classification be treated as a one-time determination?
No. Classification is applied against the criteria based on the information available, and that information often evolves as an incident develops. A situation initially assessed below the threshold may later meet it, and vice versa. Many programs treat classification as subject to reassessment as new details emerge, rather than as a single point-in-time judgment, and document the basis for any change.
Common misconceptions
The mandatory reporting obligation for major ICT-related incidents originates from a single article that also defines the classification criteria.
Under DORA, these responsibilities are separated across provisions: the reporting obligation for major ICT-related incidents is set out in Article 19, while the detailed classification criteria and thresholds reside in Article 18. Conflating them into one article misstates the source of each requirement.
Any significant ICT disruption automatically qualifies as a 'major ICT-related incident' requiring notification to authorities.
Whether an incident is 'major' depends on it meeting defined classification thresholds. Incidents falling below those criteria are managed internally and may not trigger the same regulatory reporting obligations, though this can vary by jurisdiction and sector.
A single initial notification satisfies the full reporting obligation.
Reporting is typically phased, comprising an initial notification followed by intermediate and final reports as information develops. Submitting only the initial notice generally does not complete the obligation.
Best practices
Map your internal incident classification logic explicitly to the applicable regulatory thresholds so that 'major' determinations are consistent, documented, and defensible rather than made ad hoc.
Distinguish clearly in policies and playbooks between the classification criteria and the reporting obligation, referencing the correct provisions to avoid conflating where each requirement originates.
Establish a phased reporting workflow with clear ownership for initial, intermediate, and final submissions, and pre-define the information each phase requires to meet timelines under pressure.
Test incident escalation and classification decisions through exercises, since real-time determination of whether a threshold is met is often where programs struggle most.
Track jurisdiction- and sector-specific variation in reporting expectations, as thresholds, timelines, and recipient authorities can differ across regimes.
Maintain an audit trail of the data underlying each classification decision (clients affected, duration, criticality) so that determinations can be independently reviewed and revisited if the incident's impact grows.
