Major Incident

Major incident is an incident that causes, or credibly threatens, substantial disruption to an IT service or business operation and requires an immediate, coordinated response beyond routine incident handling. In IT service management, the classification identifies events whose consequences demand concentrated management attention, accelerated escalation, and coordinated service restoration.

A major incident might involve a critical payment service becoming unavailable, a shared authentication platform preventing employees from working, or a severe degradation during a time-sensitive business operation. The affected population may be large, but user count alone is insufficient: disruption to one highly consequential service can justify a major-incident declaration. Organizations set their own thresholds by service criticality, business impact, urgency, dependencies, and the response needed.

The term names the incident and its exceptional significance. It is distinct from major incident management, the organized response used to contain the consequences and restore service. A major incident is also not necessarily identical to a Priority 1 ticket: incident priority measures the urgency and impact used to order work, whereas a major-incident declaration invokes an agreed response and coordination model. Organizations may link these classifications, but the mapping is a local policy choice.

What makes an incident major?

The primary test is the significance of the service or business consequences and whether ordinary incident arrangements can respond adequately. The threshold should be established before an outage, while retaining a way to declare a major incident when an unusual situation falls outside predefined rules. An incident can initially appear minor and later become major as its scope, duration, or business effects become clearer.

Assessment dimension	Evidence relevant to a major-incident decision	Qualification
Critical service impact	A service essential to revenue, patient care, public operations, safety, identity, or another critical business function is unavailable or seriously degraded.	One critical service may be enough, even if comparatively few people use it.
Extent of disruption	Large numbers of customers, employees, locations, business units, or transactions are affected.	A raw user count matters only in relation to the service and its business context.
Time sensitivity	A disruption occurs during a payment deadline, reporting window, critical operation, or other period when delay increases harm.	The same technical failure may have different consequences at different times.
Security, safety, or data exposure	The incident involves significant loss of data, service integrity, security capability, or safety-related functionality.	Specialist security, legal, or safety escalation may be required in addition to IT service restoration.
Response complexity	Several service owners, suppliers, technical disciplines, or business teams must act together under urgent conditions.	Coordination need may trigger major-incident procedures even before the full consequences are known.
Potential for escalation	Credible evidence indicates that an existing degradation may rapidly affect a critical dependency or wider service.	The declaration should identify what is observed and what remains a risk or hypothesis.

These are assessment dimensions, not a universal scoring formula. For example, the University of California, Berkeley includes critical-system outages, significant degradation affecting campus users, and time-sensitive windows in its documented major-incident criteria. PagerDuty uses the need for a coordinated response between teams as its operating trigger. Both are legitimate organizational definitions, but neither should be presented as a rule binding every enterprise.

Major incident declaration and incident priority

Declaration is the operational decision to treat an event as major and activate the designated response arrangements. It is normally made by an authorized incident manager, service manager, or other person defined in the organization's incident management policy. Monitoring or service desk staff may raise a candidate or initiate escalation before a formal declaration. In some implementations, automated rules propose candidate incidents for a major incident manager to accept or reject.

Priority and declaration answer different questions. A severity or priority label indicates the assessed seriousness and urgency of an incident within a classification scheme. A major-incident declaration determines whether a specially coordinated response is necessary. For example, Atlassian treats its SEV 1 and SEV 2 incidents as major incidents, while PagerDuty explicitly allows coordinated incident response to begin before a final severity is established.

This distinction matters when service impact is uncertain. Waiting for a fully evidenced root cause or an exact count of affected users may delay a necessary response. Equally, automatically designating every high-priority ticket as major can create alert fatigue and dilute attention. The declaration should be defensible and revisable as evidence changes; it should not depend on a perfect initial diagnosis.

How a major incident changes the response

Ordinary incident management seeks to restore normal service while minimizing adverse business impact. The major classification adds more concentrated coordination and visibility when the normal assignment and escalation path is inadequate. It typically changes who is engaged, how quickly they are contacted, how work is coordinated, and how stakeholders are informed.

A major-incident response commonly includes a named lead, a shared operational record, rapid involvement of relevant service teams, an agreed communication channel, frequent impact assessment, a clear approach to restoring service, and a deliberate handoff to follow-up analysis. The goal is to reduce the consequences of the incident while avoiding conflicting technical actions or contradictory messages. A dedicated response structure should make decisions faster and clearer, rather than adding another approval queue.

Response element	What changes when an incident is declared major
Coordination	A major incident manager or equivalent incident lead directs the response across technical and business groups.
Escalation	On-call responders, owners of affected services, vendors, and appropriate management contacts are mobilized according to the urgency and scope.
Shared operational picture	A primary incident record and current situation summary establish affected services, known impact, open questions, decisions, owners, and next actions.
Communications	Customer, employee, business, executive, and supplier updates follow the appropriate audience-specific communication arrangements.
Restoration	Teams prioritize a safe way to restore acceptable service, including an approved workaround or recovery action when the permanent cause is not yet known.
Learning	An appropriate post-incident review examines the event, response, contributing conditions, and necessary follow-up once immediate impact is controlled.

These are common operating mechanisms, not mandatory job titles or a requirement for every enterprise to maintain a permanent crisis command team. A small service provider may combine several responsibilities in one person; a complex multinational organization may need separate communications, technical, business, and security leads.

The incident's operational progression

A major incident is a condition requiring action, rather than a fixed series of steps. Its response nevertheless moves through recognizable states. The sequence may loop as new facts emerge, a workaround fails, or the affected service changes.

1. Detection and initial assessment. Monitoring, user reports, or technical teams identify a service disruption and estimate business consequences. Responders record the initial facts and uncertainty.
2. Declaration and mobilization. The designated authority determines that an elevated response is required, identifies an incident lead, and contacts the necessary specialists and stakeholders.
3. Coordinated investigation and containment. Teams assemble the service picture, assess dependencies, compare plausible explanations, and consider steps to limit additional harm. Work can proceed in parallel under a common coordinator.
4. Service restoration and verification. An authorized workaround, failover, rollback, repair, or other measure restores an acceptable level of service; teams verify the business outcome, not just a technical signal.
5. Resolution and transition. The acute response ends when the agreed impact-ending conditions are met. Residual risks, temporary fixes, user notifications, and follow-up ownership are recorded.
6. Review and prevention. An appropriate post-incident review or problem-management investigation addresses causes, contributing factors, response weaknesses, and recurrence risk.

Atlassian describes an incident response that combines detection, assessment, escalation, delegation, communication, resolution, and a subsequent postmortem. ServiceNow documents major-incident-specific activities for candidate identification, collaborative response, communication, resolution, and post-incident review. These illustrate similar operating needs without imposing one universal sequence or tool configuration.

Roles, authority, and accountability

A major incident requires clear operational authority because several people may have legitimate responsibilities at once. The major incident manager coordinates the response, but does not automatically own every technical, security, financial, or business-risk decision. The arrangement should establish who can declare and close the major status, direct response priorities, authorize exceptional action, communicate externally, and accept residual risk.

Role	Typical contribution	Accountability boundary
Major incident manager or response lead	Coordinates work, maintains the operating picture, resolves cross-team conflicts, and tracks restoration progress.	Does not automatically have authority to waive all change, security, or business-risk controls.
Service desk and monitoring teams	Detect incidents, collect user impact, link reports, route escalations, and keep support channels informed.	May propose a major incident without owning its formal declaration.
Technical responders and suppliers	Diagnose service and dependency behavior, test remedies, and carry out recovery actions within assigned responsibilities.	Remain accountable for the safety and evidence of their own technical work.
Service or product owner	Explains business criticality, customer commitments, dependencies, and acceptable restoration conditions.	Advises on or makes business-risk decisions only within delegated authority.
Communications coordinator	Issues accurate, consistent updates for users, customers, management, and other audiences.	Should distinguish confirmed facts from estimates and unverified causes.
Security, resilience, legal, or executive leads	Join when the incident engages specialist obligations, continuity decisions, external reporting, or material enterprise exposure.	Their involvement does not transfer all specialist decisions to the incident manager.

Some organizations use the title incident commander for the coordinating role. The title does not by itself determine the legal, managerial, or technical authority of its holder. Larger organizations may also maintain an on-call structure and designate a deputy so that a single responder does not become a bottleneck.

Records and decisions during a major incident

A useful incident record makes a changing situation understandable to responders and reviewers. It normally identifies the affected service, onset and detection times, user or business impact, current severity and declaration status, response lead, significant technical observations, decisions, workarounds, recovery steps, communications, and the evidence used to declare service restored. A linked timeline can separate what actually happened from what participants believed at the time.

During the event, the record needs to support decisions without slowing the response. Afterward, it should support reconstruction of impact, elapsed time, inter-team handoffs, approval decisions, and open corrective actions. Duplicating every chat message into several manual records is less useful than maintaining one trustworthy incident chronology with reliable links to the supporting evidence.

Relationship to other management activities

Major incidents interact with several distinct IT management concepts. Keeping their responsibilities separate helps prevent a recovery action, a cause investigation, or a continuity decision from being mistaken for the incident itself.

Related entity	Relationship to a major incident	Distinction
Incident	Major incident is a subset of incidents distinguished by its business significance and response requirements.	Most incidents do not require a specially coordinated response.
Major Incident Management	Provides the roles, coordination, communication, and restoration approach activated for major incidents.	The major incident is the event; management is the response capability and process.
Incident Management	Provides the broader practice within which major incidents are identified and handled.	Routine incident work can be performed without invoking major-incident arrangements.
Problem Management	Investigates actual or potential causes and recurrence risks associated with the disruption.	Service may be restored before the underlying cause is fully understood or permanently corrected.
Emergency Change and Change Enablement	A production change may be necessary to contain or resolve the disruption and may qualify for expedited authorization.	Major-incident declaration alone does not authorize uncontrolled changes to production systems.
Business Continuity Planning (BCP) and IT Service Continuity Management (ITSCM)	A prolonged or widespread disruption may require alternative business operations or recovery of critical supporting IT services.	Continuity and recovery arrangements address sustained operation and preparedness beyond the immediate incident response.
Post-Incident Review	Uses the event record and evidence to understand what happened and what should improve.	A review is conducted after the acute response; it is not a substitute for immediate service restoration.

A major IT incident can coincide with a cybersecurity breach, physical disruption, vendor failure, or business crisis. These may invoke separate security response, legal, contractual, disaster recovery, or continuity authorities. The major-incident label should help coordinate them without suggesting that the IT response lead alone is empowered to make every consequential decision.

Illustrative example

Consider a hypothetical enterprise whose shared identity provider becomes unavailable during the start of a business day. Thousands of employees cannot authenticate to the enterprise resource planning system, customer support platform, and internal communications services. The service desk receives a surge of reports; monitoring shows widespread login failures, but the underlying cause is not yet known.

The incident is declared major because a shared critical dependency is disrupting several business functions and a single support team cannot restore service independently. A major incident manager mobilizes identity engineers, network operations, affected application owners, the identity provider, and a communications lead. The team establishes one incident timeline and issues an initial notice describing observed effects without claiming a confirmed cause.

Engineers determine that an identity routing change offers a safe route to restore service. If implementing that remedy alters a controlled production service, it is assessed and authorized through the applicable change route, including emergency authorization where genuinely required. Once authentication and affected business transactions are verified, the organization ends the acute response and assigns follow-up analysis of the triggering condition, recovery safeguards, and communications. This example is illustrative and is not a report of an actual incident.

The example shows why major refers to service and business consequences and coordinated response, rather than to the size of the code defect or the number of support tickets. It also illustrates the separate decisions to restore service, authorize a change, and investigate causes.

Common failures and limitations

Declaring an incident major can speed coordination, but the declaration itself does not restore service or ensure that decisions are sound. Common failure patterns include delaying escalation while teams seek a complete diagnosis, relying on a severity number without checking business impact, activating too many responders without clear assignments, issuing unsupported restoration estimates, and closing the event before affected business services have actually recovered.

The opposite problem also occurs: overdeclaration of routine incidents can desensitize responders and consume scarce specialist capacity. A useful classification policy should therefore combine advance criteria with empowered professional judgment. It should permit a mistaken declaration to be revised when evidence changes and should reward timely, well-reasoned escalation rather than perfect hindsight.

Communication is particularly vulnerable when teams confuse technical progress with customer recovery. For example, restarting an application does not establish that transactions are being completed or that users can access dependent services. Updates should distinguish the observed problem, current business effect, mitigation status, and next update commitment. Unconfirmed root causes or restoration times should be described as provisional, not as facts.

Measuring the impact and response

Major-incident performance can be examined through operational measures, business effects, and the quality of subsequent learning. Metrics need consistent definitions, especially for when the impact started and when service was acceptably restored.

Measure	What it helps assess	Interpretation caution
Time from detection to major-incident declaration	Whether consequential events receive timely coordinated attention.	Faster is not automatically better if declarations are indiscriminate; missed and late declarations also matter.
Time to mobilize the necessary responders	How quickly the response obtains relevant decision-making and technical capability.	Counting people on a call does not establish useful coordination.
Time to mitigate or restore acceptable service	Duration of the business-impacting condition and effectiveness of restoration.	Distinguish partial mitigation, technical recovery, verified business restoration, and administrative ticket closure.
Business impact	Disrupted transactions, affected services, customer consequences, financial exposure, or other material outcomes.	Avoid comparing unlike services solely by incident count or minutes of downtime.
Communication timeliness and accuracy	Whether audiences receive reliable information when they need it.	The number of messages is not evidence that they were clear or accurate.
Recurrence and corrective-action outcomes	Whether a similar failure or response weakness persists after review.	Incident frequency depends on system exposure, detection quality, and the comparability of events.

These measures should support learning and risk decisions rather than become a single universal performance score. A lower count of major incidents might reflect improved reliability, reduced service demand, or suppressed classification. Assessment requires the underlying service and reporting context.

ITIL context

Major incidents are discussed within the incident management practice used by ITIL-oriented service organizations. ITIL's broader objective is to minimize the adverse impact of incidents through prompt restoration of acceptable service. The specific criteria for declaring an event major, selecting a response lead, communicating with stakeholders, and coordinating across suppliers are adapted to an organization's services and operating model. PeopleCert's ITIL (Version 5) qualification structure continues to include incident management within its Monitor, Support and Fulfil practices; the existence of a practice does not prescribe one universal incident severity matrix.

See also

• Incident Management
• Major Incident Management
• Major Incident Manager
• IT Service Desk
• Problem Management
• Post-Incident Review
• Emergency Change
• Business Continuity Planning (BCP)
• IT Service Continuity Management (ITSCM)
• IT Service Management (ITSM)