When a critical system goes down and hundreds of users are impacted, your team can’t afford to improvise. A well-defined major incident management process is what separates organizations that recover in minutes from those that spend hours in confusion. This guide walks through every stage of the process — from declaring a major incident to closing it out — including roles, responsibilities, process flow, and real-world examples to help you build or refine your own approach.
What Is a Major Incident?
A major incident is a high-impact, high-urgency event that significantly disrupts business operations and requires a coordinated response beyond standard incident handling procedures. In ITIL terms, it sits at the top of the priority scale — typically Priority 1 — and triggers a separate, accelerated management process.
The threshold for “major” varies by organization, but common criteria include:
- A business-critical service is completely unavailable
- A large number of users are affected (e.g., 100+ employees or all external customers)
- There is significant financial, reputational, or regulatory exposure
- Standard incident resolution procedures are insufficient or too slow
Examples of major incidents include a full e-commerce platform outage during a peak sales period, a core banking system failure, a data breach affecting customer records, or a widespread network outage preventing employees from working.
Major Incident Management in ITIL
ITIL (IT Infrastructure Library) treats major incident management as a subset of the broader incident management practice, but with a dedicated procedure. ITIL 4 emphasizes that major incidents require a separate, clearly documented process with designated roles, escalation paths, and communication protocols — not just a higher-priority ticket.
The key distinction ITIL draws is that major incident management is about restoring service as fast as possible, not about finding root causes. Root cause analysis happens afterward, through the problem management process. Conflating the two during an active major incident slows resolution down.
The Major Incident Management Process: Step by Step
The following process flow covers the end-to-end lifecycle of a major incident. Organizations often document this as a process flow diagram or a formal process document — both of which are useful artifacts to have ready before an incident occurs, not during one.
Step 1: Detection and Logging
A potential major incident is detected — either through automated monitoring alerts, user reports, or escalation from the service desk. At this stage, the incident is logged in the ITSM tool with as much detail as available: affected services, number of users impacted, initial symptoms, and time of detection.
The service desk or on-call engineer performs an initial triage to determine whether standard incident procedures apply or whether the major incident process should be triggered.
Step 2: Classification and Declaration
Based on predefined criteria (impact, urgency, affected services), the incident is classified and a decision is made to formally declare it a major incident. This declaration is the trigger for the entire major incident process to activate.
Clear, documented criteria for what qualifies as a major incident are critical here. Without them, teams either over-declare (causing alert fatigue) or under-declare (causing delayed response to real crises).
Step 3: Escalation and Team Assembly
Once declared, the major incident is escalated to the Major Incident Manager (or equivalent role). The relevant technical resolver groups are assembled — typically drawn from infrastructure, application, network, and security teams depending on the nature of the incident. A war room (physical or virtual) is established as the central coordination point.
Stakeholders who need to be notified at this stage include IT leadership, business relationship managers, and communications teams if customer-facing services are affected.
Step 4: Investigation and Diagnosis
The resolver teams work to identify the scope and cause of the incident. This is not a full root cause analysis — the goal is to find enough information to implement a fix or workaround quickly. Parallel workstreams are common: one team investigates while another prepares a potential workaround.
The Major Incident Manager keeps the team focused on resolution rather than analysis paralysis. Regular update cadences (every 15–30 minutes) keep all parties aligned on progress.
Step 5: Communication Management
Ongoing communication is one of the most critical — and most frequently mishandled — parts of major incident management. A dedicated communications lead should manage two distinct streams:
- Internal updates: Regular briefings to IT leadership and business stakeholders on status, estimated resolution time, and business impact
- External updates: Customer-facing status page updates, support ticket responses, and any regulatory notifications if required
Communication should be factual and timely. Silence during a major incident is perceived as incompetence. A simple “We are aware of the issue and actively investigating” update every 30 minutes is better than no communication while the team works.
Step 6: Resolution and Service Restoration
Once a fix or workaround is identified, it is implemented and tested. The priority is restoring service, not necessarily fixing the underlying problem permanently. A temporary workaround that gets users back to work is preferable to a longer wait for a permanent fix.
Service restoration is confirmed by monitoring systems and user verification. The incident is then resolved in the ITSM tool with a detailed resolution note.
Step 7: Communication of Resolution
All stakeholders are notified that service has been restored. Internal and external communications are updated. If a workaround rather than a permanent fix was applied, this is clearly communicated along with the expected timeline for a permanent resolution.
Step 8: Post-Incident Review (PIR)
Within a defined window after resolution (typically 24–72 hours for major incidents), a post-incident review is conducted. This feeds directly into the problem management process to identify root cause and prevent recurrence. The PIR should document: timeline of events, actions taken, what worked, what didn’t, and specific improvement actions with owners and deadlines.
The PIR output is not a blame document — it is an improvement tool. Organizations that treat it as a blame exercise will find their teams reluctant to be honest, which defeats the purpose.
Major Incident Management Roles and Responsibilities
Clear role assignment before an incident occurs is what prevents the chaos of “who’s in charge?” during an actual crisis. The following roles are standard in most mature major incident management processes.
Major Incident Manager
The single point of accountability for the entire major incident lifecycle. This person drives the process, not the technical resolution. Responsibilities include declaring the major incident, assembling the team, chairing the war room, managing communication cadence, and ensuring the PIR is completed. This role requires strong communication and coordination skills, not necessarily deep technical expertise.
Technical Lead / Resolver Teams
Subject matter experts who perform the actual investigation and fix. Each resolver group (infrastructure, application, network, security) has a technical lead who reports progress to the Major Incident Manager. Resolver teams should be empowered to make technical decisions quickly without bureaucratic approval chains slowing them down.
Communications Lead
Manages all stakeholder communications — internal updates to leadership and business owners, and external updates to customers or the public. In smaller organizations, this role may be handled by the Major Incident Manager, but separating it is recommended to prevent communication from being neglected while the manager focuses on coordination.
Service Desk Liaison
Keeps the service desk informed so they can handle the influx of related tickets, provide users with consistent messaging, and avoid duplicate troubleshooting efforts by end-user support teams.
Problem Manager
Often engaged during or immediately after the major incident to prepare for the PIR and formal root cause analysis. In some organizations, the Problem Manager observes the major incident in progress to gather information for the subsequent problem record.
Major Incident Management Process Flow Diagram
A process flow diagram is one of the most useful artifacts for operationalizing major incident management. While a visual diagram is best created in tools like Lucidchart, Visio, or even PowerPoint, the logical flow follows this sequence:
- Incident detected and logged → Initial triage
- Does the incident meet major incident criteria? → If No: route to standard incident process → If Yes: proceed
- Declare major incident → Notify Major Incident Manager
- Assemble resolver teams → Establish war room
- Investigate and diagnose (parallel: prepare workaround)
- Communicate status to stakeholders (loop every 15–30 minutes)
- Resolution identified → Implement fix or workaround
- Service restored → Confirm with monitoring and users
- Communicate resolution → Close incident record
- Conduct post-incident review → Raise problem record
Organizations that download major incident management process PDFs or PPT templates from industry sources typically adapt this flow to their own criteria and tooling. The exact flow matters less than having one documented and rehearsed before it’s needed.
Major Incident Management Examples
Seeing the process applied to realistic scenarios makes the steps more concrete. Here are two common examples.
Example 1: E-Commerce Platform Outage
At 2:00 PM on a Friday, automated monitoring alerts fire indicating the payment processing service is returning errors for 100% of transactions. The on-call engineer logs the incident, determines it meets major incident criteria (full service outage, direct revenue impact), and declares a major incident. The Major Incident Manager assembles the application and infrastructure teams. Within 20 minutes, the team identifies a failed database connection pool update deployed at 1:45 PM. A rollback is executed by 2:35 PM, service is restored, and an all-clear communication goes to stakeholders by 2:40 PM. A PIR is scheduled for the following Monday.
Example 2: VPN Outage Affecting Remote Workforce
A Monday morning spike in VPN connections causes the VPN concentrators to become unresponsive, preventing 800 remote employees from accessing internal systems. The service desk escalates to major incident within 10 minutes of the first reports. The network team implements a load-balancing configuration change as a workaround within 45 minutes, restoring access for most users. A permanent capacity upgrade is scheduled within the week. The PIR identifies that a known peak-load risk identified three months earlier had not been acted on, and an action item is assigned to the infrastructure capacity planning team.
Tools That Support Major Incident Management
An ITSM platform with strong incident management capabilities is essential for executing this process at scale. A few tools worth considering:
ServiceNow has one of the most mature major incident management modules available. Its major incident management feature (available in ITSM Pro and Enterprise) includes a dedicated major incident workbench, automated stakeholder notifications, and built-in communication templates. For organizations already on the ServiceNow platform, this is the natural choice. The major incident management ServiceNow implementation is well-documented and widely adopted in large enterprises.
Jira Service Management (Atlassian) supports major incident management through its incident management features, with on-call scheduling, alert routing, and incident communication built in. It integrates natively with Jira Software for development teams, which is useful when incidents involve application-layer issues requiring developer involvement.
InvGate Service Management provides incident management with priority classification, SLA tracking, and escalation workflows suited for mid-market organizations. It supports the structured process described in this guide without the complexity overhead of enterprise platforms. Pricing starts at $24.98/agent/month billed annually (5-agent minimum, $1,499/year).
PagerDuty and Opsgenie are purpose-built incident response platforms that complement ITSM tools — they handle on-call scheduling, alerting, and real-time coordination during an active incident, feeding resolution data back into the ITSM platform for record-keeping and reporting.
Frequently Asked Questions
What is the difference between an incident and a major incident?
A standard incident is any unplanned interruption to a service or degradation of service quality. A major incident is a subset — specifically those with high impact and urgency that require a separate, escalated management process. The distinction is usually defined by impact criteria: number of users affected, business criticality of the service, and financial or reputational risk involved.
What are the main stages of the major incident management process?
The core stages are: detection and logging, classification and declaration, escalation and team assembly, investigation and diagnosis, communication management, resolution and service restoration, and post-incident review. Each stage has defined inputs, outputs, and responsible roles. Skipping the post-incident review is one of the most common mistakes — it’s what converts a painful event into a process improvement.
Who is responsible for managing a major incident?
The Major Incident Manager holds overall accountability. This role coordinates all activities, manages stakeholder communications, and ensures the process is followed. Technical resolution is handled by resolver teams (infrastructure, application, network, security). Larger organizations may also have a dedicated communications lead and a service desk liaison during the incident.
How does major incident management relate to problem management?
Major incident management focuses on restoring service as quickly as possible. Problem management focuses on finding and eliminating the root cause to prevent recurrence. They are related but distinct processes. When a major incident is resolved, a problem record should be raised if the root cause is unknown, triggering a formal root cause analysis. The post-incident review is the handoff point between the two processes.
Where can I find a major incident management process document or template?
Many organizations publish their major incident management process documents publicly — university IT departments and government agencies in particular. Searching for “major incident management process PDF” or “major incident management process PPT” will surface a range of templates. ITIL-aligned frameworks from Axelos and process templates from your ITSM vendor are also reliable starting points. The key is to adapt any template to your organization’s specific services, team structure, and escalation thresholds rather than using it verbatim.
Pricing accurate as of the publish date and subject to change. Verify current pricing on each vendor’s official site before purchasing.
Photo by João Victor da Silva Ribeiro on Unsplash
