The Uncomfortable Truth About Change Management
Every major outage in the history of technology has the same root cause: someone changed something. Usually on a Friday. Usually without telling anyone.
A change management policy exists to prevent the three most expensive words in IT: "Who changed that?"
Change management isn't about preventing change. It's about preventing surprise. The difference costs millions.
Why Your Current Process Probably Isn't Working
Let's be honest. If your change management process looks like this:
- Developer makes a change
- Developer tells Slack
- Nobody reads Slack
- Something breaks at 2 AM
- Everyone reads Slack very carefully
...then you don't have a change management policy. You have a notification habit with no teeth.
According to Gartner, 80% of unplanned outages are caused by ill-planned changes made by administrators and developers. The fix isn't more Slack messages — it's structured governance.
The Change Classification Matrix
Not every change deserves a review board. The trick is categorizing changes so that risky ones get scrutiny and routine ones flow fast.
| Type | Risk Level | Approval | Example |
|---|---|---|---|
| Standard | Pre-approved, low-risk, repeatable | Auto-approved | Dependency updates, config tweaks, log rotation |
| Normal | Moderate risk, planned | Change Advisory Board (CAB) | New feature deploy, database migration, infra scaling |
| Emergency | High risk, unplanned, urgent | Expedited (post-approval) | Security patch, incident response, critical hotfix |
The golden ratio: 70% Standard, 25% Normal, 5% Emergency. If your emergency changes exceed 20%, your planning process has a planning problem.
What the Policy Must Cover
1. Request and Documentation
Every change needs a record. Not a novel — a record. Five fields:
- What is changing?
- Why is it changing?
- Who requested it?
- When will it happen?
- What's the rollback plan?
That last one is the most important. A change without a rollback plan is a bet, not a change.
2. Risk Assessment
Before approval, assess:
| Factor | Low (1) | Medium (3) | High (5) |
|---|---|---|---|
| Impact scope | Single service | Multiple services | Customer-facing |
| Reversibility | One-click rollback | Manual rollback | Irreversible |
| Testing | Fully tested | Partially tested | Untested |
| Dependency count | None | 1-3 | 4+ |
Score > 12? That's a CAB review. Score < 6? Fast-track it.
3. Approval Workflow
| Change Type | Approver | SLA |
|---|---|---|
| Standard | Auto-approved (pre-authorized) | Immediate |
| Normal | Change manager + system owner | 48 hours |
| Emergency | On-call lead (retroactive CAB review within 48h) | Immediate |
4. Post-Implementation Review
The most neglected step. After every Normal and Emergency change:
- Did the change achieve its objective?
- Were there unexpected side effects?
- Was the rollback plan adequate?
- What would we do differently?
This isn't bureaucracy — it's learning. Organizations that skip post-implementation reviews make the same mistakes on a reliable quarterly schedule.
The Change Freeze Myth
"No changes during change freeze" sounds great until you realize that your most critical security patches always arrive during change freeze. December, end of quarter, pre-audit — the times you most need change management are the times organizations try to stop changes entirely.
Better approach: Define clear emergency criteria that operate during freeze periods. A frozen process that can't handle emergencies isn't a process — it's a liability.
Framework Alignment
| Framework | Change Management Controls |
|---|---|
| SOC 2 | CC8.1 – Change management process |
| ISO 27001 | A.12.1.2 – Change management |
| ITIL | Change Enablement practice |
| PCI DSS | Req 6.5.1 – Change control procedures |
| NIST CSF | PR.IP-3 – Configuration change control |
The Bottom Line
A change management policy should make safe changes easy and dangerous changes visible. If your policy makes all changes painful, people will route around it — and that's when things break.
The best change management isn't a gate. It's a governance commitment your team understands well enough to apply judgment, not just follow rules.