Skip to main content
Oversight Institute
Category: Incident Management

Major Incident Classification

Also known as: Major Incident Severity Classification, Major ICT-Related Incident Classification
Simply put

Major incident classification is the process of deciding whether a disruption is serious enough to be treated as a 'major incident' that requires a formal, coordinated response rather than routine handling. Organizations apply predefined criteria, such as how severely business operations are disrupted or how widely the impact spreads, to sort incidents into severity levels. What counts as 'major' varies by organization and by regulatory regime.

Formal definition

Major incident classification is the application of defined criteria and severity scales to determine whether an incident qualifies as 'major,' triggering escalated, coordinated response procedures. In some operational frameworks, incidents rated at the highest severity tiers (for example, SEV-1 or SEV-2) are typically designated major incidents, while lower tiers are handled through standard processes; classification is often performed by a designated role (such as an Incident Response Manager) using a documented classification matrix. Under the EU's DORA regime, Regulatory Technical Standards specify criteria for classifying major ICT-related incidents, with a major incident generally understood as one that significantly disrupts operational continuity or affects the broader financial system. Note that classification schemes and thresholds are not standardized across organizations or jurisdictions: the distinction between 'major' and 'critical' incidents differs by scheme (in some usages major incidents are confined to specific systems or processes while critical incidents pose broader threats), and regulatory definitions such as DORA's apply to specific sectors and geographies rather than universally. The classification captured here addresses incident severity and escalation triggers; it does not itself specify remediation, reporting timelines, or the underlying detection controls.

Why it matters

Major incident classification determines whether a disruption receives an escalated, coordinated response or is handled through routine processes. This threshold decision matters because it governs who is mobilized, how quickly, and with what authority. Misclassifying a serious event as routine can delay coordinated response, while over-classifying can strain response resources. In third-party and supply chain contexts, the classification a vendor or service provider applies to an incident on their side directly shapes whether, and how urgently, it is communicated to dependent organizations, making consistent classification a factor in downstream visibility.

The practical difficulty is that classification schemes and thresholds are not standardized across organizations or jurisdictions. What one organization treats as a 'major' incident, another may treat as merely 'critical' or routine, and the distinction between 'major' and 'critical' itself differs by scheme, in some usages major incidents are confined to specific systems or processes while critical incidents pose broader threats. This variation complicates efforts to align incident expectations across contractual relationships, where different parties may operate under incompatible severity definitions.

Regulatory regimes add a further layer. Under the EU's DORA framework, Regulatory Technical Standards specify criteria for classifying major ICT-related incidents, with a major incident generally understood as one that significantly disrupts operational continuity or affects the broader financial system. However, such regulatory definitions apply to specific sectors and geographies rather than universally, so organizations operating across regions or serving multiple sectors may need to reconcile a regulatory classification standard with their own internal severity scales.

Who it's relevant to

Incident Response and Operational Resilience Teams
These teams apply the classification matrix in practice and own the escalation decision. Consistent, documented criteria help ensure that comparable events receive comparable responses and that the trigger for a coordinated major-incident response is applied predictably rather than case by case.
Third-Party Risk and Vendor Management Professionals
Because a supplier's own classification determines how urgently an incident is escalated and communicated, TPRM professionals may seek to understand how key vendors classify incidents and whether contractual notification expectations align with the vendor's internal severity thresholds. Differences in classification schemes across parties can affect downstream visibility.
Compliance Teams in Regulated Sectors
For organizations subject to regimes such as DORA, classification of major ICT-related incidents follows criteria specified in Regulatory Technical Standards. Compliance teams need to reconcile these sector- and geography-specific regulatory definitions with internal severity scales, recognizing that such regulatory definitions are not universal across jurisdictions or sectors.
Procurement and Contract Owners
Those negotiating service agreements may use incident classification concepts to define notification obligations and response expectations. Because 'major' and 'critical' can carry different meanings across schemes, contract language benefits from explicitly defining severity terms rather than assuming a shared understanding.

Inside Major Incident Classification

Severity Tiering
A graduated scale (often expressed as levels such as Sev-1 through Sev-4 or Critical/High/Medium/Low) that ranks an incident by its potential or actual impact. In third-party contexts, tiering typically weighs factors such as service criticality, data sensitivity, and the number of dependent processes, though specific thresholds vary by program and are not standardized across organizations.
Impact Assessment Criteria
The defined dimensions used to gauge magnitude, which may include operational disruption, financial exposure, data confidentiality or integrity loss, regulatory or contractual breach, and reputational harm. A 'major' designation depends on how many of these criteria are triggered and to what degree, rather than on a single factor.
Classification Triggers and Thresholds
The predefined conditions that elevate an incident to 'major' status, such as breach of a service-level threshold, confirmed exposure of regulated data, or loss of a critical supplier's service. Thresholds are typically set during program design and may differ by risk tier of the third party involved.
Third-Party and Nth-Party Scope
The delineation of whether an incident originates with a direct third party, a fourth party, or deeper in the supply chain. Classification often accounts for reduced visibility beyond the first tier, which can complicate accurate impact scoring for events at subcontractor level.
Escalation and Notification Pathways
The routing rules that tie a classification level to required actions, such as who must be informed, contractual notification timelines, and regulatory reporting obligations. These pathways depend on jurisdiction, sector, and the terms negotiated in the underlying contract.
Reassessment and Reclassification Provisions
The mechanism for adjusting an incident's classification as new information emerges. Because initial classification is often made under uncertainty, many programs treat the initial tier as provisional and subject to upgrade or downgrade during investigation.

Common questions

Answers to the questions practitioners most commonly ask about Major Incident Classification.

Is major incident classification the same as assigning a high severity level to an incident?
Not exactly. Severity and major incident status are related but distinct. Severity typically describes the technical or business impact of an incident on a graded scale, while a major incident classification is a formal designation that triggers a specific escalation, communication, and governance response. In many programs a high-severity incident is a candidate for major incident status, but the classification usually depends on additional criteria such as breadth of impact, duration, regulatory implications, or the need for coordinated cross-functional response. Treating the two as interchangeable can lead to inconsistent escalation, so most programs define explicit criteria that separate them.
Does classifying an incident as a major incident automatically trigger regulatory notification?
Not automatically. Internal major incident classification and external regulatory reporting obligations are governed by different criteria, and the thresholds rarely align one-to-one. An incident can meet an organization's internal major incident definition without meeting a reporting threshold, and conversely a reportable event may not match internal major incident criteria. Regulatory notification requirements vary by jurisdiction and sector, and depend on factors such as the type of data or service affected and defined timeframes. Programs typically maintain a separate assessment step to determine reporting obligations rather than assuming classification alone satisfies them.
What criteria should a major incident classification scheme include?
Criteria vary by program, but classification schemes commonly consider factors such as impact on critical services or customers, the number of affected parties, duration or expected time to resolution, financial exposure, safety implications, and potential regulatory or reputational consequences. Many programs use a combination of impact and urgency dimensions rather than a single measure. Depending on the risk tier and sector, criteria may also account for whether a third party or supplier is the source of the disruption. Defining criteria explicitly, rather than relying on subjective judgment, helps produce consistent classification across responders and shifts.
Who should have the authority to declare a major incident?
This depends on the program's governance model. In many organizations, designated roles such as an incident manager, on-call lead, or duty officer are empowered to declare a major incident so that response is not delayed by escalation bottlenecks. Some programs allow provisional declaration by first responders subject to later confirmation. The key considerations are typically speed of activation, clarity of accountability, and avoiding both over-declaration and under-declaration. Clear documentation of who holds declaration authority, and under what conditions, tends to reduce ambiguity during high-pressure events.
How should major incident classification account for third-party or supplier-caused disruptions?
Because incidents originating with a third party can affect an organization's own services, many programs extend their classification criteria to cover supplier-caused disruptions. In practice this often means mapping which suppliers support critical functions and defining how a disruption at a third party maps onto internal impact thresholds. Visibility can be a limitation, since an organization may have limited insight into an incident's root cause or scope beyond its direct supplier, particularly for fourth-party or Nth-party dependencies. Contractual notification and coordination arrangements typically influence how quickly and accurately such incidents can be classified.
Should classification remain fixed once assigned, or can it change during an incident?
Classification is generally treated as dynamic rather than fixed. As an incident evolves, new information about scope, impact, or duration may justify escalating or de-escalating the classification. Many programs build reassessment points into their process so that classification reflects current conditions rather than the initial assessment, which may have been made with incomplete information. Documenting classification changes and the rationale for them supports consistency and provides a basis for post-incident review, since an initial classification made under uncertainty can become stale as facts emerge.

Common misconceptions

A major incident classification is an objective, universally comparable label.
Classification thresholds are typically defined per organization or per program and reflect internal risk appetite, service criticality, and contractual terms. What one organization designates 'major' may be a lower tier elsewhere, so classifications are not directly comparable across entities without understanding each program's criteria.
Classifying an incident as 'major' reflects the residual risk after controls have acted.
An incident classification describes the assessed impact of an actual event, which is distinct from residual risk (the risk remaining after mitigating controls) and from inherent risk (risk before controls). Conflating the classification of a realized incident with a risk-assessment output misrepresents both concepts.
A third party's report that an incident is minor can be taken at face value for classification.
Supplier self-reporting is an attestation, not independent verification. Because visibility beyond the first tier is often limited and self-reported severity may understate impact, many programs treat an initial third-party classification as provisional pending validation.

Best practices

Define severity tiers and their triggering thresholds in advance, tying them to the risk tier and service criticality of each third party rather than applying a single blanket scale.
Separate the classification of a realized incident from risk-assessment outputs, and document which impact dimensions (operational, financial, data, regulatory, reputational) drove the assigned tier.
Treat an initial classification as provisional and build in reassessment checkpoints so the tier can be upgraded or downgraded as investigation reveals more accurate impact information.
Corroborate third-party self-reported severity where feasible rather than accepting an attestation as verified, recognizing that visibility beyond the first tier is often constrained.
Map each classification level to explicit escalation and notification actions, accounting for contractual timelines and jurisdiction- and sector-specific reporting obligations that may differ across regions.
Extend classification logic to consider fourth-party and Nth-party origins, and flag where limited multi-tier visibility may reduce confidence in the assigned severity.
Promotional banner for the Penetration Report Template Kit