Overview
Build a change management process that satisfies ISO/IEC 20000-1:2011 Clause 9.2. This skill guides you through defining change types (standard, normal, emergency), documenting the full change lifecycle, establishing the Change Advisory Board, creating emergency change procedures, and defining how change management integrates with configuration and release management.
Change management is the gatekeeper that prevents uncontrolled modifications from disrupting services. Auditors focus heavily on this process because it connects directly to service stability. They want to see that every change is recorded, assessed for risk and impact, approved by the right authority, and reviewed after implementation. This skill ensures you cover every aspect – from routine pre-approved changes to emergency fixes at 2 AM.
For a step-by-step walkthrough, see the ISO 20000 SMS workspace tutorial .
What It Covers
- Change types – standard (pre-approved), normal (full lifecycle), and emergency (expedited)
- Change lifecycle – request through closure with defined stages, inputs, and outputs
- Change categorization – minor, significant, major, and emergency with mapped approval authorities
- Change Advisory Board (CAB) – composition, meeting frequency, quorum, decision authority
- Emergency change procedure – expedited authorization, retrospective review, feedback to normal process
- Process integrations – CMDB updates after changes, releases requiring approved change requests
Example Conversation
You: We need to define our change management process for ISO 20000. We currently use a ticketing system for change requests but don’t have a formal CAB or documented approval workflows.
Agent: I’ll help you build a formal change management process for Clause 9.2. Let me start with change types. ISO 20000 expects at minimum:
- Standard changes – low-risk, repeatable, pre-approved. Examples: password resets, adding a user to a distribution list, deploying a pre-tested patch.
- Normal changes – follow the full lifecycle with CAB approval. Examples: server migration, firewall rule changes, new application deployment.
- Emergency changes – expedited path for urgent situations. Examples: critical security patch, service restoration requiring a config change.
Can you give me examples of changes in your environment that would fall into each category?
You: Standard: adding VPN accounts, restarting scheduled services, deploying approved Windows patches. Normal: deploying new application versions, modifying network topology, migrating databases. Emergency: anything needed to restore a P1 service outage.
Agent: Good. Now let’s establish the Change Advisory Board. Who should participate?
You: Service delivery manager chairs it, plus infrastructure lead, application lead, security officer, and one business representative from the client.
Agent: Here’s the proposed CAB structure:
Role Person/Team Authority Chair Service Delivery Manager Approves minor changes, facilitates CAB meetings Infrastructure Infrastructure Lead Technical assessment for infra changes Application Application Lead Technical assessment for app changes Security Security Officer Security impact assessment Business Client Representative Business impact assessment Meeting frequency: weekly (with ad-hoc sessions for urgent normal changes). Quorum: 3 members including the chair and at least one technical lead. Agree?
You: Yes. What about emergency changes – who can approve those outside of a CAB meeting?
Agent: For the emergency change procedure, I’d recommend:
- Authorization: Any 2 CAB members (or the IT Director alone) can authorize
- Implementation: Follows expedited path – risk assessment still required but abbreviated
- Retrospective review: Mandatory within 48 hours, presented at the next CAB meeting
- Documentation: Emergency change logged retroactively with full details
You: That works. Add that the IT Director must be notified of all emergency changes within 1 hour.
Agent: I’ll run the
change_process_validatornow…Result: All checks passed. 3 change types defined (standard, normal, emergency). 8 lifecycle stages documented. CAB composition with 5 roles, weekly meetings, quorum of 3. Emergency procedure with dual authorization and 48-hour retrospective. Integration with configuration management (CMDB update) and release management (approved change required) documented.
Sample Output Excerpt
The skill produces a structured JSON process file and a markdown process document. Here is a representative excerpt from the JSON.
{
"change_types": [
{
"type": "standard",
"description": "Pre-approved, low-risk, repeatable changes",
"approval": "pre-approved",
"examples": ["VPN account creation", "Scheduled service restart", "Approved Windows patches"]
},
{
"type": "normal",
"description": "Changes following full lifecycle with CAB approval",
"approval": "CAB",
"examples": ["Application deployment", "Network topology change", "Database migration"]
},
{
"type": "emergency",
"description": "Urgent changes for critical service restoration",
"approval": "emergency_cab",
"examples": ["Critical security patch", "P1 service restoration config change"]
}
],
"lifecycle_stages": [
"request", "logging", "categorization", "assessment",
"approval", "implementation", "review", "closure"
],
"cab": {
"composition": [
"Service Delivery Manager (Chair)",
"Infrastructure Lead",
"Application Lead",
"Security Officer",
"Client Business Representative"
],
"meeting_frequency": "weekly",
"quorum": 3,
"quorum_requirements": "Chair + at least one technical lead"
},
"emergency_procedure": {
"authorization": "Any 2 CAB members or IT Director alone",
"retrospective_review": true,
"max_hours_before_review": 48,
"notification": "IT Director notified within 1 hour"
},
"integrations": {
"configuration_management": "CMDB updated after every implemented change",
"release_management": "All releases require an approved change request"
}
}
Extension Tools
change_process_validator
Validates change-process.json for ISO 20000-1 Clause 9.2 completeness. Run after generating the change process.
| Check | What It Does |
|---|---|
| Change types | Confirms standard, normal, and emergency types are defined |
| Lifecycle stages | Verifies all required stages are present (request through closure) |
| CAB composition | Checks that CAB membership, meeting frequency, and quorum are documented |
| Emergency procedure | Validates expedited authorization path and retrospective review requirement |
| Process integrations | Confirms integration with configuration management and release management |
Getting Started
Activate the ISO 20000-1 Change Management skill and have your CMDB design and service catalog ready – the agent references them to understand which CIs and services are affected by changes. Prepare a list of your common change scenarios so you can classify them into standard, normal, and emergency types.
The completed change process is the central coordination point for the SMS – release management requires approved changes, configuration management is updated after every change, and incident management may trigger emergency changes.