⚙️ Process & Workflows — Change Management
Normal Change Lifecycle
Normal Change Enablement Workflow
Click any step to expand · 7 steps
1
📝Change Request Submission
2
🔍Completeness Review
3
⚖️Risk & Impact AssessmentDECISION
4
👥CAB Review
5
📅Scheduling
6
🚀Implementation
7
✅Post-Implementation Review
Risk Assessment Matrix
Score each dimension 1–5, then classify:
| Dimension | Score 1 | Score 3 | Score 5 |
|---|---|---|---|
| Technical complexity | Simple config change | Multi-system | Core infrastructure |
| Business impact | 1 user | Team / department | All users / revenue |
| Rollback complexity | Instant rollback | < 30 min | > 1 hour / no rollback |
| Test coverage | Full UAT passed | Partial testing | No testing |
| CI change velocity | Low (first change in 30d) | Moderate | High (multiple recent) |
Total score → Risk level:
- 5–10: LOW → Delegate approval
- 11–17: MEDIUM → Change Manager approval
- 18–25: HIGH → CAB required
Emergency Change Process
Emergency changes bypass the standard CAB cycle but still require governance:
ECAB Composition
- Change Manager (mandatory)
- Service Owner of affected service (mandatory)
- Technical Lead (mandatory)
- Security representative (if security-related)
Emergency Change SLA
| Step | Target |
|---|---|
| ECAB convened | Within 2 hours |
| Decision | Within 4 hours |
| Implementation | As agreed |
| Full CR documentation | Within 24 hours post-implementation |
Emergency Change Criteria
- Active P1 incident requiring an infrastructure or software change
- Critical security vulnerability with active exploitation evidence
- Imminent regulatory or contractual breach
Standard Change Models
Pre-approved change types that bypass CAB:
| Change Model | Category | Frequency |
|---|---|---|
| Monthly OS patching | Software | Monthly |
| Account provisioning | Access | On-demand |
| SSL certificate renewal | Infrastructure | Quarterly |
| DNS record update | Network | On-demand |
| Scheduled database backup job | Data | Weekly |
| Application config update (non-prod) | Software | On-demand |
Each model must define: implementation steps, rollback steps, test validation criteria, and maximum duration.
DevOps Integration (ITIL 4 / ITIL 5)
ITIL 4 explicitly supports CI/CD pipelines within Change Enablement:
Code commit → CI pipeline (automated tests pass)
→ Risk score calculated automatically (CMDB + change velocity)
→ LOW risk: auto-approved, deployed to production
→ MEDIUM risk: Change Manager notified, 1-click approval
→ HIGH risk: CAB ticket created, human review required
→ Post-deploy: automated smoke tests + monitoring alert rules appliedThis model reduces change lead time from days to hours while maintaining governance for high-risk changes.
Change Freeze Periods
Define blackout windows to protect business-critical periods:
| Period | Restriction |
|---|---|
| Month-end (last 3 business days) | No changes to financial systems |
| Fiscal year-end | Full change freeze |
| Black Friday / Peak season | Emergency changes only |
| Major software go-lives | 72-hour freeze on related systems |
KPIs
| Metric | Target |
|---|---|
| Change success rate | > 97% |
| Emergency change % of total | < 10% |
| Failed changes per month | < 3 |
| Changes causing incidents | < 2% |
| Average change lead time (Normal) | < 7 calendar days |
| CAB on-time decisions | > 95% |
Downloadable Resources
| Resource | Format | Download |
|---|---|---|
| Change Register | Excel | ⬇ Download |
| RACI Matrix | Word | ⬇ Download |
← Back to Change Management