Major Incident Management

What is a major incident?

A major incident is significant disruption that needs a coordinated response beyond normal incident handling. It is declared when the scale, impact, or uncertainty of an outage means the organisation must mobilise quickly, communicate widely, and restore service under visible leadership.

This is not the same as priority. Priority tells you how urgently a ticket should be worked. A major incident is a management mode: a deliberate decision to run a structured response with clear ownership, stakeholder communication, and recovery coordination. A priority 1 incident may not require major incident procedures. An incident with a lower priority can still be declared major if business impact, breadth of effect, or reputational risk warrants it.

When to declare a major incident

Organisations should define clear criteria in advance so the decision is made quickly and consistently under pressure, not debated while service remains impaired. Typical triggers include:

• widespread loss of a critical service or multiple dependent services
• significant financial, regulatory, or customer impact
• unclear ownership or the need to pull expertise from several teams at once
• sustained disruption where normal escalation is not moving recovery forward
• reputational risk or executive attention that needs structured communication

The declaration should be made by someone with authority to mobilise people and resources, not left to the ticket queue to infer from priority alone.

How a major incident should be handled

Once declared, the focus shifts from routine ticket progression to coordinated recovery. Technical teams still diagnose and fix; the major incident response adds structure around that work so effort is focused and stakeholders stay informed.

A disciplined major incident response typically includes:

• Incident Manager ownership - one person coordinates the response, chairs recovery activity, and keeps decision-making visible
• Technical recovery team - subject matter experts work the problem without also carrying comms, logistics, or stakeholder management
• Structured communication - regular, factual updates to business and technical stakeholders; separate channels for recovery work and for status reporting
• Clear roles and escalation paths - who decides on workarounds, who approves risk, and how further expertise is brought in
• Recovery before root cause - restore service first; detailed investigation and problem records follow once impact is contained
• Controlled stand-down - confirm service is restored, agree when the major incident is over, and hand off to closure and post-incident review

After service is restored

Major incidents should always produce a post-incident review. The purpose is not blame, but clarity: what happened, what worked, what slowed recovery, and what should change in process, tooling, or readiness. Findings feed problem management, change, and improvement activity so the same failure is less likely to hurt the business again.

These example documents showcase our approach to major incident management and post-incident review - structured response, clear communication, and analysis that leads to lasting improvement.

Incident management overview

Major incident management sits within the broader incident management practice - from identification and triage through to closure and learning.