Change Management
Explain the importance of change management processes and the impact to security
Every unmanaged change is a potential vulnerability. Change management ensures that updates to systems, configurations, and infrastructure are proposed, reviewed, tested, documented, and reversible.
The process: RFC (Request for Change) → Impact Analysis → CAB Approval (Change Advisory Board) → Implementation (during maintenance window) → Backout Plan if needed. Unmanaged changes are among the most common causes of outages and security gaps. Even emergency changes follow an expedited process — never no process.
Business Processes:
- Approval process — who signs off on the change? Typically the Change Advisory Board (CAB) for standard changes, or an emergency CAB for urgent ones.
- Ownership — who is responsible for the change from start to finish? Every change has a single owner.
- Stakeholders — who is affected? Users, other teams, customers, third-party vendors.
- Impact analysis — what could break? Assess risk to availability, security, performance, and dependent systems.
- Test results — proof the change works in a non-production environment before touching production.
- Backout plan — how to reverse the change if it fails. Every change must have one.
- Maintenance window — when the change will be implemented (scheduled downtime, low-traffic period).
- Standard operating procedure (SOP) — documented step-by-step instructions for implementation.
Technical Implications:
- Allow lists / Deny lists — changes may require updating firewall rules, application whitelists, or blocked IP lists.
- Restricted activities — certain actions (deploying to production, modifying ACLs) may be prohibited during change freezes.
- Downtime — planned service interruption during implementation.
- Service / application restart — many changes require restarting services, which impacts availability.
- Legacy applications — older systems may not tolerate changes to dependencies (libraries, OS patches, protocols).
- Dependencies — other systems that rely on the changed component. A database schema change can break every application that queries it.
Documentation:
- Updating diagrams — network diagrams, architecture diagrams, data flow diagrams must reflect the change.
- Updating policies/procedures — SOPs, runbooks, and configuration baselines must be updated.
- Version control — track what changed, when, and by whom. Configuration management databases (CMDB) and version control systems (Git).
| Step | Purpose | Key Question |
|---|---|---|
| RFC | Formally propose the change | What do you want to change and why? |
| Impact Analysis | Assess risk before implementation | What could break? |
| CAB Approval | Stakeholder review and sign-off | Do the benefits outweigh the risks? |
| Implementation | Execute during maintenance window | Is there a tested SOP? |
| Backout Plan | Reverse the change if it fails | How do we restore to the previous state? |
| Technical Implication | What It Means | Exam Angle |
|---|---|---|
| Allow Lists | Approved applications, IPs, or domains | Changes may require updating allowed entries |
| Deny Lists | Blocked applications, IPs, or domains | New threats may require adding blocked entries |
| Downtime | Service unavailable during change | Must be planned within maintenance window |
| Service Restart | Applications need restart after changes | Impacts availability; must be coordinated |
| Legacy Apps | Older systems may not support changes | Dependency conflicts, compatibility issues |
| Dependencies | Other systems relying on changed component | Breaking a dependency can cascade failures |
Every change needs a backout plan. No exceptions. Even emergency changes. The exam will test whether you know that emergency changes follow an expedited change management process — they do NOT skip change management entirely.
A critical zero-day vulnerability is announced. The vendor releases an emergency patch. Your SysAdmin wants to deploy immediately to all production servers.
Emergency Patch Deployment
Enterprise · 2,000 users · Zero-day vulnerability · Vendor patch availableEmergency change process: Take VM snapshots (instant backout plan) → test on one server → deploy in waves → monitor for issues → document after the fact. The process is accelerated, not eliminated. Post-change review happens within 48 hours.
In practice, this negotiation happens constantly. Security teams want speed; operations teams want stability. The change management process is the bridge between them. Senior security professionals who understand change management get respected by ops teams — those who don't get blocked by them.
On the exam: "Emergency changes skip change management" is always WRONG. Emergency changes follow an expedited process with retroactive documentation. The exam tests this distinction heavily.
The zero-day patch is ready. Your SysAdmin has not tested it. There is no backout plan documented. The vulnerability is being actively exploited against organizations in your industry. Your CISO asks for your recommendation:
Push Immediately Without Testing
Fix the vulnerability right now. Accept the risk that the patch might break production. Deal with fallout later. Every minute of delay is exposure.
Follow Emergency Change Process
Snapshot servers (backout plan), test on staging for 1 hour, deploy in batches during a 2-hour window. Takes 3 hours total but controlled.
Option B is correct — even emergencies need a process
Option B: An untested patch that breaks production is a self-inflicted outage. You've traded a security vulnerability for an availability disaster. The emergency change process takes 3 hours — that's faster than recovering from a botched deployment that took down your ERP at 2 AM with no backout plan.
Option A's kernel of truth: Speed matters. Active exploitation means real risk. But "push untested to 40 servers simultaneously with no rollback" isn't speed — it's recklessness. The emergency process is the fast path. It's just not the reckless path.
On the exam: the answer is always "follow the process." The process can be accelerated, but never skipped entirely. A backout plan is non-negotiable.
Change management questions love the backout plan. If a question describes a failed deployment and asks "which document should have been prepared," the answer is almost always the backout plan. Also watch for: "which process ensures changes are reviewed before implementation?" — that's the CAB/approval process. "What document demonstrates the system can be restored?" — backout plan, not test results.
- A Backout plan
- B Impact analysis
- C Test procedure
- D Approval procedure
Correct: A. The backout plan specifically documents how to restore the system to its previous state if a change fails. Impact analysis (B) assesses risk before the change. Test procedure (C) validates the change works in a non-production environment. Approval procedure (D) documents who signed off. Only the backout plan addresses "how to restore if it fails."