Use when performing it change management process — iTIL-aligned change management process covering change request submission, risk assessment, CAB review, approval workflows, implementation planning, and post-implementation review. Ensures all IT changes follow a controlled process to minimize risk and service disruption.
Scanned 9/8/2026
Install to Claude Code
npx -y skills add cloudthinker-ai/CloudSkills --skill it-change-management-process --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of It Change Management Process?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/cloudthinker-ai-it-change-management-process)More formats (shields.io, HTML) on the badges page.
---
name: it-change-management-process
enabled: true
description: |
Use when performing it change management process — iTIL-aligned change
management process covering change request submission, risk assessment, CAB
review, approval workflows, implementation planning, and post-implementation
review. Ensures all IT changes follow a controlled process to minimize risk
and service disruption.
required_connections:
- prefix: itsm
label: "ITSM Tool (ServiceNow, Freshservice, etc.)"
config_fields:
- key: change_title
label: "Change Title"
required: true
placeholder: "e.g., Upgrade production database to PostgreSQL 16"
- key: change_type
label: "Change Type (standard/normal/emergency)"
required: true
placeholder: "e.g., standard, normal, emergency"
- key: requested_by
label: "Requested By"
required: true
placeholder: "e.g., Jane Smith, Platform Team"
- key: target_date
label: "Target Implementation Date"
required: true
placeholder: "e.g., 2026-04-15 02:00 UTC"
- key: affected_services
label: "Affected Services"
required: false
placeholder: "e.g., payment-api, user-auth, database-cluster"
features:
- HELPDESK
---
# IT Change Management Process
Change: **{{ change_title }}**
Type: **{{ change_type }}** | Requested by: {{ requested_by }}
Target Date: {{ target_date }} | Affected: {{ affected_services }}
## Change Type Definitions
| Type | Description | Approval Required | Lead Time |
|------|-------------|-------------------|-----------|
| Standard | Pre-approved, low-risk, routine | Pre-approved (no CAB) | 24 hours |
| Normal | Requires assessment and approval | CAB approval | 5 business days |
| Emergency | Critical fix, cannot wait for CAB | Emergency CAB (expedited) | ASAP |
## Step 1 — Change Request Submission
- [ ] Complete change request form:
- Title: {{ change_title }}
- Description: detailed technical scope
- Business justification
- Affected services: {{ affected_services }}
- Requested implementation date: {{ target_date }}
- Expected duration
- Requestor: {{ requested_by }}
## Step 2 — Risk Assessment
### Impact & Risk Matrix
```
RISK ASSESSMENT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Impact:
[ ] Low — Single user/non-critical system
[ ] Medium — Department or non-critical service
[ ] High — Organization-wide or business-critical service
[ ] Critical — Revenue-impacting or security-related
Probability of Failure:
[ ] Low — Routine, well-tested, done many times
[ ] Medium — Some complexity, tested but not routine
[ ] High — Complex, first-time, multiple dependencies
Risk Level = Impact x Probability:
[ ] Low Risk → Standard approval
[ ] Medium Risk → Manager + CAB approval
[ ] High Risk → CAB + Director approval
[ ] Critical Risk → CAB + VP/CTO approval
```
### Pre-Implementation Checklist
- [ ] Change tested in non-production environment
- [ ] Rollback plan documented and tested
- [ ] Backup of affected systems completed or scheduled
- [ ] Communication plan prepared for affected users
- [ ] Maintenance window scheduled ({{ target_date }})
- [ ] On-call resources identified for implementation
## Step 3 — Approval
### Standard Change
- [ ] Verify change matches pre-approved standard change template
- [ ] Technical lead approval
- [ ] Proceed to implementation
### Normal Change
- [ ] Technical review completed by peer
- [ ] Manager approval
- [ ] Submit to CAB for review
- [ ] CAB meeting date: ______
- [ ] CAB decision: [ ] Approved / [ ] Rejected / [ ] Deferred
- [ ] If rejected: document reason and required modifications
### Emergency Change
- [ ] Emergency CAB (minimum: change manager + service owner)
- [ ] Verbal approval documented
- [ ] Formal documentation completed within 24 hours post-implementation
## Step 4 — Implementation Plan
```
IMPLEMENTATION PLAN
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Date/Time: {{ target_date }}
Duration: [estimated duration]
Implementer: {{ requested_by }}
Approver: [name]
PRE-IMPLEMENTATION:
[ ] Notify stakeholders
[ ] Verify backups completed
[ ] Confirm rollback plan ready
IMPLEMENTATION STEPS:
1. [Step 1 with expected duration]
2. [Step 2 with expected duration]
3. [Step 3 with expected duration]
VERIFICATION:
[ ] [Test 1 — expected result]
[ ] [Test 2 — expected result]
[ ] [Test 3 — expected result]
ROLLBACK TRIGGER:
If any verification fails or [specific condition],
execute rollback plan immediately.
ROLLBACK PLAN:
1. [Rollback step 1]
2. [Rollback step 2]
3. [Verify rollback successful]
```
## Step 5 — Post-Implementation Review
- [ ] All verification tests passed
- [ ] No unexpected errors or degradation observed
- [ ] Monitor for 30 minutes (standard) / 2 hours (high risk) post-change
- [ ] Update CMDB if configuration items changed
- [ ] Notify stakeholders of successful completion
- [ ] If issues detected:
- [ ] Determine if rollback is needed
- [ ] Document issues and resolution
- [ ] Close change request in ITSM
- [ ] Record actual vs planned duration
- [ ] Document lessons learned (for non-standard changes)
## Counter-Rationalizations
| Shortcut | Counter | Why |
|----------|---------|-----|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |
## Output Format
Generate a change management report with:
1. **Change summary** (title, type, risk level)
2. **Approval chain** with timestamps
3. **Implementation result** (success/rollback)
4. **Post-implementation status** and observations
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!