Incident Management Procedure Template (ISO/IEC 20000-1)

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.

Document control

Approvals

Revision history

Contents

1. Purpose, scope and definitions
2. Roles and responsibilities
3. Process overview
4. Detection, logging and categorisation
5. Priority
6. Response and resolution targets
7. Investigation, diagnosis and escalation
8. Major incidents and security incidents
9. Communication with users
10. Resolution, closure and reopening
11. Links to problem, change and configuration management
12. Measures, reporting and quality checks
13. Standards mapping and references

1. Purpose, scope and definitions

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.

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

RACI for key activities

3. Process overview

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.

4. Detection, logging and categorisation

4.1 Sources

4.2 Minimum record content

4.3 Category tree (Example)

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

5.1 Impact

5.2 Urgency

5.3 Priority matrix

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

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

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

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.

8. Major incidents and security incidents

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:

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

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

11. Links to problem, change and configuration management

12. Measures, reporting and quality checks

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

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.