8.3.3. Change Management Processes
💡 First Principle: Every unauthorized change to a production system is a potential security incident — either an attacker modifying the environment to establish persistence, or an administrator bypassing controls in a way that introduces unassessed risk. Change management exists to ensure that every modification is assessed for security impact, tested for side effects, authorized by the appropriate authority, and documented for audit and forensic traceability.
Change categories:
| Category | Approval | Risk | Example |
|---|---|---|---|
| Standard change | Pre-approved; no CAB review needed | Low, well-understood, repeatable | Monthly OS patch deployment following tested procedure |
| Normal change | CAB review and approval required | Moderate; requires impact assessment | New firewall rule, application upgrade, infrastructure migration |
| Emergency change | ECAB expedited approval | High urgency; higher deployment risk | Zero-day patch for actively exploited vulnerability |
Change Advisory Board (CAB):
The CAB is the governance body that evaluates, approves, or rejects proposed changes. Composition typically includes: IT operations, security, affected application owners, and (for significant changes) business stakeholders. The security representative's role is to evaluate whether the proposed change introduces security risk, weakens existing controls, or conflicts with compliance requirements.
Change management process flow:
- Request for Change (RFC) — Requestor documents what will change, why, expected impact, rollback plan, and testing evidence.
- Security impact assessment — Does this change affect access controls, network topology, encryption, logging, or compliance scope? If yes, security review is mandatory.
- CAB review — Evaluate risk, schedule, conflicts with other changes, and resource requirements.
- Authorization — CAB approves, rejects, or requests modification. Approval is documented with who approved and under what conditions.
- Implementation — Change deployed during approved maintenance window. Rollback plan must be ready.
- Post-implementation review (PIR) — Was the change successful? Were there unexpected side effects? Was the rollback plan needed?
- Closure — Change record updated with outcome; configuration management database (CMDB) updated to reflect new state.
Emergency change process:
When a security incident requires immediate system modification (deploying a patch, blocking an IP range, disabling a compromised service), the normal CAB review cycle is too slow. The emergency change process provides expedited authorization:
- Verbal or electronic ECAB approval (often a subset of the full CAB — typically the change manager, security lead, and affected system owner)
- Implementation proceeds immediately after approval
- Retrospective documentation completed within 24–48 hours
- Full PIR at the next scheduled CAB meeting
The critical governance requirement: an emergency change is still an authorized change — it is not an excuse for uncontrolled modification. If an administrator makes a change without ECAB approval, it is an unauthorized change regardless of the urgency.
⚠️ Exam Trap: The exam frequently tests the relationship between change management and incident response. A security incident may trigger an emergency change (patching a zero-day), and a failed change may trigger an incident (deployment breaks authentication, causing a service outage). Understanding that these processes intersect — rather than operate independently — is a common exam differentiator.
Reflection Question: An IT administrator discovers a critical vulnerability at 11 PM and patches the affected server immediately without filing a change request, notifying the CAB, or documenting the change. The patch successfully remediates the vulnerability. From a governance perspective, what did the administrator do wrong, what risks does this create even though the outcome was positive, and what process should have been followed?
