Change Management for Security
Change management is the process of requesting, evaluating, approving, implementing, and verifying changes to production systems in a controlled, documented manner.
# Change Management for Security
Definition
Change management is the process of requesting, evaluating, approving, implementing, and verifying changes to production systems in a controlled, documented manner. In the security context, change management prevents unauthorized or untested modifications that could introduce vulnerabilities, disrupt services, or weaken security controls.
Every security incident caused by a misconfiguration was preceded by a change. Someone modified a firewall rule. Someone changed a cloud security group. Someone deployed a code update. Someone reconfigured a server. If that change was unauthorized (no approval), untested (no validation in a non-production environment), undocumented (no record of what changed, when, and why), or unreviewed (no security evaluation), it is an uncontrolled change that may have introduced the vulnerability that an attacker will exploit.
Change management is not bureaucracy. It is the process control that ensures every modification to the production environment is intentional, reviewed, tested, approved, and reversible. The CrowdStrike incident (July 2024) demonstrated the consequences of inadequate change control at global scale: a content update to CrowdStrike's Falcon sensor caused 8.5 million Windows devices to crash simultaneously. The update bypassed the staged rollout controls that would have limited the blast radius. One change. Global impact.
How It Works
The Change Management Process
Request. The change initiator submits a change request documenting: what is being changed, why the change is needed (business justification), when the change will be implemented (proposed window), what systems are affected, what the expected impact is, what the rollback plan is (how to reverse the change if it fails), and who will implement it.
The change request forces the initiator to think through the change before executing it. A request that cannot articulate the rollback plan is a request that has not considered failure. A request that cannot identify the affected systems is a request with unknown blast radius.
Classification. Changes are classified by risk level:
Standard changes: pre-approved, low-risk, routine changes that follow an established procedure. Applying a vendor-recommended patch to a non-critical system, adding a user to a standard access group, and deploying a pre-tested configuration change are standard changes. They follow a documented procedure without requiring individual approval each time.
Normal changes: changes that require evaluation and approval through the full change management process. Deploying a new application, modifying firewall rules, upgrading a production database, and reconfiguring network infrastructure are normal changes.
Emergency changes: changes required to address an immediate threat or outage that cannot wait for the normal approval process. Isolating a compromised endpoint, blocking a known malicious IP during an active attack, and applying an emergency patch for an actively exploited vulnerability are emergency changes. Emergency changes bypass the standard approval timeline but still require documentation, post-implementation review, and retroactive approval.
Evaluation. The change is evaluated for risk: what could go wrong? What is the impact if the change fails? Does the change affect security controls (firewall rules, access policies, encryption configurations)? Does the change introduce new attack surface (new internet-facing services, new integrations, new user access)?
Security evaluation is where change management intersects with security operations. A change request to open a new firewall port should trigger a security review: why is this port needed? What service will run on it? Is the service hardened? Is it monitored? A change request to deploy a new SaaS integration should trigger a security review: what data does the integration access? How does it authenticate? What is the vendor's security posture?
Many organizations separate the security review from the general change approval: changes that affect security controls require security team approval in addition to the standard change approval board (CAB).
Approval. The Change Advisory Board (CAB) or designated approver reviews the change request, evaluation results, and implementation plan. The CAB includes representatives from operations, security, and the business unit affected by the change. Approval is documented with the approver's identity, the approval date, and any conditions (e.g., "approved for implementation during the Saturday maintenance window only").
Implementation. The change is implemented during the approved window by the authorized implementer following the documented procedure. Implementation includes pre-change verification (confirming the current state matches expectations), the change execution, and post-change verification (confirming the change achieved the intended result without unintended side effects).
Verification and closure. After implementation, the change is verified: does the system function correctly? Did the change achieve its objective? Are there any unintended impacts? If verification succeeds, the change is closed as successful. If verification fails, the rollback plan is executed and the change is closed as failed, with a root cause analysis.
Change Management and Configuration Drift
Change management is the governance process that prevents configuration drift. Every authorized change to a production system flows through the change management process and is documented. If a security monitoring tool detects a configuration change that does not have a corresponding approved change request, that change is unauthorized. Unauthorized changes are investigated: was it an attacker modifying configurations, an administrator who bypassed the process, or an automated system making an undocumented change?
The connection to CDA's APC (Autonomous Posture Command) methodology is direct. APC monitors configuration state continuously. Change management governs authorized state transitions. Together, they form a closed loop: APC detects that a configuration changed, change management confirms whether the change was authorized, and unauthorized changes trigger investigation and remediation.
Emergency Change Governance
Emergency changes are the highest-risk category because they bypass normal evaluation and approval. The urgency is real: during an active incident, the security team cannot wait 48 hours for CAB approval to block a malicious IP or isolate a compromised system. The risk is also real: emergency changes made under pressure without adequate evaluation can introduce new problems.
Emergency change governance requires: pre-authorized emergency approvers (the SOC manager or incident commander can approve emergency changes without convening the full CAB), mandatory documentation within a defined window (emergency changes must be documented within 24 to 48 hours of implementation), mandatory post-implementation review (every emergency change is reviewed by the CAB at the next scheduled meeting), and trend monitoring (an increasing volume of emergency changes may indicate that the normal process is too slow or that the environment is unstable).
An organization where 40% of changes are classified as "emergency" does not have a high-threat environment. It has a broken change management process that incentivizes bypassing normal approval.
Why It Matters
Unauthorized Changes Are a Primary Cause of Incidents
Misconfigurations caused by uncontrolled changes are among the most common root causes of security incidents. A firewall rule opened for testing and never closed. A cloud security group modified to "allow all" during troubleshooting. A database exposed to the internet by a deployment that skipped security review. Each was a change that, if it had passed through change management with security evaluation, would have been caught before it reached production.
Compliance Requirements
Change management is required by every major compliance framework. SOC 2 CC8 (Change Management) is one of the most scrutinized Common Criteria in SOC 2 audits. ISO 27001 A.8.32 (Change Management) requires documented change management processes. PCI DSS Requirement 6.5 requires change control processes for all system changes. NIST CSF 2.0 PR.PS includes change management as a platform security control.
Auditors evaluate change management by sampling: they select a random set of changes from the audit period and verify that each has a documented request, approval, implementation record, and post-change verification. Changes that lack documentation are findings. Emergency changes that were never retroactively documented are findings. Changes that bypassed the process entirely are significant findings.
Rollback Capability
Change management's requirement for a rollback plan is a business continuity control. A change that fails in production needs to be reversed quickly. Without a pre-planned rollback, the team must troubleshoot under pressure, potentially making additional uncontrolled changes that compound the problem. A documented rollback plan provides a tested path back to the known-good state.
The CrowdStrike incident's recovery required manual intervention on each affected device (booting into Safe Mode and deleting the problematic file) because the update mechanism that delivered the change could not deliver the rollback. The incident reinforced that rollback capability must be independent of the change delivery mechanism: if the delivery mechanism is broken, the rollback must still work.
CDA Perspective
Change management sits at the intersection of SPH (Security Posture and Hygiene) and RGA (Risk Governance and Assurance) in the Planetary Defense Model. SPH owns the operational process: change request workflows, implementation procedures, and post-change verification. RGA owns the governance: policy, CAB structure, audit evidence, and compliance reporting.
CDA's Autonomous Posture Command (APC) methodology integrates change management into the posture monitoring loop. Every authorized change should be reflected in the configuration baseline. A configuration change detected by APC that matches an approved change request is expected drift (authorized transition). A configuration change detected by APC with no corresponding change request is unexpected drift (potentially unauthorized) that triggers investigation.
SPH-H01 (Configuration Drift Remediation, 16 estimated hours) includes change management process assessment: is the process documented? Is it followed? Are emergency changes governed? Is there evidence of unauthorized changes bypassing the process? The mission evaluates the process and remediates gaps.
CDA approaches change management with one principle: the process must match the organization's operational speed. A startup deploying code 10 times per day cannot use a weekly CAB meeting as the approval mechanism. A hospital with life-critical systems cannot approve firewall changes through a Slack message. The change management process must be rigorous enough to prevent uncontrolled changes and fast enough to not become a bottleneck that incentivizes bypassing. CDA designs change management processes scaled to the organization's deployment velocity: lightweight for fast-moving environments (automated approval for pre-tested standard changes, expedited review for normal changes), rigorous for high-consequence environments (multi-party approval, mandatory security review, staged rollouts).
Key Takeaways
- Change management ensures every modification to production systems is intentional, reviewed, tested, approved, documented, and reversible.
- Changes are classified as standard (pre-approved, routine), normal (requires evaluation and CAB approval), or emergency (bypasses normal timeline with mandatory retroactive documentation).
- Security evaluation of changes that affect security controls (firewall rules, access policies, encryption, network configuration) should require security team approval in addition to standard CAB approval.
- Emergency change governance prevents the bypass mechanism from becoming the default mechanism. Increasing emergency change volume indicates a broken process.
- CDA's APC integrates change management into posture monitoring: authorized changes are expected drift, unauthorized changes trigger investigation.
Related Articles
- Endpoint Hardening
- Security Posture and Hygiene (SPH): The Terrain
- Compliance Program Design
- Cloud Security
- Firewall Architecture and Management
- SOC 2 Type II
Sources
- American Institute of Certified Public Accountants (AICPA). "SOC 2 Trust Services Criteria: CC8 (Change Management)." AICPA, 2017 (updated 2022).
- International Organization for Standardization. "ISO/IEC 27001:2022, Annex A.8.32 (Change Management)." ISO, 2022.
- ITIL Foundation. "ITIL 4: Change Enablement Practice." Axelos, 2019.
- PCI Security Standards Council. "PCI DSS v4.0: Requirement 6.5 (Changes Are Managed Securely)." PCI SSC, March 2022.
- CrowdStrike. "Preliminary Post Incident Review: Content Configuration Update Causing Windows BSOD." CrowdStrike, July 2024.
Word count: 1,756
Related CDA Missions
CDA Theater missions that address topics covered in this article.
Written by Evan Morgan
Found an issue? Help improve this article.