ITIL 4 IM cheat sheet

Incident: an unplanned interruption to a service or reduction in the quality of a service.

Incident management practice purpose: minimize the negative impact of incidents by restoring normal service operation as quickly as possible.

Normal service operation is defined by the agreed service levels (SLAs), not by perfect technical health.

Major incident: an incident with significant business impact; it requires a separate, escalated response and often a dedicated major incident team.

Incident vs problem: an incident is the observable event; a problem is the underlying cause (or potential cause) of one or more incidents.

Incident vs service request: a service request is a normal, planned user request (e.g., access, information); it is not a failure and is handled by the service request management practice.

Workaround: a temporary solution that reduces or eliminates the impact of an incident for which a full resolution is not yet available.

Known error: a problem that has been analyzed but not yet resolved; it typically has a documented root cause and workaround.

Impact and urgency are separate inputs; priority is derived from them (commonly via a priority matrix), not set by impact alone.

Incident owner: accountable for managing the lifecycle of a specific incident, including coordination and communication, through to closure.

Major incident manager (or major incident team lead): accountable for the major incident process, coordination of technical teams, and stakeholder communication during a major incident.

First-line / service desk: logs incidents, performs initial diagnosis, resolves known errors using workarounds, and escalates when required.

Second-line and third-line support: perform deeper diagnosis and resolution; third line typically includes specialist or technical teams and suppliers.

Functional escalation: moving an incident to a team with more skill or authority; hierarchical escalation: raising to higher management for priority, resources, or communication.

Problem manager: accountable for problem management, including root cause analysis and known error management; works with incident management on recurring incidents.

The incident management value stream typically flows: detect/record → classify → diagnose → resolve/workaround → recover → close, with communication throughout.

Incident management is a practice, not a process owner role: the practice owner defines the approach, tools, and measures; incident owners handle individual incidents.

Roles may be combined in small organizations, but accountability for major incident coordination and for problem root cause analysis should remain explicit.

Incident identification and logging: capture the incident as soon as detected, with sufficient information to classify and route it.

Classification: assign category, impact, urgency, and priority; classification drives routing, escalation, and reporting.

Prioritization rule: priority is a function of impact and urgency; higher impact and urgency yield higher priority and shorter target resolution times.

Initial diagnosis: check for known errors and documented workarounds; if a workaround exists, apply it to restore service and record the incident against the known error.

Escalation decision rule: escalate when the current support level cannot resolve within its target time, when impact increases, or when authority/resources are needed.

Investigation and diagnosis: gather symptoms, identify the failing component, and determine the resolution or workaround.

Resolution and recovery: apply the fix or workaround, verify that the service is restored to agreed levels, and confirm with the user where appropriate.

Incident closure: confirm the user is satisfied, record the resolution, and close; recurring incidents should be linked to a problem record.

Major incident procedure: declare, assemble the team, communicate to stakeholders at agreed intervals, restore service, and conduct a post-incident review.

Post-incident review: capture lessons, contributing factors, and actions; feed findings into problem management and continual improvement.

Incident record fields commonly include: ID, date/time logged, caller, affected service/CI, category, impact, urgency, priority, status, assignment group, resolution, and closure details.

Status values typically include: new, in progress, on hold (pending user/supplier), resolved, and closed; status drives reporting and SLA clocks.

SLA clocks: response and resolution targets are measured from the incident start or logging time; pause rules (e.g., pending customer) must be defined and applied consistently.

Known error database (KEDB): stores known errors with root cause and workaround; incident tools should surface KEDB matches during diagnosis.

Configuration management system (CMS) / CMDB: links incidents to affected configuration items and services, enabling impact assessment and routing.

Tool integration: incident tooling should integrate with monitoring/event management (to auto-create incidents), service request management, problem management, and knowledge management.

Knowledge management: resolution notes and workarounds should be captured as knowledge articles to speed future diagnosis and support self-service.

Dashboards and reporting: track volume, backlog, major incidents, SLA attainment, mean time to restore, and first-time-fix rate; use data to drive improvement.

Automation opportunities: auto-classification, auto-routing, suggested workarounds from the KEDB, and automated status notifications to users.

The service value chain activities relevant to incident management are: engage (users), plan, improve, design and transition, obtain/build (limited), and deliver and support (primary).

Incident management is a practice within the ITIL 4 practice framework; it interacts with service desk, service request management, problem management, and service level management.

The four dimensions: organizations and people (roles, culture), information and technology (tools, data), partners and suppliers (third-party support), and value streams and processes (workflow).

Guiding principles apply: focus on value, start where you are, progress iteratively with feedback, collaborate and promote visibility, think and work holistically, keep it simple and practical, optimize and automate.

Incident management supports the 'deliver and support' value chain activity and contributes to value co-creation with users and customers.

Continual improvement: incident data (trends, recurring incidents, major incident reviews) is input to the improvement activity and to problem management.

Service level management: SLAs and OLAs set the targets that incident management works to; incident performance is reported against them.

Supplier and partner management: third-party support agreements must define escalation paths and response times that align with incident priorities.

Risk and governance: major incidents are a governance concern; escalation, communication, and post-incident review are part of the organization's risk management.