Overview
Build an incident and service request management process that meets ISO/IEC 20000-1:2011 Clause 8.1. This skill guides you through creating a priority matrix, defining the full incident lifecycle, establishing functional and hierarchical escalation paths, documenting the major incident procedure, and setting up service request fulfillment – all calibrated to your SLA targets.
Incident management is the most operationally visible process in any IT service management system. When something breaks, everyone is watching. An auditor will want to see that you have a defined priority matrix, clear escalation rules, documented response and resolution targets, and a separate fast-track procedure for major incidents. This skill builds all of that, step by step.
For a step-by-step walkthrough, see the ISO 20000 SMS workspace tutorial .
What It Covers
- Priority matrix – impact and urgency levels mapped to priorities P1 through P4
- Response and resolution targets – SLA-aligned time windows per priority
- Incident lifecycle – detection through closure with defined stages
- Escalation procedures – functional (specialist groups) and hierarchical (management)
- Major incident procedure – dedicated manager, communication plan, post-incident review
- Service request fulfillment – request models, approval workflows, tracking
Example Conversation
You: We’re setting up incident management for ISO 20000 certification. We’re an enterprise IT department supporting 2,000 employees across finance, HR, and operations.
Agent: I’ll help you build the incident management process for Clause 8.1. Let me start with the priority matrix. I’ll use a standard impact-urgency model. First, let’s confirm the impact levels for your organization:
- Extensive – Entire organization affected (e.g., email outage, ERP down)
- Significant – One department affected (e.g., HR system down)
- Moderate – A team or group affected
- Minor – Single user affected
Do these levels fit your organization, or would you adjust the definitions?
You: That works. For urgency, we want to distinguish between revenue-impacting and non-revenue-impacting situations.
Agent: Good distinction. Here’s the proposed priority matrix:
Critical High Medium Low Extensive P1 P1 P2 P3 Significant P1 P2 P3 P3 Moderate P2 P3 P3 P4 Minor P3 P3 P4 P4 Now let’s set response and resolution targets. What are your current SLA commitments?
You: P1 incidents must be responded to in 15 minutes and resolved in 4 hours. P2 is 30 minutes response, 8 hours resolution. P3 is 2 hours and 24 hours. P4 is 4 hours and 72 hours.
Agent: Recorded. Now let’s define escalation. For functional escalation, what specialist teams do you have?
You: Service desk (L1), infrastructure team (L2), application support (L2), database team (L3), and we have vendor escalation for SAP and Oracle.
Agent: And for hierarchical escalation, what happens when a P1 incident is not resolved within the target window?
You: After 2 hours, escalate to the IT operations manager. After 3 hours, escalate to the CIO. Any P1 lasting more than 4 hours triggers the major incident procedure.
Agent: Let me define the major incident procedure. For P1 incidents, I’ll include:
- Dedicated incident manager assigned immediately
- Communication cadence – stakeholder notification within 15 minutes, status updates every 30 minutes
- Bridge call established for real-time coordination
- Post-incident review mandatory within 5 business days
Does that match how you want to handle major incidents?
You: Yes, and add that the major incident report must include a root cause and preventive actions.
Agent: I’ll run the
incident_process_validatornow…Result: All 5 checks passed. Priority matrix defined with 4 impact levels, 4 urgency levels, and 16 mappings. 7 lifecycle stages documented. Functional and hierarchical escalation paths present. Major incident procedure with trigger criteria and post-incident review. Response/resolution targets set for all 4 priority levels.
Sample Output Excerpt
The skill produces a structured JSON process file, a visual priority matrix, and a markdown process document. Here is a representative excerpt from the JSON.
{
"priority_matrix": {
"impact_levels": ["extensive", "significant", "moderate", "minor"],
"urgency_levels": ["critical", "high", "medium", "low"],
"mapping": [
{ "impact": "extensive", "urgency": "critical", "priority": "P1" },
{ "impact": "extensive", "urgency": "high", "priority": "P1" },
{ "impact": "extensive", "urgency": "medium", "priority": "P2" },
{ "impact": "significant", "urgency": "critical", "priority": "P1" },
{ "impact": "moderate", "urgency": "critical", "priority": "P2" }
]
},
"lifecycle_stages": [
"detection", "logging", "categorization", "prioritization",
"investigation", "resolution", "closure"
],
"escalation": {
"functional": [
{ "from": "Service Desk (L1)", "to": "Infrastructure Team (L2)", "trigger": "Infrastructure-related incident" },
{ "from": "Infrastructure Team (L2)", "to": "Database Team (L3)", "trigger": "Database root cause identified" }
],
"hierarchical": [
{ "priority": "P1", "elapsed_time": "2 hours", "escalate_to": "IT Operations Manager" },
{ "priority": "P1", "elapsed_time": "3 hours", "escalate_to": "CIO" }
]
},
"major_incident_procedure": {
"trigger_criteria": "Any P1 incident or P2 incident exceeding 4 hours",
"communication_plan": "Stakeholder notification within 15 min, updates every 30 min",
"post_incident_review": true,
"review_deadline": "5 business days"
},
"response_resolution_targets": [
{ "priority": "P1", "response_time": "15 minutes", "resolution_time": "4 hours" },
{ "priority": "P2", "response_time": "30 minutes", "resolution_time": "8 hours" },
{ "priority": "P3", "response_time": "2 hours", "resolution_time": "24 hours" },
{ "priority": "P4", "response_time": "4 hours", "resolution_time": "72 hours" }
]
}
Extension Tools
incident_process_validator
Validates incident-process.json for ISO 20000-1 Clause 8.1 completeness. Run after drafting the incident management process.
| Check | What It Does |
|---|---|
| Priority matrix | Verifies impact levels, urgency levels, and priority mappings are defined |
| Lifecycle stages | Confirms all required stages are documented (detection through closure) |
| Escalation paths | Checks that both functional and hierarchical escalation are present |
| Major incident procedure | Validates trigger criteria and post-incident review requirement |
| Response/resolution targets | Confirms targets are set for each priority level |
Getting Started
Activate the ISO 20000 Incident and Service Request Management skill and have your SLA targets and support team structure ready. The agent will guide you through building the priority matrix first, then the lifecycle, escalation paths, and major incident procedure.
The completed incident process integrates directly with problem management (repeated incidents trigger problem records) and change management (incident workarounds may require change requests).