Skip to content
Back to skills

It Change Management Process

ASecurity

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.

  • 6 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 8, 2026
businessgosqlrailsapidatabasesecuritydocumentation

Works with

  • api

Security analysis

A100/100

Scanned September 8, 2026

npx -y skills add cloudthinker-ai/CloudSkills --skill it-change-management-process --agent claude-code

Installs 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 with every re-scan.

Security grade badge for It Change Management Process
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/cloudthinker-ai-it-change-management-process/badge)](https://www.skillsdirectory.com/skills/cloudthinker-ai-it-change-management-process)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…