Incident, Problem, Change & Release

Real-world analogy

What is it?

ITIL-aligned service management is the operating model of most enterprise IT organizations. Knowing the vocabulary, disciplines, and safe patterns makes you immediately more hireable and promotable.

Real-world relevance

A printer ticket (incident) is resolved in 10 minutes with a spooler restart. Over a month, 40 similar tickets trigger a problem record. Root cause: an outdated print driver on the central server. A planned change fixes it during a maintenance window. Ticket volume drops 80%.

Key points

• Incident — restore service fast — The goal of incident management is to restore service as quickly as possible — even with a workaround. Not to find the root cause. Not to change the architecture. Those come later.
• Problem — find and fix root causes — Problem management investigates why incidents happen. Outputs: known errors, workarounds, permanent fixes. Problems are longer-lived than incidents and often span multiple tickets.
• Change — controlled, risk-managed — Change management ensures updates (config, patch, new release, infra) are approved, risk-assessed, scheduled, executed, verified, and documented. Prevents well-intentioned outages.
• Request — ordinary, pre-approved asks — ‘I need access to this folder’ or ‘please provision this VM from the catalog.’ Requests are routine and pre-approved — not changes. Mixing them up clogs CAB meetings.
• Release — delivering change safely — Release management groups related changes into a deliverable, tests, rolls out in stages, and communicates. Common in software-heavy shops; equally valid for infrastructure.
• Severity vs priority (again) — Severity = technical impact. Priority = business impact. A single global outage can be Sev 2 technically but Priority 1 business-wise. Always answer both.
• CAB — Change Advisory Board — A group that reviews and approves changes in mature orgs. Standard changes (pre-approved, low-risk) may skip CAB. Emergency changes use an accelerated path. Normal changes go through CAB.
• Tooling — ServiceNow, Jira Service Management, Zendesk, Freshservice, ManageEngine — different products, same underlying ITIL disciplines. Tools change; the thinking remains.

Code example

// ITIL flow (minimal)

User reports issue
      |
      v
INCIDENT ticket  -> restore service fast (workaround OK)
      |  (many repeats?)
      v
PROBLEM ticket   -> root cause analysis, known error
      |
      v
CHANGE ticket    -> controlled fix (CAB approval, rollback plan)
      |
      v
RELEASE          -> deployment package / rollout (if software)
      |
      v
POST-IMPLEMENTATION REVIEW  -> verify, update KB + CMDB

Severity = technical impact
Priority = business impact

Line-by-line walkthrough

1. 1. ITIL flow diagram
2. 2. User report
3. 3. Incident — restore fast
4. 4. Repeats promote to problem
5. 5. Problem — root cause
6. 6. Change — controlled fix
7. 7. Release — delivery packaging
8. 8. Post-implementation review
9. 9. Blank separator
10. 10. Severity vs priority reminder

Spot the bug

Every ticket, regardless of type, is logged as a ‘change request’ requiring CAB approval. Users wait days for password resets.

Explain like I'm 5

Fun fact

Hands-on challenge

More resources

• ITIL 4 Foundation (AXELOS)
• ServiceNow Community (ServiceNow)
• Jira Service Management (Atlassian)