Major incident management: the process, roles and communication plan

The short version: A major incident is an incident with such a high business impact that it needs a separate, faster process than normal tickets. The process is: declare it, assemble a team under one incident manager, communicate on a fixed schedule, restore service first, and then review it. Finding and removing the root cause is a different job, handled afterwards by problem management.

Most IT incidents are routine. A user cannot print, a laptop is slow, a password needs resetting. A few are not: the email system is down for everyone, the main office has no network, or a payment system has stopped. These need a different way of working. This guide explains what a major incident is, how to run one step by step, who does what, how to communicate, and where the line is between incident management and problem management.

We used the Atlassian guides to IT incident management and to problem management for the terminology. Atlassian notes that teams following ITIL or ITSM practices use the term "major incident" for an incident that needs an emergency response, and it quotes the ITIL definition of a known error as a problem that has a documented root cause and a workaround. We read both on 28 October 2026 (checked 2026-10-28). The thresholds and timings below are examples to adapt, not an industry standard.

What is a major incident?

Atlassian describes incidents as events of any kind that disrupt or reduce the quality of a service, or threaten to. A major incident is one where the business impact is high enough that the normal queue-based handling is not good enough. There is no universal number, because "high impact" depends on the business, so you have to define it in advance.

Typical triggers are:

• A core service is down for many users or for a whole site: email, the network, the identity system, the ERP, the customer portal.
• A system that earns money or protects safety has stopped.
• A security event with real consequences, such as ransomware or a suspected account takeover of an administrator.
• A failure affecting several customers or locations at once.
• A smaller outage that has run on longer than its priority allows.

A major incident is not simply a P1. Many organisations have several P1 tickets open at once without invoking the major incident process. The difference is that a major incident needs people from several teams working together under one coordinator, with leadership kept informed.

The priority itself comes from impact and urgency. Our article on severity vs priority explains how to set it, and the P1 to P4 guide shows what each level means in practice.

How do you decide when to declare a major incident?

Write the declaration criteria down and make them easy to apply under pressure. A short checklist works better than a long policy.

1. The service affected is on the list of critical services, or more than a stated number of users or sites are affected.
2. There is no workaround users can reasonably apply.
3. The expected impact is serious: lost revenue, safety, legal or contractual consequences, or damage to reputation.
4. The first engineer cannot fix it within a short time limit, for example 30 minutes, or has no way to estimate when it will be fixed.

Anyone on the service desk should be allowed to propose a major incident, and one named person (usually the on-duty incident manager) should be able to confirm it. Declaring a major incident that turns out smaller is cheap. Failing to declare a real one for an extra hour is not.

What are the steps of the major incident management process?

Here is a process that works for small and mid-sized IT teams, in order.

1. Detect and log. A monitoring alert, a call or several similar tickets reveal the problem. Log it with the time it started, what is affected and who reported it.
2. Declare. Apply the criteria, name the incident, and open a single incident record that everything attaches to. Use one shared channel or call, for example a bridge call and a chat room.
3. Assign the incident manager. One person owns coordination. They do not do the technical work.
4. Assemble the response team. Pull in the technical leads for the affected area, plus anyone who can speak to the vendor, the network carrier or the business.
5. Assess the impact. Who cannot work, what business process has stopped, and what is the business deadline?
6. Restore service first. Choose the fastest safe route back to a working service: roll back a change, fail over, restart, apply a workaround. Do not spend the outage hunting for the perfect explanation.
7. Communicate on a schedule. Send updates at agreed intervals, whether or not there is news. More on this below.
8. Confirm recovery. Test with real users or a business owner, not just a green dashboard.
9. Close the incident and hand over. Record the timeline, the workaround and the open questions, and pass the root cause investigation to problem management.
10. Review. Hold a post-incident review within a few working days, while memories are fresh.

The key principle is that restoring service and understanding the cause are two separate activities. Mixing them lengthens the outage.

Who does what in a major incident?

Keep the roles few and clear. In a small team one person may hold two roles, but the incident manager should not also be the one fixing the fault.

• Incident manager: runs the bridge, decides priorities, keeps the timeline, and makes sure nothing blocks the technical team.
• Technical lead: directs the diagnostic and repair work and tells the incident manager what is known, unknown and being tried.
• Communications lead: writes and sends the updates, so engineers do not have to. In a small team this can be the incident manager.
• Subject experts: the engineers working on the specific system, network, security or application.
• Business or customer representative: confirms the impact, the business deadline, and when service is acceptable again.
• Scribe: records timestamps, decisions and actions. This is the raw material for the review.

If your IT is outsourced, agree these roles with your provider in advance, including who from your side can authorise a failover or an emergency change. Our guides on L1, L2 and L3 support levels and the escalation matrix cover who gets called and when.

How should you communicate during a major incident?

Silence causes more damage than bad news. People who do not hear anything assume nobody is working on it, so they keep calling and escalating, which takes engineers away from the fix.

1. Send a first notice quickly. Say what is affected, the time it started, that you are investigating, and when the next update will come. Do not wait to know the cause.
2. Set a fixed cadence. For example, every 30 minutes for a critical outage, adjusted to the situation. Send the update on time even if the content is "no change, still investigating".
3. Use plain language. Say what users can and cannot do, and any workaround. Avoid internal ticket numbers and jargon.
4. Keep a single source of truth. One channel, one status message, one owner. Do not let three people send three different estimates.
5. Be careful with estimates. Give a time for the next update, not a promised fix time, unless you are confident.
6. Send a recovery notice. Say what was restored, what users should check, and that a review will follow.
7. Follow up after the review. Share what happened and what will change, in a short summary.

Match your audience: leadership needs impact and business consequence, users need what they can do now, and technical teams need detail.

What is the difference between incident management and problem management?

This is the most common confusion, and the answer is the goal of each.

• Incident management restores normal service operation as quickly as possible. It is about speed and minimising impact. A workaround is a success.
• Problem management finds and addresses the underlying cause of incidents so they do not recur. It is about depth and prevention. A workaround is only an interim step.

Atlassian describes problem management as the process of identifying and managing the causes of incidents on an IT service. A known error is a problem with a documented root cause and a workaround.

Compare them on a concrete case. A file server runs out of disk space on Monday morning and nobody can open shared files.

• Incident response: clear disk space or add capacity, confirm users can open files, and close the incident.
• Problem investigation: find out why the disk filled, whether a backup job, a runaway log or a user copying large files was responsible, and why monitoring did not warn anyone. Then add alerts, quotas or capacity so it does not happen again.

The two connect. A major incident usually leads to a problem record, and several similar incidents can be linked to one problem. If the root cause is not found, the workaround should be written into the known error record so that the next engineer can restore service faster.

How do you run the post-incident review?

The review should be blameless: the aim is to improve the system, not to find someone to criticise. Cover the following.

1. A timeline from first symptom to full recovery, with the times of detection, declaration, key decisions and restoration.
2. What worked well, what slowed the response, and what was luck.
3. The business impact, described in plain terms.
4. The cause as far as it is known, and what is still unknown.
5. Actions with a named owner and a due date, entered as problem records, change requests or monitoring improvements.
6. Whether the declaration criteria, roles and contact lists need updating.

The timeline also gives you real measurements for the averages described in our guide to MTTR, MTBF and MTTA. If the incident involved data loss or a long restore, compare the result with your targets in RTO vs RPO.

What should you prepare before the first major incident?

Preparation is where most of the benefit comes from.

1. Define what counts as a major incident and who may declare one.
2. Keep an up-to-date contact list for your team, vendors, carriers and key business owners, available when your systems are down (for example, on paper or in a phone).
3. Create templates for the first notice, update and recovery messages.
4. Set up a standing channel or bridge number, so nobody has to invent one under pressure.
5. Document the critical services, their owners and their dependencies.
6. Agree emergency change rules in advance, so the fix is not delayed by approval.
7. Run a short practice exercise at least once a year.

If you outsource IT, ask your provider for their documented major incident process and the contact path. Brocent's SLA page publishes response targets by priority, and the managed IT support plans and per-user pricing shows the managed IT support list prices and a 15-minute first response on critical incidents within the service window in your contract. If you want to discuss a major incident process for your own environment, contact us.

Frequently asked questions

What is a major incident in ITIL?

In ITIL and ITSM practice, a major incident is an incident with significantly high business impact that is handled through a separate, faster process than standard incidents. The exact threshold is defined by each organisation, not by ITIL.

What is the difference between a major incident and a P1?

A P1 is a priority level on a single ticket. A major incident is a way of responding: several teams, one coordinator, and structured communication. Many P1 tickets can be handled in the normal process. A major incident process is for those that need coordination across teams.

What does a major incident manager do?

The major incident manager coordinates the response. They run the bridge, assign tasks, keep the timeline, handle escalation, and make sure communications go out on schedule. They usually do not do the hands-on technical fix.

What is the difference between incident management and problem management?

Incident management restores service quickly, even with a workaround. Problem management investigates the root cause and removes it so the incident does not return. A major incident normally ends with a problem record.

How often should we send updates during a major incident?

Agree a cadence at the start, for example every 30 minutes for a critical outage, and keep to it even when there is no news. The right interval depends on how severe the incident is and how fast things are changing.

Do small businesses need a major incident process?

Yes, in a lighter form. A one-page process with declaration criteria, a named coordinator, a contact list and message templates is enough to start. The need is greater for a small team, because the same few people both fix and communicate.

Who should lead the review after a major incident?

Someone who was not the main person fixing the fault, often the incident manager or a service owner. A neutral lead makes a blameless discussion easier and keeps the focus on actions.

Want these targets in a contract, not a slide? Brocent's managed IT support plans publish the SLA and the per-user monthly price side by side for Hong Kong, Singapore, mainland China and the United States. See the plans and pricing or talk to a consultant.