ITIL Major Incident Management: Process and Roles

Quick answer: ITIL major incident management is a separate, faster procedure for incidents with serious business impact. It needs a clear definition of "major", one major incident manager in charge, a dedicated technical team, updates to the business at fixed intervals, and a review afterwards so the same failure does not return.

When the ERP or the main internet link goes down, most growing companies react the same way. Five people call the same engineer, three start fixing in parallel, the managing director asks for an update every ten minutes, and nobody writes down what was tried. The outage lasts longer than it should, and the same fault returns a month later.

The fix is not a bigger team. It is a simple, agreed procedure that everyone follows when a big failure happens. This guide explains ITIL major incident management in plain terms: how it differs from normal incident handling, who does what, the steps to follow and the numbers to track.

Incident vs Major Incident in ITIL

In ITIL, an incident is an unplanned interruption to a service or a reduction in its quality. A printer that will not print, a failed VPN login and a slow ERP screen are all incidents. The goal of incident management is to restore normal service as quickly as possible.

ITIL 4 treats incident management as a practice, not a rigid set of steps, which helps smaller teams adopt it without heavy tools. It also separates three ideas that are often mixed up:

• Incident: something is broken now and users are affected.
• Service request: a user wants something standard, such as a password reset or a new laptop.
• Problem: the underlying cause of one or more incidents, which needs deeper investigation.

A major incident is an incident with serious impact on the business, one that needs a response beyond the normal process. ITIL does not fix a universal threshold. Each organisation must define its own, in writing, before the next outage.

Point	Normal incident	Major incident
Impact	One user or a small group, usually with a workaround	A core service, a whole site or many users; no workaround
Who leads	Service desk agent or assigned engineer	A named major incident manager
Team	One resolver at a time	A dedicated group pulled from normal work
Communication	Ticket updates to the user	Scheduled updates to users and management
Speed	Normal response and resolution targets	Immediate start, shorter targets, round the clock if needed
After resolution	Ticket closed with notes	Formal review, root cause work and tracked actions

When to Declare a Major Incident

The most common failure is declaring too late. Teams hope the fault will clear in a few minutes and lose the first hour. Write simple triggers so the service desk can declare without asking for permission. Typical triggers are:

• A core business system (ERP, billing, email, core application) is down for all users or for a whole location.
• A customer-facing or citizen-facing service is unavailable.
• A suspected security breach, ransomware or data leak.
• Payroll, statutory filing or another time-bound process is blocked close to its deadline.
• A fault is spreading, for example more sites dropping off the network every few minutes.

Use your priority matrix as the base. Most small and mid-sized teams work well with four levels (P1 critical, P2 high, P3 medium, P4 low), worked out from impact and urgency. A major incident is usually a P1 that meets one of the triggers above. It is better to declare early and stand down than to lose an hour.

ITIL Major Incident Management Roles

You do not need a separate person for every role. In a small company one person may hold two of them. What matters is that the roles are named in advance, with a backup for each.

Role	What the person does	Who it can be in a smaller firm
Major incident manager	Owns the incident from start to finish, coordinates people, takes decisions, keeps time	IT head or senior IT coordinator
Technical lead	Directs the diagnosis and the fix, assigns tasks to engineers	Senior engineer or the vendor's lead engineer
Communications lead	Sends updates to users, management and customers at fixed times	Service desk lead or an admin manager
Service desk	Logs the incident, links related tickets, answers user calls with the agreed message	Helpdesk staff or outsourced helpdesk
Resolver teams and vendors	Network, server, application and supplier engineers who work on the fix	Internal staff and AMC or software vendors
Business owner	Decides on business trade-offs, such as running manually or delaying dispatch	Head of the affected department

One rule keeps this working: the major incident manager does not fix the fault. Their job is to coordinate, so that engineers are left alone to work. If you use an outsourced partner, write the handover points and contacts into the contract; our guide to IT helpdesk outsourcing covers how to split first-line and second-line work.

How to Solve It: The Major Incident Process in 8 Steps

1. Detect and log. The incident arrives from a user call, an email or a monitoring alert. Log one master ticket and link every related ticket to it. Good 24x7 monitoring often raises the alarm before users do.
2. Assess and declare. The service desk checks the triggers. If one is met, it declares a major incident and calls the major incident manager by phone, not email.
3. Assemble the team. The manager names the technical lead and communications lead, and opens one bridge call or chat channel for the technical team. Side conversations stop.
4. Send the first update. Within the first 15 to 30 minutes, tell users and management what is affected, that the team is working on it, and when the next update will come.
5. Diagnose and contain. The technical lead assigns tasks, checks recent changes first, and looks for a workaround that restores service even before the root cause is known.
6. Escalate without delay. If progress stalls, bring in the vendor, the next level of expertise or senior management. Record the time of each escalation.
7. Resolve and verify. Apply the fix, confirm with real users that the service works, and watch it for an agreed period before declaring the incident closed.
8. Review and improve. Hold a review within a few working days. Record the timeline, the cause, what went well, what slowed the team down and the actions to prevent a repeat. Hand the root cause to problem management.

Keep a written log throughout: time, action, person. It takes one person a few minutes and it is the base for the review, for any insurance or audit query and for regulatory reporting.

Communication During a Major Incident

Poor communication does more damage to trust than the outage itself. Three habits fix most of it.

• Fixed intervals. Send an update every 30 or 60 minutes, even if the update is "still investigating". Silence makes people call the engineers.
• One voice. Only the communications lead sends updates. Engineers do not answer questions from management directly during the fix.
• Plain language. Say what is affected, what users should do meanwhile, and when the next update comes. Leave technical detail for the review.

Prepare three short templates in advance: the first notice, the progress update and the closure message. Also keep a contact list (phone numbers, not only email) for the team, vendors and management in a place that still works when the network is down.

If the incident is a security event, extra duties may apply. CERT-In directions require specified cyber incidents to be reported within six hours of being noticed. Our CERT-In 6-hour reporting checklist explains how to prepare.

Metrics and the Post-Incident Review

Track a small set of numbers for every major incident and review them each quarter.

• Time to detect: from the start of the fault to the first alert or call.
• Time to declare: from detection to the major incident being declared.
• Time to restore: from detection to service being back, often reported as mean time to restore (MTTR).
• Updates sent on time: how many scheduled updates went out as promised.
• Repeat incidents: major incidents with the same cause as an earlier one.
• Review actions closed: how many agreed actions were finished by their due date.

These numbers also belong in your service contracts. Our article on managed IT services SLA metrics shows how to write them into an agreement.

The review should be blameless. Ask what in the process, tools or design allowed the failure, not who made the mistake. People who fear blame hide facts, and hidden facts cause the next outage. Where the review shows that recovery took too long, link the actions to your disaster recovery plan.

A Lean Version for Small IT Teams

A 60-person firm does not need the full enterprise set-up. A workable minimum is:

1. A one-page definition of a major incident with four or five triggers.
2. A named major incident manager and a backup, with mobile numbers.
3. A contact sheet for vendors, internet providers and key managers, kept on paper as well.
4. Three message templates.
5. A shared log sheet for time, action and person.
6. A 30-minute review meeting after every major incident, with actions tracked to closure.

Run a short practice drill twice a year. A drill shows the gaps, such as an out-of-date phone number, while nothing is at stake.

Frequently Asked Questions

What is a major incident in ITIL?

A major incident is an incident with serious business impact that needs a coordinated response beyond the normal incident process. ITIL leaves the exact threshold to each organisation, so you should define it in writing with clear triggers.

Who is the major incident manager?

The major incident manager is the single person who owns the incident from declaration to closure. They coordinate teams and vendors, take decisions and make sure updates go out on time. They should not be the person doing the technical fix.

What is the difference between an incident and a problem?

An incident is the interruption itself, and the aim is to restore service fast. A problem is the underlying cause of one or more incidents, and the aim is to find and remove that cause so the incident does not repeat.

How quickly should a major incident be resolved?

There is no universal figure. Set targets based on how long the business can work without each service and on what your team and vendors can deliver. Many teams set a target to begin the response immediately and to send the first update within 15 to 30 minutes.

Do small companies need a major incident process?

Yes, in a lean form. Even a small firm depends on a few systems that stop all work when they fail. A one-page procedure, named roles and a contact sheet are enough to cut confusion and shorten outages.

How Affix Center Can Help

Affix Center is a Mumbai-based IT company that provides managed IT operations and support, including helpdesk, monitoring and incident handling, along with advisory services for IT process design. We can help you define major incident triggers, set up roles and templates, and run the process with your team. To put a working major incident procedure in place, contact our team.