The IT manager’s guide to major incident management

When email goes down for 2,000 employees, the outage isn't the service desk's only problem. Within minutes, dozens of tickets can arrive describing the same failure. Someone has to recognize the pattern, declare the incident, pull in the right technical team, and keep everyone else informed.

That's why major incident management (MIM) needs to be more involved than setting a ticket to P1. It needs a separate response process with predefined triggers, clear ownership, faster escalation, and its own communication cadence.

The difference becomes obvious when the ticket queue starts filling up. Your service desk shouldn't be spending 30 minutes telling 80 employees that email is still down. That’s why this guide explains what you need to create your own MIM protocol.

The five stages of major incident management

MIM moves an outage through identification, escalation, communication, resolution, and review. The exact workflow will vary by organization, but the important part is that ownership and escalation paths are decided before anyone needs them.

To see how that works in practice, we'll follow one example incident: It’s 10:15 a.m. on a normal workday, and the company email system has gone down.

1. Identification and declaration

Identification is the point where the team recognizes that an issue meets its predefined criteria for a major incident based on incident severity levels. The signal might come from monitoring or a critical system owner; a sudden spike in related tickets can be just as telling.

Declaration is the decision that follows. Someone with the authority to declare a major incident activates the MIM process and takes the issue out of the standard incident workflow.

Email outage: Within 15 minutes, the service desk receives dozens of reports that employees can't send or receive email. The on-call lead recognizes the pattern and declares a major incident.

2. Escalation and team assembly

Escalation means bringing in the right people to restore service immediately. The major incident manager coordinates that response and gives technical teams a dedicated place to work.

Email outage: The major incident manager pulls in the messaging infrastructure team. They open a dedicated Slack channel and notify IT leadership.

3. Communication with stakeholders

Major incident communication runs alongside the technical response. Responders need technical updates, leadership needs business impact, and affected employees need to know what's happening and when they'll hear more.

A defined cadence keeps those conversations from interrupting the people working on the outage.

Email outage: The incident manager sends the first leadership notification and posts an employee-facing update. They set a 30-minute cadence for further updates.

4. Investigation and resolution

The response team investigates the issue and identifies a safe fix or workaround. Restoring service takes priority during the active incident; deeper root cause analysis can continue afterward.

Email outage: The team traces the failure to a mail server configuration pushed that morning. They roll it back and confirm that employees can send and receive email again.

5. Post-incident review

After restoring service, the team reviews the incident while the details are still fresh. This is an important part of the broader service management lifecycle, not an optional debrief once the “real” work is done.

The team should run a blameless review of what happened and how the response went within 48 hours, documenting the timeline and identifying what needs to change before the next incident.

Email outage: The review finds that testing didn't catch the faulty configuration. The team adds a validation step to the deployment process and updates the MIM runbook.

Common mistakes in enterprise major incident management

The biggest mistakes tend to show up when teams have to use the MIM process for a real incident.

No predefined criteria for what counts as major

If the only trigger is “this feels serious,” teams will make different calls under pressure. Some high-priority incidents will get unnecessary MIM treatment while actual major incidents sit in the standard queue for too long.

Solution: Define the threshold in advance using factors like business impact and service criticality. SLA risk can also inform the decision.

Using the standard incident workflow

A major incident shouldn't compete with password resets and access requests for attention. Once declared, it needs to bypass the normal queue and follow its own escalation path.

Solution: Give major incidents a separate response track with their own escalation path and ownership. That gets the right people involved without waiting for standard handoffs.

Letting duplicate tickets overwhelm the service desk

When 200 employees report the same outage, answering 200 tickets individually is wasted effort.

Solution: An AI help desk can help identify related reports and keep requesters informed about a known incident. Responders can then send automated updates to everyone affected.

Best practices for enterprise major incident management

The middle of an outage isn't the time to discover that an escalation contact left six months ago. (Or that nobody knows where the latest runbook lives.) The best major incident management processes keep response teams prepped and ready.

Run tabletop exercises

A process can look complete on paper and still break down under pressure. Run tabletop exercises around incidents your organization could realistically face, then follow the response from declaration through communication and restoration. You'll quickly find unclear ownership, missing contacts, or steps that made sense when the runbook was written but don't anymore.

Keep runbooks current and accessible

During an outage, responders need to have the right information on hand. Use enterprise knowledge management to keep escalation paths, MIM criteria, communication templates, and runbooks accessible in one place. Update that material after tabletop exercises and real incidents so responders can trust what they find.

Plan for the ticket flood

Instead of treating duplicate reports as an unexpected side effect of a major incident, build them into the response plan. Link related tickets to the active incident, and notify requesters should you already know about the issue.

As the situation changes, the service desk should be able to update everyone affected at once. This saves time and allows the team to focus on restoring service.

How Serval keeps the service desk focused during a major incident

A major incident can turn one outage into hundreds of tickets. Serval helps IT service management teams manage that volume without answering every report individually.

Before a major incident is even declared, Serval groups duplicate incident reports under the first one filed. It also evaluates each high-priority incident based on how critical the affected services are and proposes promoting it to a major incident, with an optional approval step so a person can make the final call.

Serval's Help Desk Agent detects new tickets related to a major incident, links them, and tells each requester IT is on it. The service desk can broadcast one update to every linked ticket, and resolving the major incident closes every linked report.

By using AI to resolve routine requests that continue arriving during the outage, Serval also keeps more repetitive work off the service desk. Serval doesn't run the technical fix; that stays with your responders and on-call tools. It handles the ticket volume and communication around it, so responders stay focused on restoring service.

Book a demo today to see Serval in action.

FAQ

How does ITIL approach major incident management?

In ITIL, major incident management falls under the broader Incident Management practice, which focuses on restoring normal service as quickly as possible after a disruption. According to ITIL, a major incident has a significant business impact that requires an immediate, coordinated resolution.

Instead of relying on a universal definition of major incidents from ITIL, establish clear criteria for what qualifies as “major” based on your organization’s services, risks, and business needs. Those criteria give teams a consistent way to recognize major incidents and activate the right response.

What should be included in incident response documentation?

Document the incident timeline, how it was detected, who was involved, and the actions taken to restore service. Include communication sent during the response and any follow-up actions identified during the post-incident review.

How can teams help prevent incident recurrence?

Start with the post-incident review. Identify what caused the incident and which controls failed to catch it earlier. Then turn those findings into specific changes, such as stronger deployment validation, better monitoring, or an updated MIM runbook. Assign an owner to each action so the review leads to an actual change.