Incident management processes and practices
Domain 3 tests the activity flow of the incident management practice, how priority and escalation work, how major incidents are handled, and how incident management interfaces with problem, change and knowledge management. ITIL 4 does not mandate a rigid process, but expects these activities to be designed into value streams.
Core activities
- Identification: detection by monitoring, users, suppliers or event management.
- Logging: a complete record with a unique ID.
- Categorization: service, configuration item, symptom and category tree to support routing and reporting.
- Prioritization: impact × urgency, with reassessment as the situation changes.
- Initial diagnosis: known-error database, knowledge articles and diagnostic scripts.
- Escalation: functional escalation to higher skills; hierarchical escalation to authority.
- Investigation and diagnosis: deeper work by second- or third-line teams.
- Resolution and recovery: workaround or permanent fix, with service restoration tested.
- Closure: confirm with the user, record a closure code, and link problems, known errors or changes.
Major incidents
Use predefined criteria, a dedicated manager, a communications plan, a bridge and regular stakeholder updates. Major incident is a declaration based on business impact, not simply a priority 1 label.
Practice interfaces
Problem management receives recurring or major incidents and returns known errors. Change enablement approves emergency changes. Knowledge management supplies workarounds and articles. Service level management sets targets and reports performance.
Worked example
Campus Wi-Fi fails for 500 users. Monitoring detects it, the service desk logs it, and impact and urgency are both high, so priority is 1 and the major incident criteria are met. The major incident manager opens a bridge. First-line applies a known-error workaround, failing over to the secondary controller, and service is restored in 20 minutes. The user confirms closure. A problem record is opened for the controller firmware, and an emergency change is scheduled. Reasoning: the workaround restores service quickly; closure does not wait for root cause.
Traps that cost marks
- Never reassessing priority as impact changes.
- Skipping categorization, which destroys reporting quality.
- Closing without user confirmation.
- Using emergency change as a reason to skip change records.
- Failing to link incidents to problems, known errors and changes.