Change Management

Why Most Outages Are Self-Inflicted

Study after study of major IT outages points to the same root cause: unauthorized or poorly managed changes. Not hackers. Not hardware failures. Changes. A network engineer updates a firewall rule during business hours without telling anyone. A developer pushes a database schema change that breaks the API. A system administrator applies a configuration tweak that conflicts with a security baseline nobody knew existed.

Change management exists because the fastest way to break a stable environment is to change something without understanding the impact.

This module covers CISSP exam objective 7.9. ISC2 tests your understanding of change management as a governance discipline — not the mechanics of deploying code, but the process that ensures changes are evaluated, approved, documented, and reversible.

The Change Management Process

A structured change management process ensures that every modification to the production environment is intentional, evaluated, and traceable. The process follows a consistent sequence regardless of the change’s size.

1. Request

Every change begins with a formal request that documents:

• What is being changed and why
• The systems, applications, or infrastructure affected
• The expected outcome and business justification
• The requestor and the technical team responsible for implementation

Even minor changes should be logged. Undocumented changes become invisible — impossible to correlate with incidents and impossible to audit.

2. Review and Impact Analysis

Before approval, the change must be assessed for potential impact:

• Technical impact — What systems depend on the component being changed? Will the change require downtime? Could it affect performance?
• Security impact — Does the change alter access controls, open network paths, modify encryption settings, or affect audit logging?
• Business impact — Which business processes are affected? What is the cost of downtime if the change fails?
• Compliance impact — Does the change affect systems in scope for regulatory requirements (PCI DSS, HIPAA, SOX)?

The CMDB (Configuration Management Database) is the primary tool for impact analysis. It maps dependencies between systems, so you can trace the ripple effects of changing any single component.

3. Approve

Approval authority depends on the change category and risk level. Low-risk, pre-approved changes may not need individual review. Higher-risk changes go to the Change Advisory Board (CAB).

4. Implement

The change is executed during an approved maintenance window, following the documented implementation plan. The implementation should match exactly what was approved — scope creep during a change window is a common source of unplanned outages.

5. Verify

After implementation, the team confirms that the change achieved its intended outcome without introducing side effects. Verification includes functional testing, security validation, and monitoring for anomalies.

The Change Advisory Board (CAB)

The CAB is a cross-functional group that reviews and approves changes based on risk, impact, and organizational readiness. Typical CAB membership includes:

• IT operations and infrastructure leads
• Information security representatives
• Application owners and developers
• Business stakeholders affected by the change
• Service desk representatives (who handle user-facing impact)

The CAB does not implement changes. It evaluates whether the change has been adequately assessed, tested, and planned — and whether the organization is ready for the potential consequences.

Not every change needs full CAB review. The process should be proportional to risk. A standard change that has been performed dozens of times with a known risk profile should not require the same scrutiny as a major infrastructure migration.

Change Categories

Changes are classified into categories that determine the level of review and approval required:

• Standard changes — Low-risk, repeatable changes with well-documented procedures and pre-approved authority. Examples: adding a user account, deploying a routine patch to non-critical systems, updating DNS records. These are pre-authorized and do not require individual CAB approval.
• Normal changes — Changes that require assessment, planning, and explicit approval. Most changes fall into this category. They follow the full request-review-approve-implement-verify cycle and are scheduled for approved maintenance windows.
• Emergency changes — Changes required to address an immediate threat or restore a failed service. These bypass the normal approval timeline but still require documentation and post-implementation review. An emergency change is not an undocumented change — it follows a compressed version of the same process.

The exam frequently tests whether you understand that emergency changes still require documentation and review, just on a different timeline. “It was an emergency” is never a valid excuse for skipping documentation entirely.

Emergency Change Procedures

Emergency changes are necessary when waiting for the normal approval process would cause greater harm than implementing the change immediately. Common triggers include:

• Active security incidents requiring immediate system modifications
• Critical system outages affecting business operations
• Zero-day vulnerabilities with active exploitation

The emergency change process preserves accountability while compressing timelines:

1. Verbal approval from a designated authority (typically a senior manager or on-call CAB representative)
2. Implementation with whatever testing is possible given time constraints
3. Retroactive documentation — A formal change record is created after the fact, documenting what was changed, why, by whom, and what the outcome was
4. Post-implementation review — The change is reviewed at the next CAB meeting to assess whether the process was appropriate and whether additional actions are needed

Rollback Planning

Every change plan must include a rollback procedure — the steps required to reverse the change and restore the previous state if something goes wrong. A change without a rollback plan is a gamble.

Effective rollback planning includes:

• Backups taken immediately before the change, with verified restore capability
• Rollback steps documented in the same detail as the implementation steps
• Rollback criteria — Pre-defined conditions that trigger a rollback decision (e.g., “if the application does not respond within 10 minutes of the change, execute rollback”)
• Rollback testing — For high-risk changes, the rollback procedure should be tested in advance, not assumed to work
• Time limits — A defined point at which the team must decide to proceed or roll back, preventing indefinite troubleshooting during a maintenance window

Configuration Management Integration

Change management and configuration management are tightly linked. Configuration management maintains the authoritative record of how every system is configured. Change management is the process that controls modifications to those configurations.

When they work together:

• The CMDB provides the impact analysis data needed for change review
• Approved changes update the CMDB to reflect the new configuration state
• Configuration audits detect unauthorized changes — changes that bypassed the process
• Baseline configurations define what “normal” looks like, making deviations detectable

When they do not work together, the CMDB becomes stale, impact analysis becomes unreliable, and unauthorized changes go undetected.

Change Freeze Periods

A change freeze (also called a change blackout) is a period during which no non-emergency changes are permitted. Organizations commonly enforce change freezes during:

• End-of-year financial close periods
• Major business events (product launches, holiday shopping seasons)
• Regulatory audit windows
• Periods following a major incident, while the environment is stabilized

Change freezes reduce the risk of disruption during critical business periods. Emergency changes can still be processed, but they face higher scrutiny and require senior management approval.

Release Management

Release management coordinates multiple related changes into a single, planned deployment. Rather than deploying each change independently — each with its own risk and testing overhead — release management bundles them into a tested, integrated package.

This is especially relevant for software deployments where database changes, API updates, and front-end modifications must be deployed together to function correctly. Release management ensures these dependent changes are tested as a unit and deployed as a unit.

Pattern Recognition

Change management questions on the CISSP follow these structures:

• Outage after a change — The root cause is a change management process failure: insufficient testing, missing impact analysis, no rollback plan, or scope creep during implementation.
• Unauthorized change discovered — The issue is a process bypass. The answer focuses on detection (configuration auditing) and prevention (enforcing the change process).
• Emergency scenario — The question tests whether you understand that emergency changes still need documentation and post-implementation review.
• “What should have been done first?” — Almost always impact analysis or CAB review, depending on the scenario.

Trap Patterns

Watch for these incorrect answers:

• “Emergency changes do not need documentation” — They absolutely do. The documentation happens retroactively, but it must happen. Every emergency change should be reviewed at the next CAB meeting.
• “The CAB implements changes” — The CAB reviews and approves. Technical teams implement. This separation of duties is deliberate.
• “All changes require CAB approval” — Standard (pre-approved) changes follow documented procedures without individual CAB review. Requiring CAB approval for every minor change would create bottlenecks that encourage people to bypass the process.
• “Rollback is only needed for major changes” — Every change should have a rollback plan. The depth of the plan should be proportional to risk, but even simple changes can have unexpected consequences.

Scenario Practice

Question 1

A database administrator makes a schema change to a production database during lunch hour to “save time.” No change request was submitted, no testing was performed, and no one was notified. The change causes the customer portal to return errors for two hours before the cause is identified.

Which change management failure is MOST significant?

A. The change was made during lunch hour instead of a maintenance window
B. The change bypassed the entire change management process, including review, approval, and testing
C. The database administrator did not have the technical skills to make the change
D. The customer portal should have been designed to handle database schema changes gracefully

Question 2

During an active ransomware incident, the incident response team needs to immediately isolate three network segments by modifying firewall rules. The next scheduled CAB meeting is in four days.

What is the CORRECT approach?

A. Wait for the CAB meeting to approve the firewall changes
B. Implement the changes immediately under emergency change procedures with verbal approval, then document retroactively
C. Implement the changes without documentation since the incident takes priority over process
D. Submit an expedited change request and wait for email approval from all CAB members

Question 3

An organization’s configuration audit reveals that 12 production servers have configurations that do not match the approved baseline in the CMDB. Operations staff cannot explain when or why the changes were made. No change records exist for these modifications.

What does this finding indicate?

A. The CMDB baseline is outdated and should be updated to reflect current configurations
B. Unauthorized changes have been made outside the change management process
C. Configuration drift is normal and does not require investigation
D. The configuration audit tool is producing false positives

Key Takeaway