# Incident Management Procedure: [Organisation or service desk name]

> Service desk procedure for IT incidents, from detection to closure: what counts as an incident, logging and minimum record content, categorisation, priority from impact and urgency, response and resolution targets, functional and hierarchical escalation, the hand-off to major incident response, communication, resolution, closure and the quality checks that keep the records useful. Structure aligned with ISO/IEC 20000-1:2018 with Amendment 1:2024 (the current edition as of October 2026), clause 8.6.1 incident management, with links to clauses 8.6.2 service request management, 8.6.3 problem management, 8.3.3 service level management and 9.4 service reporting. This procedure complements the SRE-oriented Incident Severity Matrix (`ops/incident-severity-matrix`), which stays the single source of truth for severity levels and major incident response. Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write one procedure per service desk or per service management system. Resolver teams add their own runbooks; they do not redefine priority or escalation.
- Fill the priority matrix (section 5) and the targets (section 6) first, from the service level agreements you have signed. Everything else follows from them.
- Keep priority and severity separate. Priority (P1 to P4) orders the work queue for every incident. Severity (SEV1 to SEV4, from `ops/incident-severity-matrix`) applies to incidents big enough to need coordinated response. Section 8 defines how the two meet.
- The main pitfall is a procedure that rewards closing tickets over restoring service: measure first-time fix and reopen rates, not only volume.
- Related templates: Problem Record (`ops/problem-record`), Change Request (`ops/change-request`), Incident Commander Handbook (`ops/incident-commander-handbook`), On-call Handbook (`ops/on-call-handbook`), Incident Communication (`dev/incident-communication`), Service Level Agreement (`ops/service-level-agreement`), Service Review Report (`ops/service-review-report`), Security Incident Report (`security/security-incident-report`), Personal Data Breach Assessment (`compliance/personal-data-breach-assessment`).
- Example organisation: Corvid Commerce, a fictional online retailer, with an internal service desk supporting its staff and its online checkout. Delete every *Example* row before use.
-->

## Document control

<!-- Guidance: This is a controlled procedure. Auditors compare the version in force with the dates of the incident records they sample. -->

| Field | Value |
|---|---|
| Document ID | [PROC-ITSM-INC] |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Retired] |
| Owner (incident management process owner) | [@process-owner] |
| Approvers/reviewers | [@head-of-service-management], [@service-desk-lead], [@security-lead] |
| Applies to | [Services, sites and teams in scope] *Example:* All services in the Corvid Commerce service catalogue, all resolver groups and suppliers |
| Tooling | [Service management tool name] |
| Effective date | YYYY-MM-DD |
| Next review | YYYY-MM-DD (at least yearly, or after a major incident review that changes this procedure) |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |

### Approvals

| Role | Name | Date |
|---|---|---|
| Process owner | [@name] | YYYY-MM-DD |
| Head of service management | [@name] | YYYY-MM-DD |
| Security lead | [@name] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved; priority matrix aligned with SLA version 3 |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added rule to open a problem after the second matching incident within 90 days |

## Contents

<!-- Guidance: Keep aligned with the headings below. -->

1. [Purpose, scope and definitions](#1-purpose-scope-and-definitions)
2. [Roles and responsibilities](#2-roles-and-responsibilities)
3. [Process overview](#3-process-overview)
4. [Detection, logging and categorisation](#4-detection-logging-and-categorisation)
5. [Priority](#5-priority)
6. [Response and resolution targets](#6-response-and-resolution-targets)
7. [Investigation, diagnosis and escalation](#7-investigation-diagnosis-and-escalation)
8. [Major incidents and security incidents](#8-major-incidents-and-security-incidents)
9. [Communication with users](#9-communication-with-users)
10. [Resolution, closure and reopening](#10-resolution-closure-and-reopening)
11. [Links to problem, change and configuration management](#11-links-to-problem-change-and-configuration-management)
12. [Measures, reporting and quality checks](#12-measures-reporting-and-quality-checks)
13. [Standards mapping and references](#13-standards-mapping-and-references)

## 1. Purpose, scope and definitions

<!-- Guidance: Draw the line between incidents and service requests clearly; most queue disputes start there. Questions: do degraded services count? Does a failed backup with no user impact count? Say yes or no in writing. -->

**Purpose.** Restore normal service as quickly as possible after an unplanned interruption or quality reduction, keep users informed, and record enough information for problem management and service reporting.

**Scope.** All services in the service catalogue (`compliance/iso-20000-service-catalog`), all users and customers who can contact the service desk, all resolver groups and every supplier that resolves incidents on [Organisation]'s behalf.

| Term | Meaning in this procedure |
|---|---|
| Incident | An unplanned interruption to a service, a reduction in its quality, or an event that has not yet affected users but will if no action is taken (for example, loss of redundancy) |
| Service request | A user request for something standard: information, access, a standard change or a supplied item. Handled under the service request procedure, not here |
| Major incident | An incident that meets SEV1 or SEV2 criteria in `ops/incident-severity-matrix` |
| Workaround | A way to reduce or remove the impact of an incident without removing its cause |
| Resolver group | A team that diagnoses and resolves incidents in a defined area |
| Known error | A problem with a documented cause or symptom pattern and workaround (see `ops/problem-record`) |

Out of scope: [list] *Example:* Physical security events and safety incidents (handled by facilities), product feature requests (handled by product management).

## 2. Roles and responsibilities

<!-- Guidance: Name roles, not people, and say who owns an incident at every moment. The rule "the service desk owns every incident until closure" avoids orphaned tickets when resolver groups pass work between them. -->

| Role | Responsibilities |
|---|---|
| Process owner | Owns this procedure, its measures and its yearly review; chairs the monthly incident quality review |
| Service desk analyst (first line) | Logs, categorises and prioritises; applies known workarounds; resolves at first contact where possible; keeps the user informed; confirms closure |
| Incident owner | The service desk analyst who logged the incident, or the duty lead; stays accountable until closure, even when the work sits with a resolver group |
| Resolver group (second and third line) | Diagnoses, applies fixes or workarounds, records what was done, returns the incident to the service desk for user confirmation |
| Duty manager | Receives hierarchical escalations, removes blockers, approves priority overrides, decides when to call a major incident |
| Incident commander | Leads major incidents as defined in `ops/incident-commander-handbook` |
| Supplier | Resolves incidents on supplied components within contracted targets; reports status at agreed intervals |
| Problem manager | Receives problem candidates from incident trends (section 11) |

### RACI for key activities

| Activity | Service desk | Resolver group | Duty manager | Process owner |
|---|---|---|---|---|
| Log and categorise | R, A | C | I | I |
| Set and change priority | R | C | A (overrides) | I |
| Functional escalation | R, A | R | I | I |
| Hierarchical escalation | R | R | A | I |
| Resolve | R | R | I | I |
| Confirm closure with user | R, A | I | I | I |
| Monthly quality review | C | C | C | R, A |

## 3. Process overview

<!-- Guidance: The diagram must match sections 4 to 10 step for step. Keep it at this level; resolver runbooks hold the technical detail. -->

The flow below shows the path of every incident. Service requests leave the flow at the first decision; major incidents leave the normal queue and return to it for resolution and closure, so the service desk keeps one record from start to end.

```mermaid
flowchart TD
  D["Detect:<br/>user contact, monitoring alert, supplier notice"] --> L["Log and categorise<br/>(section 4)"]
  L --> SR{"Service request?"}
  SR -- "Yes" --> RQ["Route to service request procedure"]
  SR -- "No" --> P["Set priority<br/>(section 5)"]
  P --> MJ{"Meets SEV1 or SEV2<br/>criteria?"}
  MJ -- "Yes" --> MI["Major incident response<br/>(section 8)"]
  MJ -- "No" --> KE{"Matches a known error?"}
  KE -- "Yes" --> W["Apply workaround"]
  KE -- "No" --> F["First-line diagnosis"]
  F --> FX{"Resolved at first line?"}
  FX -- "No" --> E["Escalate to resolver group<br/>(section 7)"]
  FX -- "Yes" --> R["Resolve and record<br/>(section 10)"]
  E --> R
  W --> R
  MI --> R
  R --> C{"User confirms?"}
  C -- "Yes" --> CL["Close"]
  C -- "No" --> F
```

## 4. Detection, logging and categorisation

<!-- Guidance: Every incident is logged, including ones fixed in two minutes on the phone; unlogged fixes make trends invisible. Keep the category tree short (two levels is usually enough) and stable, because reports compare categories over time. -->

### 4.1 Sources

| Source | Logged by | Notes *(Example)* |
|---|---|---|
| Phone, chat, portal, email | Service desk, or user via portal | Portal form asks for service, symptom and business impact |
| Monitoring alert | Event integration creates the incident automatically | Only alerts marked "incident" in the Alerting Policy (`ops/alerting-policy`) create incidents |
| Supplier notification | Service desk | Linked to the supplier's own reference |
| Internal staff noticing a fault | Anyone, via portal | Same rules as users |

### 4.2 Minimum record content

| Field | Required at logging | Example *(Example)* |
|---|---|---|
| Incident ID | Yes (generated) | INC-3125 |
| Reported by and contact | Yes | Store operations lead, chat |
| Date and time reported | Yes (generated) | 2026-08-21 08:31 UTC |
| Affected service and configuration item | Yes | Online checkout (SVC-CHK), checkout-api (CI-APP-0201) |
| Symptom description in the user's words | Yes | "Customers cannot pay; page spins then errors" |
| Category and subcategory | Yes | Application / Availability |
| Impact, urgency, priority | Yes | High, High, P1 |
| Assigned group and person | Yes | Checkout resolver group |
| Linked records | When known | PRB-0042; KE-0019 once published |
| Work log entries | Throughout | Time-stamped actions and results |
| Resolution code and description | At resolution | Workaround applied |

### 4.3 Category tree *(Example)*

| Category | Subcategories |
|---|---|
| Application | Availability, Performance, Functional error, Data error, Integration |
| Infrastructure | Compute, Storage, Network, Database, Cloud service |
| End-user computing | Laptop, Mobile device, Printer, Peripheral |
| Identity and access | Sign-in failure, Account locked, Multi-factor issue |
| Security event | Suspected phishing, Malware alert, Suspected data exposure (route per section 8.2) |

Rule: categorise by the **symptom** at logging and record the confirmed **cause** category at resolution. Reports use both; the difference shows where first-line diagnosis needs training.

## 5. Priority

<!-- Guidance: Priority is calculated from impact and urgency, not chosen. Define both scales in business terms that a first-line analyst can judge in one minute. Pitfall: letting the caller's seniority set priority; use a documented override with a reason instead. -->

### 5.1 Impact

| Level | Definition *(Example)* |
|---|---|
| High | A whole service or a revenue-bearing journey is unavailable or badly degraded, or many users (more than [100]) or a whole site is affected |
| Medium | Part of a service is degraded, or one team or department is affected, or a single user who cannot do critical work |
| Low | One user or a few users with minor inconvenience; normal work can continue |

### 5.2 Urgency

| Level | Definition *(Example)* |
|---|---|
| High | No workaround, and the impact grows quickly or a business deadline is at risk within hours |
| Medium | A workaround exists but is costly, or the impact will grow within a business day |
| Low | A reasonable workaround exists, or the work can wait without growing harm |

### 5.3 Priority matrix

| Impact / Urgency | High urgency | Medium urgency | Low urgency |
|---|---|---|---|
| **High impact** | P1 | P2 | P3 |
| **Medium impact** | P2 | P3 | P4 |
| **Low impact** | P3 | P4 | P4 |

Overrides: the duty manager may raise or lower the calculated priority by one level and must record the reason. Priority is reassessed whenever impact or urgency changes, and every change is logged with the time and reason so that target measurement uses the right clock (section 6).

## 6. Response and resolution targets

<!-- Guidance: Copy the targets from your SLAs; this table must never promise less than a signed agreement. State the clock: business hours or 24x7, and when it pauses. Pitfall: pausing the clock "awaiting user" without a rule for how long, which hides delays. -->

| Priority | Response target (assigned and first contact) | Resolution target | Clock | Update to user | Hierarchical escalation at |
|---|---|---|---|---|---|
| P1 *(Example)* | 15 minutes | 4 hours | 24x7 | Every 30 minutes | Immediately to duty manager; head of service at 2 h (50%) and 3 h (75%) |
| P2 *(Example)* | 30 minutes | 8 business hours | Business hours, [09:00 to 17:00 local time, Monday to Friday], 8 business hours a day | Every 2 hours | Duty manager at 4 h (50%) and 6 h (75%) |
| P3 *(Example)* | 4 business hours | 3 business days (24 business hours) | Business hours | Daily | Resolver group lead at 12 business hours (50%), duty manager at 18 (75%) |
| P4 *(Example)* | 1 business day | 10 business days | Business hours | On change of status | Resolver group lead at 40 business hours (50%) |

Clock rules *(Example)*:

- The response clock starts when the incident is logged and stops when it is assigned to a named person who has contacted the user.
- The resolution clock pauses only while the incident is in status "Awaiting user" and only after two documented contact attempts; it restarts automatically after [3] business days and the incident is then closed with the user informed.
- A priority change restarts measurement against the new target from the time of the change, and the report shows both values.

## 7. Investigation, diagnosis and escalation

<!-- Guidance: Escalate early and visibly. Functional escalation moves the work to people with more skill; hierarchical escalation moves attention to people with more authority. Both can happen at once. -->

### 7.1 First-line diagnosis

1. Search the known error database and recent incidents for the same configuration item.
2. Check service status, recent changes on the affected configuration item and open maintenance windows (`ops/maintenance-notice`).
3. Apply the documented workaround or first-line runbook if one matches.
4. If not resolved within the first-line time box ([20] minutes for P3 and P4, [5] minutes for P1 and P2), escalate.

### 7.2 Functional escalation

| From | To | Trigger | Hand-off content |
|---|---|---|---|
| Service desk (first line) | Resolver group (second line) | Time box reached, or no runbook matches | Symptom, steps tried, results, user availability |
| Resolver group | Specialist team or architect (third line) | Diagnosis needs deep product or code knowledge | Diagnosis so far, logs and evidence references |
| Any line | Supplier | Fault is in a supplied component | Supplier contract ID, configuration item, evidence; record the supplier reference |

Rules: a resolver group that receives a misrouted incident reassigns it within [30] minutes with a note; it does not send it back to the service desk without a suggestion. Three reassignments trigger a duty manager review.

### 7.3 Hierarchical escalation

Hierarchical escalation follows the thresholds in section 6 and also happens when: a supplier misses a contracted target, resources are blocked by another team, the user requests it with a business reason, or the incident may breach a contractual or regulatory obligation. The duty manager records the decision and any action in the work log.

```mermaid
flowchart LR
  SD["Service desk<br/>first line"] -- "functional" --> RG["Resolver group<br/>second line"]
  RG -- "functional" --> SP["Specialist or supplier<br/>third line"]
  SD -- "hierarchical" --> DM["Duty manager"]
  RG -- "hierarchical" --> DM
  DM -- "hierarchical" --> HS["Head of service"]
```

## 8. Major incidents and security incidents

<!-- Guidance: This section is the bridge to the Incident Severity Matrix. Do not copy its criteria here; refer to them, so that there is only one definition to maintain. -->

### 8.1 Major incidents

When an incident meets SEV1 or SEV2 criteria in `ops/incident-severity-matrix`, the duty manager or on-call engineer declares a major incident. From that moment:

| Item | Rule |
|---|---|
| Command | An incident commander takes over coordination as defined in `ops/incident-commander-handbook`; the service desk keeps the incident record and user contact |
| Priority | The incident is set to P1, or P2 for SEV2 where impact is limited, with "Major" flag |
| Communication | External updates follow `dev/incident-communication`; the service desk uses the published statement only |
| Child incidents | Users reporting the same symptom are logged as child incidents linked to the major incident and closed with it |
| Review | A postmortem (`dev/postmortem`) and a problem record (`ops/problem-record`) are mandatory |

### 8.2 Security incidents and personal data

If a security event is suspected (phishing, malware, unauthorised access, suspected data exposure), the analyst follows the security triage steps, preserves evidence, and routes the incident to the security team without attempting containment beyond the documented first steps. The security team decides whether a security incident is declared and records it in a Security Incident Report (`security/security-incident-report`). If personal data may be involved, the data protection team starts a Personal Data Breach Assessment (`compliance/personal-data-breach-assessment`) at once, because legal notification clocks can be short. This procedure does not set legal timelines: check the current official text of the laws that apply to you with a qualified professional.

## 9. Communication with users

<!-- Guidance: Users judge the service desk by updates more than by fix time. Agree templates for each stage so that analysts do not write from scratch under pressure. -->

| Stage | Message content *(Example)* | Channel |
|---|---|---|
| Logged | Incident ID, what was understood, priority, next update time | Portal and email |
| Escalated | Who is working on it now, next update time | Portal |
| Waiting for user | What is needed, by when, what happens if no reply | Portal and email |
| Resolved | What was done, how to check, how to reopen | Portal and email |
| Closed | Confirmation, link to satisfaction survey | Portal |

For major incidents, the status page and any customer messages follow `dev/incident-communication`; the service desk links individual incidents to the published update.

## 10. Resolution, closure and reopening

<!-- Guidance: Resolution restores service; closure confirms it with the user and checks the record quality. Keep these as two steps. Pitfall: closing on the resolver's say-so without the user, which inflates reopen rates. -->

| Step | Rule *(Example)* |
|---|---|
| Resolution | Resolver records what was done, resolution code, cause category and any linked known error or change |
| Confirmation | Service desk contacts the user; if confirmed, the incident is closed |
| Auto-closure | If the user does not respond within [3] business days after two contact attempts, the incident closes automatically |
| Record check | Before closure, analyst checks category, configuration item, priority history and work log are complete |
| Reopen | User may reopen within [5] business days if the same symptom returns; after that a new incident is logged and linked |

| Resolution code | Use when |
|---|---|
| Resolved, fix applied | The cause was removed at incident level, for example a replaced disk |
| Resolved, workaround applied | Service restored, cause remains; link known error or open problem |
| Resolved by change | Emergency or normal change applied; link the change |
| No fault found | Could not reproduce, user confirms service normal |
| Duplicate | Linked to the parent incident |
| Not an incident | Reclassified as a service request or out of scope |

## 11. Links to problem, change and configuration management

<!-- Guidance: Incidents feed the other practices. Write the triggers down so that the links do not depend on one person's memory. -->

| Link | Trigger *(Example)* | Owner |
|---|---|---|
| Open a problem | Every major incident; the second incident with the same symptom on the same configuration item within 90 days; any incident resolved by workaround without a known error | Problem manager |
| Link a known error | Incident matches every matching symptom of a published known error | Service desk |
| Raise a change | Resolution needs a change to a configuration item; emergency changes follow the emergency path in `ops/change-enablement-policy` | Resolver group |
| Configuration data | Incident shows a CMDB record is wrong or missing; raise a data correction task as defined in `ops/cmdb-data-model` | Configuration manager |

## 12. Measures, reporting and quality checks

<!-- Guidance: Pick a small set of measures that drive the behaviour you want, report them monthly in the Service Review Report, and review a sample of records for quality. -->

| ID | Measure | Formula | Target *(Example)* |
|---|---|---|---|
| IM-01 | Response target met | incidents meeting response target / incidents closed | 95% |
| IM-02 | Resolution target met | incidents meeting resolution target / incidents closed | 90% |
| IM-03 | First contact resolution | incidents resolved by first line at first contact / incidents logged by the service desk | 60% |
| IM-04 | Reopen rate | incidents reopened / incidents closed | below 3% |
| IM-05 | Reassignment count | average reassignments per incident | below 1.5 |
| IM-06 | Incidents linked to known errors | incidents linked to a known error / incidents closed | Trend only |
| IM-07 | Record quality score | sampled records passing all checks / records sampled | 95% |

Monthly quality review: the process owner samples [20] closed incidents across priorities and checks category, priority history, work log, resolution code and user confirmation. Findings and trends are reported in the Service Review Report (`ops/service-review-report`).

## 13. Standards mapping and references

<!-- Guidance: Clause numbers refer to ISO/IEC 20000-1:2018; check them against the edition you are certified to. -->

| Section of this procedure | ISO/IEC 20000-1:2018 clause | Topic (short original label) |
|---|---|---|
| 1, 4 Scope, logging, categorisation | 8.6.1 Incident management | Record and classify incidents |
| 5, 6 Priority and targets | 8.6.1, 8.3.3 Service level management | Prioritise against impact, urgency and agreed targets |
| 7 Escalation | 8.6.1 | Escalate when needed |
| 8 Major and security incidents | 8.6.1, 8.7.3 Information security management | Handle major and security incidents by documented procedure |
| 1 Service requests excluded | 8.6.2 Service request management | Handle requests separately |
| 11 Problems, changes, configuration | 8.6.3 Problem management, 8.5.1 Change management, 8.2.6 Configuration management | Feed other processes |
| 2, 7 Suppliers | 8.3.4 Supplier management | Control suppliers in incident resolution |
| 12 Measures and reporting | 9.1 Monitoring and measurement, 9.4 Service reporting | Measure and report |

| Reference | Version or date checked | Use |
|---|---|---|
| ISO/IEC 20000-1:2018, Information technology, Service management, Part 1: Service management system requirements, with Amd 1:2024 | Current edition as of October 2026 (no newer edition found) | Clause numbers above |
| ITIL, PeopleCert | ITIL 4 available; ITIL (Version 5) released in phases from 2026; checked 2026-10-30 | Practice name "incident management" and the impact and urgency approach, by name only |

## Standard and licence note

Structure aligned with ISO/IEC 20000-1:2018 with Amendment 1:2024, clause 8.6.1 incident management and the related clauses listed in section 13. ISO/IEC 20000-1 is a copyrighted standard: this template cites clause numbers with short original labels only; no text, table or definition is copied. Official text: ISO, purchase or licensed access: https://www.iso.org/standard/70636.html, also sold by national standards bodies. The practice name incident management follows common ITIL usage and is cited by name only; ITIL is published by PeopleCert (https://www.peoplecert.org/news-and-announcements/itil-version-5-explained) and is a registered trademark of the PeopleCert group. The priority matrix, targets, thresholds and worked examples are illustrative, not taken from any standard or law. This procedure is not legal advice: notification duties for security and personal data incidents depend on the laws that apply to you; check the current official text and a qualified professional. All text is original, written for this collection. Check the current edition of any standard you certify against. Template licence: MIT.