Incident Management Process: The Lifecycle from Report to Closure, with Roles and Time Limits

The short version: An incident management process takes a reported disruption from first report to closure in a fixed sequence: detect and log, categorise, prioritise, diagnose, resolve, and close. The goal is to restore normal service quickly and limit business impact. Each step needs an owner, a rule for moving on and a time limit, and every ticket should carry enough notes that the next person never has to ask the user again.

This guide is for IT managers and service desk leads who want to set up, or tidy, the day-to-day incident process for a small or mid-sized organisation. After reading it you can write down the steps, name the roles, set time limits and use a ticket template. Major incidents, the rare large outages, follow a separate process described in major incident management; this article covers the ordinary lifecycle.

What is an incident?

ITIL 2011 defines an incident as an unplanned interruption to an IT service, a reduction in its quality, or a failure of a configuration item that has not yet affected a service, according to the Wikipedia summary of incident management (checked 28 October 2026). The same article says the process aims to restore normal service operation as quickly as possible and minimise the business impact.

ITIL 4, released in February 2019, organises its guidance as practices rather than processes, so you may see this called the incident management practice there; the steps below are common service desk practice and make no claim of ITIL alignment (checked 28 October 2026).

Two points follow:

1. Restoring service comes first. Finding the root cause is a different process (problem management). An incident can be closed with a workaround.
2. A request is not an incident. A new starter laptop or an access request is a service request, handled in its own flow. Our guide on service request vs incident draws the line.

The six steps

Guides count these steps differently. You will see five, six or seven, depending on how they group detection, logging and classification. The sequence below is the same in practice. Use whichever grouping your team can remember.

Step 1: Detect and log

Goal: every incident becomes a ticket with a number.

1. Accept reports from every channel: portal, email, phone, chat, and automatic alerts from monitoring.
2. Create the ticket at the first contact, before you start fixing.
3. Capture who is affected, what service, what they see (with the exact error text or a screenshot), when it started and how to reach them.
4. Check for duplicates and known issues. If an outage is already open, link the new ticket to it.

Owner: service desk (L1). Example limit: log within minutes of contact.

Step 2: Categorise

Goal: put it in the right bucket so it reaches the right people.

1. Choose a category and subcategory from a short, fixed list: for example email, network, device, application, account access, security.
2. Link the affected service and configuration item (the device or system) if you track them.
3. Flag possible security incidents at this point and send them to the security route straight away.

Owner: service desk. Keep the category list short; long lists are filled in badly.

Step 3: Prioritise

Goal: decide how fast it needs attention.

1. Set impact, how many people or how much of the business is affected, and urgency, how soon the business needs it fixed.
2. Take the priority from your impact and urgency matrix. Severity and priority are not the same thing, and the usual P1 to P4 levels each map to a response target.
3. Let the service desk change the priority when facts change, and write down why.

Owner: service desk, with the incident manager for the top levels. Limit: priority is set before the first response target starts counting.

Step 4: Diagnose and investigate

Goal: find a fix or workaround.

1. Initial diagnosis at L1. Use the knowledge base and scripts. Ask questions that the ticket does not already answer. If it is a known fix, apply it.
2. Escalate when the issue is outside L1's scope, when a time limit passes, or on risk (data loss, security, wide impact). Use L1, L2 and L3 levels to say who does what, and the escalation matrix template for contacts.
3. Write a handover note at each escalation: what is affected, what was tried and what is needed next.
4. Keep the user updated at the interval agreed for that priority, even when there is nothing new, and say when the next update will come.
5. Vendors: open a vendor case when the cause looks like a product fault, and record the case number on the ticket.

Owner: L1 first, then L2 or L3 or the resolver group. Example limit: if no progress by the escalation time for the priority, move up.

Step 5: Resolve and recover

Goal: the service works again for the user.

1. Apply the fix or workaround. For changes that go beyond the standard, use change control; emergency changes follow the emergency route.
2. Confirm with the user that it works, not just that the system looks fine.
3. Record the resolution: what was done, why it worked, and whether it is a workaround or a permanent fix.
4. If the cause is unknown or the fix is only a workaround, raise a problem record so the cause is investigated later.
5. Set the ticket to "resolved" and tell the user.

Owner: the person who fixed it. Limit: the resolution target for the priority.

Step 6: Close

Goal: a clean, searchable record.

1. Confirm with the user or auto-close after a set period with no reply. A common starting point is a few working days; set your own and tell users.
2. Check the record: category correct, resolution written, time spent logged, linked records attached.
3. Update the knowledge base if this ticket taught something.
4. Close. A closed ticket is reopened by a new ticket or a follow-up inside the agreed window.

Owner: service desk. Many teams also sample closed tickets each month for quality.

Roles

Small teams combine roles. The point is that someone owns each.

1. Requester or user: reports the incident, answers questions, confirms the fix.
2. Service desk agent (L1): logs, categorises, prioritises, applies known fixes, keeps the user informed.
3. Resolver (L2, L3 or a specialist team): diagnoses and fixes beyond L1.
4. Incident manager (or service desk lead): watches the queue and time limits, takes ownership of stuck or high-priority tickets, and runs escalation. For major incidents this role is described in the separate guide.
5. Problem manager: takes over when the cause needs investigating.
6. Change manager or approver: approves fixes that need a change.
7. Service owner and vendors: supply decisions and support for their service or product.

Example time limits

These are illustrative targets, not standards. Your SLA sets the real values. Brocent's published response targets are on the SLA page.

1. P1 (critical), for example: respond in minutes, update the user often, escalate immediately if not progressing, and keep working until restored.
2. P2 (high): respond within the hour, escalate if unresolved after a short, set period.
3. P3 (medium): respond within the working day, resolve within days.
4. P4 (low): respond within a day or two, resolve as capacity allows within a longer window.

Define three clocks: time to respond, time to escalate, and time to resolve. Pause the resolve clock only for defined reasons, such as waiting for the user.

A ticket template

A good ticket has these fields. Copy them into your tool.

Summary:         one line, symptom + service
Requester:       name, contact, location
Affected:        how many users, which service/device
Symptom:         user's words, exact error, screenshot
Started:         date/time, what changed before
Category:        category / subcategory
Impact/Urgency:  H/M/L each -> Priority
Actions taken:   step, result, who, time
Escalated to:    team/person, reason, time
Next update due: date/time
Resolution:      what fixed it, workaround or permanent
Problem record:  yes/no, ID

Common mistakes

1. Fixing before logging. Quick fixes with no ticket vanish from reports and from the knowledge base.
2. Priority by volume, and silence. Do not let the loudest voice set the priority; use the impact and urgency rules. Send updates on schedule, because users forgive delays more readily than lack of news.
3. Closing without confirmation, which leads to reopened tickets and unhappy users.
4. No handover notes, so the user answers the same questions at every level.
5. Treating workarounds as final. Raise a problem record when the cause is unknown.
6. Mixing requests with incidents, which distorts your numbers and your SLA.

How to check it worked

1. Pick five closed tickets at random. Each should show who, what, when, steps taken, resolution and times.
2. No open ticket is past its escalation time without a note.
3. Users are updated on the schedule you set.
4. Monthly numbers make sense: incident volume by category, time to respond and resolve by priority, reopen rate. For definitions, see MTTR, MTBF and MTTA.
5. Repeat incidents lead to problem records and knowledge articles.

FAQ

What is the incident management process?

It is the set of steps that takes an IT disruption from report to closure so that service is restored quickly and business impact is limited: log, categorise, prioritise, diagnose, resolve and close.

What are the steps of the incident management process?

Detect and log, categorise, prioritise, diagnose and investigate, resolve and recover, then close. Some frameworks split or merge steps, so you may see five, six or seven in different guides.

What is the 5 step incident management process?

A common five-step grouping is: identify and log, categorise and prioritise, investigate and diagnose, resolve and recover, close. It is the same sequence as the six steps with two of them merged.

What are the 6 steps in the incident management process?

Log, categorise, prioritise, diagnose, resolve, close. Grouping varies by source, so choose the version your team can apply consistently.

Next step

To see the response targets we publish for each priority level, read our SLA page.

Sources checked 28 October 2026: Wikipedia, "Incident management" (en.wikipedia.org/wiki/Incident_management), which quotes the ITIL 2011 definition.