IT KORR Knowledge Center
Incident Response Runbook
A runbook structure for handling an IT incident from severity classification through resolution, verification, and post-incident documentation.
Severity Classification
- Severity 1 (Critical) — widespread outage or business-critical system down; immediate response required.
- Severity 2 (High) — significant functionality impaired or a subset of users affected; urgent response required.
- Severity 3 (Medium) — limited impact with a workaround available; response within normal business hours.
- Severity 4 (Low) — minor issue with negligible business impact; scheduled response.
Initial Response Steps
- Acknowledge — confirm the incident is being worked and log the start time.
- Assess scope — determine which systems, services, and users are affected before taking action.
- Communicate status — notify stakeholders per the escalation path, with an initial status update and expected next update time.
Escalation Path by Severity
- Severity 1 — immediate escalation to on-call lead and IT leadership; status updates at short, fixed intervals until resolved.
- Severity 2 — escalation to on-call engineer within a defined response window; status updates at regular intervals.
- Severity 3/4 — handled within standard support queue; escalate only if scope or severity increases.
Investigation & Diagnosis
- Gather relevant logs, alerts, and recent changes (check the change log first — many incidents follow a recent change).
- Isolate the likely cause before applying a fix, to avoid masking the real issue.
- Document diagnostic steps taken, even ones that did not identify the cause — they narrow the field for next time.
Resolution & Verification
- Apply the fix and verify the affected system or service is fully restored, not just superficially responsive.
- Confirm with affected users or monitoring that normal operation has resumed.
- Communicate resolution to stakeholders with a summary of what happened and what was done.
Post-Incident Documentation Requirements
- Timeline of the incident from detection to resolution.
- Root cause, if known, and whether the incident should be tracked as a recurring problem.
- Follow-up actions to prevent recurrence, each with an owner and due date.
- For Severity 1/2 incidents, a formal post-incident review with stakeholders.
Related Resources
- Incident Management vs. Problem Management — /knowledge-center/it-operations/it-operations-service-management/incident-management-vs-problem-management