A critical system goes down for ten minutes. Another remains unavailable for several hours. Which is the Major Incident?
The answer is not necessarily the longer outage. A brief disruption at the wrong moment can have far greater consequences for customers, business operations and organisational risk.
That is why recognising a Major Incident requires more than measuring technical severity. The critical questions are what is at stake, how quickly the consequences could develop and whether the situation demands a coordinated response.
“A Major Incident is an event that causes, or threatens to cause, significant disruption to business operations, services or customer outcomes and requires a coordinated organisational response beyond routine incident management arrangements.”
The MIM® Body of Knowledge treats Major Incidents as organisational events.
A Major Incident may involve unavailable services, degraded performance, unreliable data or a failed dependency. A technical failure is often the first visible symptom; the consequences can reach much further. Customers may be unable to complete transactions, staff may be unable to deliver essential work, suppliers may be unable to fulfil commitments, and commercial or regulatory exposure may grow. Understanding what has failed matters. Understanding what is at stake determines how the organisation needs to respond.
At a Glance
- A Major Incident is defined by actual or threatened organisational disruption and the need for a response beyond routine arrangements, not by a technical label alone.
- Its significance depends on business operations, customer consequences, time sensitivity, organisational exposure and response requirements considered together.
- Declaration activates coordinated leadership and action; restoring a system does not automatically establish business recovery.
What makes an incident major? Look beyond the fault
- Business operations: Which essential activities are interrupted or threatened? Can the organisation still deliver the outcomes required?
- Customer consequences: Who is affected, how severely, and is an effective alternative available?
- Time sensitivity: Will harm escalate quickly, build through a backlog or become material at an approaching deadline?
- Organisational exposure: Which commercial, contractual, regulatory or reputational consequences require attention?
- Response requirements: Does the event demand coordinated authority, expertise and decisions across teams, suppliers or business functions?
These considerations must be assessed together. A short interruption at a critical moment may matter more than a longer outage for which a safe, effective workaround exists.
Why technical complexity and Major Incident status are not the same thing
A routine incident can generally be managed through established support and operational arrangements. A Major Incident requires additional organisational capability because its consequences, uncertainty or response demands warrant it.
A complex technical fault might have limited business impact. A comparatively simple fault might prevent a critical service from operating precisely when it matters most.
Many organisations use labels such as P1 or Severity 1 to prioritise incidents. Those labels are useful only in the context of the organisation’s own classification system. They should connect to clear criteria and response requirements—not replace an assessment of the situation.
Same technology problem. Different organisational consequences.
Consider four hypothetical situations:
A payment service fails at peak trading time. Customers cannot complete purchases, transactions fail and financial exposure increases. Technical recovery must be coordinated with customer communication and business decisions.
A platform stays online but its information cannot be trusted. Availability indicators look healthy, yet employees cannot safely rely on the output. Responders must understand the scope, protect data integrity and validate that the service is usable again.
A critical external supplier loses a dependency. Several internal services are affected, but internal teams cannot restore the dependency themselves. Supplier escalation, an understanding of interdependencies and coordinated recovery become essential.
An internal tool fails, but a safe workaround is available. Essential operations continue. Routine incident arrangements may remain appropriate—unless the workaround becomes unsustainable or the impact grows.The point is not that every disruption requires a Major Incident declaration. It is that similar technical failures can justify very different responses depending on their consequences.
The decision to declare cannot wait for perfect information
Who has authority to declare a Major Incident? What evidence is required? And what happens immediately after declaration? These decisions should be made during preparation, not improvised under pressure.
Effective arrangements include defined criteria, authorised decision-makers, escalation routes and a way to reassess classification as new evidence emerges. Service desk teams, technical responders, business stakeholders and suppliers may all contribute vital signals, even when they do not hold declaration authority.
The technical cause does not have to be known before an organisation recognises that Major Incident capability is needed. Early decisions often have to be made with incomplete information. The requirement is disciplined judgement as understanding develops.
Declaration is the beginning of the response—not the response itself
Declaring a Major Incident should activate the appropriate people, authority, communication and coordination. Opening a bridge call may be part of that process, but it is not the whole response.
The organisation must establish who is directing the response, what is known and uncertain, which outcomes need protection and what the next decisions and actions must achieve. Technical investigation and business assessment should inform that direction together.
In the MIM® Major Incident Lifecycle™, the early establishment of control belongs to Critical First 15™. Sustained response, validated recovery, controlled closure and improvement follow, with activities overlapping where needed.
The system is back. Is the business recovered?
Technical restoration is an important milestone, but it does not automatically mean the disruption is over. Customers may still be unable to complete a journey. Transactions may need reconciliation. Restored capacity may be insufficient to meet returning demand.
Recovery requires evidence that services and business outcomes are usable and sustainable. Closure also requires explicit ownership of outstanding actions, risks and obligations. Some work can continue after active Major Incident governance ends, provided accountability transfers deliberately.
Could your organisation recognise a Major Incident early enough?
The real test of readiness is not simply whether a severity matrix exists. It is whether people can recognise the need for Major Incident capability, understand who can declare it, connect technical signals to business and customer consequences, and know what declaration sets in motion.
Ask - Are our criteria and authority clear? Could we make a sound decision before the technical cause is understood? Would our teams know who needs to act—and how to judge whether the business has genuinely recovered?
Those questions turn a definition into an operational test. Recognising a Major Incident early is what allows an organisation to bring the right capability together when the consequences matter most.
Next: Explore “What Is Major Incident Management?” to understand the organisational capability required, and “The MIM® Major Incident Lifecycle™” to see how that capability operates before, during and after disruption.
Source: Adapted from MIM® Body of Knowledge v4 v1.0, Chapter 1 and Chapters 9–12.
