A service goes down. A user calls the service desk. Maybe they are calm. Maybe they are frustrated. Maybe they are absolutely furious because they have a deadline in 20 minutes. Or maybe nobody calls at all. An automated monitoring system notices something has changed. An alert fires. The organization starts investigating and responding before most users ever know anything happened.
That is Incident Management, and it is much bigger than what happens after someone picks up the phone. Incident Management involves people, processes, technology, monitoring, automation, escalation, service levels, Problem Management, continual improvement, and a whole lot of decisions that have to be made while something is going wrong. But underneath all of that is something surprisingly simple: the Incident Model.
Without a model, you may have people responding to incidents, but you don’t have a consistent process for moving an incident from the moment it is detected to the point where service is restored and the incident can be closed. That is what makes the Incident Model so important.
What Is an Incident Model?
An Incident Model is a predefined procedure for dealing with a known type of incident. The model establishes the path people should follow. Depending on the organization and the type of incident, it can define the steps to be taken, the order in which they occur, responsibilities, timescales and thresholds, escalation procedures, and activities such as preserving evidence.
Organizations create and customize their own incident models because incidents don’t all behave the same way. A network outage, a failed printer, and a security-related incident may all enter Incident Management through different routes and require different responses. But the basic idea remains the same: Something happens. We recognize it. We determine what it is. We decide how to handle it. We restore service. We confirm the situation is resolved. And we close the incident.
A practical model might look like this:
Detect → Identify → Log → Categorize → Prioritize → Diagnose → Resolve → Confirm → Close
This is a very basic flow. Some incidents will require additional activities or escalation. The organization determines how its incident models work based on the type of incident, its services, procedures, and circumstances. The model gives us the path. The rest of Incident Management makes that path work.
Detect: Something Has Happened
The first thing we need to know is that something has happened. That sounds obvious, but detection can happen in several ways.
- A service desk representative might receive a call: “I can’t print.”
- A user might submit a portal request or send an email saying they cannot access a service.
- A monitoring system might detect something before the user does. For example, an automated monitoring system may test a network connection and fail to receive the expected response. An alert is generated, and the organization knows something is wrong.
This is where Incident Management starts connecting with other parts of service management. A user report is one source of detection. Monitoring and event management can provide another.
Identify: Is This Really an Incident?
Once something has been detected, we need to identify what actually happened.
- Incident – an unplanned interruption to a service or reduction in the quality of a service.
That definition gives us two important questions:
Was there an unplanned interruption?
Or was there a reduction in quality that meets the organization’s agreed parameters?
That second question matters because “reduction in quality” is not automatically an incident. It depends on what the organization has agreed the service should provide.
This is where service levels become important. If a service is supposed to perform within clearly defined, achievable, negotiated parameters, those parameters help determine whether a degradation has crossed the line into an incident.
Service Request or Incident?
A service request is different from an incident.
- Service Request – a request from a user or a user’s authorized representative that initiates a service action which has been agreed as a normal part of service delivery.
For example, “Can I have access to that printer?” is a service request. The person is asking for something they do not currently have.
“I had access to that printer yesterday, and now I can’t print” is an incident. Something that previously worked has stopped working.
The distinction matters because the two situations follow different paths. A request is fulfilled. An incident is managed toward restoration of service. That may seem black and white, but what about this?
“I can’t access Service A.” That’s right, Jenny. You’re not supposed to have access to that service because you’re not an authorized user. You’re not in the required security group. That’s not an incident; that’s a service request that was denied because you don’t have the required access.
Event or Incident?
An event can also look like an incident.
- Event – a change of state that has significance for the management of a service or other configuration item.
All Incidents are events, but not all events are incidents. Monitoring might report that disk utilization has reached 85 percent. That’s an event by itself. It’s known as an information event. Nothing about this “change of state” implies it caused an unplanned interruption or a reduction in the quality of service.
Problem or Incident?
Problems and incidents are related, but they are not the same thing.
- Problem – a cause, or potential cause, of one or more incidents.
Incidents do not become a problem. Problems are the cause, and incidents are the symptoms. It is possible to have a problem with no active incidents.
Proactive Problem Management is heavily involved with Incident Management. Problem Management is an in-depth, separate best practice, so we will just say that knowing the difference between the two can be hard and Problem Management guidance can assist in understanding the difference.
Log It. Seriously, Log It.
Once you’ve identified something as an incident, log it.
It can be tempting to skip the paperwork when the solution is obvious. For instance, a user calls because a printer isn’t working. You discover it is out of paper, you put paper in it, and the user prints. The issue took 30 seconds to fix.
Why bother logging it? Because one incident means something very different from 47 incidents involving the same printer in three months. Incident records become data that can support:
- Trend analysis
- Recurring-incident identification
- Problem Management
- Continual improvement
- Service-provider evaluation
- Training and development
- Decisions about where resources are being wasted
- Identifying patterns that an individual service desk interaction would never reveal
Sometimes it can literally take longer to document the incident than to fix it. Log it anyway; this data is foundational for operational insight. It is also critical to proactive Problem Management.
Categorize
Categories are organization-specific and group issues. Some common categories could be as simple as Security, Hardware, Software, Network, Access, Application, or User error.
What are these used for? Why do we care? Suppose Bob calls because he can’t print. You investigate and discover that Bob forgot to turn the printer on. You don’t tell Bob: “Congratulations, Bob. Your incident is categorized as User Error.” That’s internal information. The category exists so the organization can understand its incidents and analyze the data later.
The Initial Category Is Not Permanent. Categorization isn’t necessarily a static, one-time guess. As more information becomes available during diagnosis and troubleshooting, the incident may need to be recategorized to ensure accurate tracking and routing.
Categorization helps organizations analyze their incidents later. If hundreds of incidents are being logged under a particular category, that information can become useful for Problem Management, reporting, trend analysis, and continual improvement.
Prioritize
Once an incident has been categorized, we need to determine how quickly it needs to be handled.
Not every incident can be handled immediately. A common organizational approach is to determine priority using two variables:
Priority = Impact + Urgency
- Priority – is determined according to the organization’s agreed criteria. A user should not be able to simply declare, “This is my highest-priority incident.”
- Impact – considers how much of the organization, service, or user population is affected.
- Urgency – considers how quickly the situation needs to be addressed.
For example, three people being unable to print might have relatively low impact. If those three people are casually printing something tomorrow, the urgency may also be low.
But if those three people are responsible for printing payroll checks on Friday morning, the urgency is very different.
Service Levels and Priority
This is another place where service levels matter.
Organizations establish expectations for how incidents will be handled, including response and resolution targets where applicable. Those expectations help the service desk determine how quickly an incident needs to move through the process.
Time scales can include response times, escalation thresholds, restoration targets, and expectations for follow-up updates. These should be established in advance through the organization’s service-level agreements and support arrangements.
And faster service has a cost.
If an organization wants immediate response from specialists, vendors, managers, or other resources, those resources have to be available. The service level and the cost of providing that level of service need to be understood and agreed upon.
Diagnose
Now we need to determine what is happening and what we can do about it.
Diagnosis often involves using the knowledge base, previous incidents, known information, troubleshooting procedures, and specialist expertise.
“Resolving an Incident Does Not Necessarily Mean Fixing the Problem.”
This is one of the most important distinctions in Incident Management.
Imagine Bob’s printer has failed. The technician determines that a replacement part is required, but the vendor says the part will take two weeks to arrive.
Does Bob have to wait two weeks before the incident can be resolved?
No.
The objective of Incident Management is to restore service. The technician might be able to redirect Bob to another printer so he can continue working.
Bob confirms that he can print from the other printer.
His service has been restored.
The original printer is still broken.
That underlying issue may become something for Problem Management to address.
What Happens If We Can’t Resolve It?
Sometimes the service desk cannot resolve an incident themselves. Whenever possible, resolving an incident at first touch is valuable because it restores service quickly and avoids unnecessary handoffs. But some incidents require escalation.
First-touch resolution does not mean every incident must be resolved by the service desk. It means the incident should be resolved at the first appropriate point when the necessary knowledge, authority, and resources are available.
Functional Escalation
A functional escalation occurs when the incident needs to be handled by another level of expertise.
The service desk may need to escalate the incident to a specialist team, a higher support tier, a vendor, or another function with the knowledge or authority required to resolve it.
Hierarchic Escalation
A hierarchic escalation is different.
Sometimes the person handling an incident has the technical knowledge to resolve it but does not have the authority to make a particular decision or exception. For example, imagine the CEO calls the service desk with a relatively low-impact, low-urgency incident but wants an exception made immediately. The service desk representative may not have the authority to make that decision. The incident may need to be escalated to a manager who does. This is also where service-level decisions become important. If an organization expects special handling for executives or other groups, that expectation needs to be understood when service levels and support arrangements are established.
Keep Ownership Through the Handoff
Escalation does not have to mean abandoning ownership. A service desk representative who initially takes responsibility for an incident may continue to own it while another team works on the technical resolution. That helps prevent the classic problem of everyone assuming someone else is handling it. The specialist may own the technical work. The original representative may continue to own the incident from the service desk perspective and keep the user informed.
Major Incidents
Some incidents have enough business impact that they require a much more coordinated response.
- Major Incident – an incident with significant business impact, requiring an immediate coordinated resolution.
The important point is that there is no universal number of affected users that automatically makes something a major incident. One organization might define a major incident as affecting 100 users. Another organization might have a service used by a million people and use completely different criteria. The organization determines its own criteria based on business impact and its services.
Consider the payroll printer again. If the printer fails on a normal Tuesday, it may be handled as a regular incident. If the same printer fails on the morning payroll must be processed, the business impact and urgency may be dramatically different.
A major incident may require an Incident Manager or another designated person to coordinate the response while multiple teams work together to restore service as quickly as possible.
Resolve
Eventually, we need to restore the affected service.
- Resolution – the action of solving an incident or problem.
Resolution can involve a permanent repair, a workaround, redirecting users to another service or resource, or another action that restores normal service.
The important question is whether the user or business can return to normal service delivery—not whether every underlying technical issue has permanently disappeared.
Confirm
Once service has been restored, the organization needs to determine whether the incident is actually resolved from the user’s perspective.
Organizations may require confirmation from the user before closing an incident, particularly when the incident was reported through email, a portal, or automated monitoring.
If a service desk representative is speaking directly with the user on the phone, confirmation is straightforward.
If the incident was reported through email, a portal, or monitoring, the organization may have a defined procedure for attempting to confirm restoration and determining what happens if the user does not respond.
Close
Once the incident has been resolved and the organization’s closure requirements have been met, the incident can be closed.
But closure is not necessarily the end of the value of that incident record.
Incident information can feed Problem Management, risk management, operational improvements, continual improvement, knowledge management, and service reporting.
Imagine the organization discovers that incidents are repeatedly being reassigned between teams before anyone resolves them. That pattern may indicate a problem with categorization, knowledge, escalation procedures, training, or the support structure itself.
The incident record gives the organization evidence that something is happening. The organization can then use that information to determine whether something needs to change.
Why the Incident Model Matters
The Incident Model gives us directions for consistency in procedure.
It helps make sure we do the right thing at the right time. It makes sure we have the documentation we need, that we are following the rules, and that we are working within the established timescales. And it can keep us from making things worse.
When something is already going wrong, the last thing we want is for everyone to start doing something different, skip an important step, miss a required escalation, or make a decision without the information they need.
The Incident Model gives people a path to follow.
It provides consistency while still allowing the organization to account for the type of incident, the service involved, and the circumstances surrounding it.
That is the value of an Incident Model: giving people clear directions for what to do, when to do it, and what needs to happen next.
Ready to Go Further with Incident Management?
How far you want to take your Incident Management knowledge depends on where you are starting and what you need to accomplish.
Starting with ITIL?
If you are new to ITIL or want a broader foundation in IT service management, ITIL 5 Foundation is the place to start. It provides the foundational understanding of ITIL and the practices used to manage and improve IT-enabled services.
Want to focus specifically on Incident Management?
If you already have the basics and want to develop a deeper, practical understanding of Incident Management, the Incident Management: Hands-On ITSM Workshop takes a closer look at how the practice works in real-world environments, with practical exercises and application.
Want to understand the bigger operational picture?
Service Operations Practitioner Training goes beyond Incident Management to explore how the practice interacts with related practices such as Problem Management, Service Desk, Monitoring and Event Management, Service Request Management, and other operational activities. It is a deeper dive for professionals who want to understand how the pieces work together in day-to-day service operations.
Choose the path that fits where you are now:
ITIL 5 Foundation → Incident Management: Hands-On ITSM Workshop → Service Operations Practitioner Training
You don’t necessarily need to take all three. Start with the level that matches your experience and goals, then continue deeper as your knowledge and responsibilities grow.