Simple explanation
Uncontrolled changes to systems are one of the most common causes of outages and security incidents — not because change is bad, but because unreviewed, undocumented change is. Change management is the formal process that makes sure changes are reviewed, approved, tested, and reversible before they touch production.
Technical explanation
Business process impact: an approval process (who signs off), an owner (who's accountable), stakeholders (who's affected), an impact analysis (what could break), a test plan/backout plan (how to verify it worked, and how to undo it if not), a maintenance window (when it's allowed to happen), and standard operating procedures documenting how the change should be executed.
Technical implications to consider before any change:
- Allow lists / deny lists — will this change require updating what's permitted to run or connect?
- Restricted activities — some changes require temporarily restricting normal operations.
- Downtime — will users lose access, and for how long?
- Service restart — does applying the change require restarting a service or system?
- Application restart — same question at the application layer.
- Legacy applications — older software may not tolerate the change gracefully (unsupported dependencies, brittle integrations).
- Dependencies — what else relies on the thing being changed?
Documentation: updated diagrams, policies, and especially version control — tracking exactly what changed, when, and by whom, so any change can be audited or rolled back.
Synonyms / related terms
| Term | Means | |---|---| | Change advisory board (CAB) | The group that reviews and approves proposed changes | | Rollback plan | Backout plan | | Maintenance window | Approved time period during which changes may be applied |
Concept Check
"An engineer patches a production database server at 2pm on a Tuesday without notifying anyone, causing a 20-minute outage. What went wrong from a change management perspective?" The issue isn't that the server was patched (patching is good) — it's the absence of an approval process, a maintenance window, and stakeholder notification. The security lesson: even a beneficial change, done outside process, is a risk.
Interview-style Q&A
Q: Why does change management count as a security topic, not just an IT-operations topic? A: "Because most outages and a real share of breaches trace back to an undocumented or unreviewed change — a firewall rule someone forgot to revert, a permission left too open 'temporarily.' A formal change process is a preventive control against self-inflicted incidents."
Memory trick
"ABC-DL" — Approval, Backout plan, Change owner, Downtime, Legacy application impact: the five things to check before approving any change.