Explain the importance of change management processes and the impact to security

Change management exists because uncontrolled changes are the number one source of outages and security incidents. Every misconfiguration, every “quick fix” deployed without review, every unauthorized patch — these are changes that bypassed the process.

The Change Management Process

1. Request for Change (RFC)

Formal proposal documenting what’s changing, why, and how.

• Includes: description, justification, scope, affected systems, rollback plan
• Not just for code — infrastructure changes, firewall rule modifications, policy updates

2. Impact Analysis

Before approving anything, assess what could break.

• Dependencies: What systems/services rely on the component being changed?
• Security impact: Does this open new attack surface? Weaken existing controls?
• User impact: Downtime windows, workflow disruptions
• Rollback complexity: How hard is it to undo if something goes wrong?

3. Approval

Changes go through a Change Advisory Board (CAB) or designated authority.

• CAB typically includes representatives from IT, security, business units, and operations
• Risk-weighted: routine changes may have pre-approved fast-track; high-risk changes get full review
• Emergency changes have an expedited process but still require documentation after the fact

4. Testing

Validate in a non-production environment before deployment.

• Staging/pre-production environment that mirrors production
• Test the change AND test the rollback procedure
• Security testing: verify the change doesn’t introduce vulnerabilities

5. Implementation

Execute the change according to the approved plan.

• Follow the maintenance window / deployment schedule
• Document any deviations from the plan in real-time
• Have the rollback plan ready to execute immediately

6. Documentation and Closure

Record what was done, when, by whom, and the outcome.

• Update configuration management database (CMDB)
• Close the change ticket
• Lessons learned if anything deviated from plan

Key Concepts

Ownership

Every change has an owner accountable for its success and security implications. “Somebody changed it” is not acceptable — every change maps to a person and an approval.

Stakeholders

People affected by the change who must be consulted or informed:

• System owners, security team, end users, management
• Exam focus: The question will describe a change and ask who should be involved

Version Control

Track all changes to code, configuration, and documentation.

• Enables rollback to known-good states
• Provides audit trail of what changed, when, and by whom
• Security relevance: Unauthorized changes to version-controlled assets are immediately visible

Backout/Rollback Plan

Every change must have a documented path back to the previous state.

• Tested before the change is implemented
• Includes success criteria: “If X doesn’t work within Y minutes, we roll back”
• Exam trap: A change without a rollback plan should not be approved

Maintenance Windows

Scheduled time periods for implementing changes with minimal business impact.

• Defined in SLAs
• Emergency changes may happen outside windows but require stronger justification

Configuration Management

Maintaining a documented baseline of system configurations.

• Baseline: Known-good configuration that all systems should match
• Drift detection: Automated comparison of actual vs. baseline configuration
• Unauthorized drift = potential compromise indicator

Change Types

Standard Change — Pre-approved, low-risk, follows a documented procedure. Examples: password resets, adding a user to an existing group.

Normal Change — Goes through full RFC → approval → implementation lifecycle. Most changes fall here.

Emergency Change — Bypasses normal approval for critical issues (active security incident, production-down). Still documented — just after the fact.

Technical Implications

Allow/Deny Lists

Changes to application allow/deny lists affect what software can execute. Must go through change management because:

• Adding to an allow list expands the attack surface
• Removing from a deny list may re-enable previously blocked threats

Downtime and Service Restarts

Changes often require service restarts or brief outages.

• Plan for impact on dependent systems
• Communicate maintenance windows to affected users
• Stagger deployments to maintain availability (rolling updates)

Offensive Context

Attackers love environments with weak change management. If changes aren’t tracked, an attacker can modify firewall rules, install backdoors, or alter configurations — and nobody notices because untracked changes are normal. Strong change management means every unexpected change is an anomaly worth investigating. It’s a detective control disguised as a process.