WOLF//SEC
← Domain 1
OBJECTIVE 1.3 Explain

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?

Impact analysis categories CompTIA expects:

  • Compliance impact: Does this change affect regulatory compliance? Will it invalidate a certification, change audit scope, or modify data handling?
  • Performance impact: Will response times, throughput, or resource utilization change? Load testing needed?
  • Integration impact: Does this change break APIs, data flows, or dependencies with other systems? Who needs to test on their end?
  • Availability impact: Will the change require downtime? During what window? What’s the user-facing impact?

3. Approval

Changes go through a Change Advisory Board (CABChange Advisory Board — Group that reviews and approves changes) or designated authority.

  • CABChange Advisory Board — Group that reviews and approves changes typically includes representatives from ITInformation Technology — Broad term for computing infrastructure and services, 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 (CMDBConfiguration Management Database — Central repository of configuration items and relationships)
  • 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.

  • Standard change catalog: Organization maintains a list of pre-approved change types with documented procedures
  • Pre-approval criteria: Change must be low-risk, well-understood, repeatable, and have a documented rollback procedure
  • No CABChange Advisory Board — Group that reviews and approves changes review required — the catalog IS the approval

Normal Change — Goes through full RFCRequest for Change — Formal proposal for a system/process change → 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.

  • Post-implementation review: After the emergency is resolved, the change goes through retroactive CABChange Advisory Board — Group that reviews and approves changes review
  • Review covers: was the emergency justified? Were proper procedures followed despite the urgency? What should be added to the standard catalog to prevent future emergencies?
  • Key point: “Emergency” is not an excuse to skip documentation — it just changes the timing

CAB Operations

  • Composition: ITInformation Technology — Broad term for computing infrastructure and services operations, security, application owners, business representatives, project management. Cross-functional representation ensures all impact areas are considered.
  • Quorum: Minimum attendance required for the CABChange Advisory Board — Group that reviews and approves changes to make decisions. Without quorum, changes cannot be approved (prevents end-runs around the process).
  • Meeting cadence: Regular schedule (weekly/biweekly) for normal changes. Emergency CABChange Advisory Board — Group that reviews and approves changes can be convened ad hoc.
  • Decision authority: CABChange Advisory Board — Group that reviews and approves changes recommends; a designated authority (change manager or ITInformation Technology — Broad term for computing infrastructure and services director) has final approval.

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.