2 Change Management and Security · Security+

Exam objective 1.2: Given a scenario, demonstrate the impact of change management processes on security.

This objective covers the business processes, technical implications, and documentation practices that turn change from a source of risk into a controlled, auditable activity. It includes the change advisory board (CAB) and its approval process, ownership and stakeholders, impact analysis, test results, backout planning, fail forward, maintenance windows, and standard operating procedures. It also covers the technical side of change: allow lists and deny lists, restricted activities, downtime, service and application restarts, legacy applications, and dependencies. Finally, it covers keeping documentation current—diagrams, policies, and procedures—and version control.

This is a "given a scenario" objective, which means the exam will describe a situation and ask you to apply the right part of the process. You might be asked what step was skipped before an outage, which document should have been updated after a firewall change, who should approve a change, or what to do when an update fails in production. Study the purpose of each element, not just its definition, so you can recognize which one is missing or misapplied in a story.

Why Change Management Is a Security Topic

Most outages are not caused by attackers. They are caused by changes: a patch that breaks a driver, a firewall rule that blocks a payment processor, a certificate that expires because nobody tracked it, or a configuration edit made at 2 p.m. on a Friday by someone who assumed it was harmless. Industry studies have consistently found that a large share of unplanned downtime traces back to changes made by the organization itself. Because availability is one leg of the CIA triad (Chapter 1), anything that threatens availability is a security concern.

Change also affects confidentiality and integrity. A rushed change might open a port to the internet, disable logging, grant an overly broad permission, or leave a debug interface exposed. Uncontrolled change makes it nearly impossible to know what the environment should look like, which in turn makes it hard to spot what an attacker has changed. If administrators routinely make undocumented edits, an attacker's malicious edit blends right in.

Change management is the formal process an organization uses to request, evaluate, approve, implement, verify, and document changes to its systems, applications, and infrastructure. Its goals are to:

Reduce the risk of outages and security weaknesses introduced by change.
Ensure that the right people review and approve changes before they happen.
Make sure every change can be undone or recovered from if it goes wrong.
Maintain an accurate record of the environment for operations, audits, and investigations.
Balance the need for agility (patching quickly, shipping features) against the need for stability.

Note

You will sometimes see change management and change control used interchangeably. Strictly, change management is the overall governance process (policies, roles, the CAB), while change control refers to the specific mechanisms that enforce it (request forms, approvals, technical gates). Configuration management is a related discipline that tracks the approved state of systems—their baselines—so that you can detect drift. On the exam, focus on the purpose described in the question rather than the exact label.

A Typical Change Management Workflow

Every organization tailors the process, but most follow a similar flow:

1. Request. Someone submits a change request (often called an RFC, request for change) in a ticketing system describing what will change, why, when, and who will do it.
2. Assess. The change owner and technical reviewers perform an impact analysis, identify risks and dependencies, and attach test results and a backout plan.
3. Approve. The appropriate authority—often the change advisory board—approves, rejects, or requests more information.
4. Schedule. The change is assigned to a maintenance window and stakeholders are notified.
5. Implement. Technicians carry out the change following the documented steps or SOP.
6. Verify. The team tests that the change worked and did not break anything else. If it failed, they execute the backout plan or fail forward.
7. Document and close. Diagrams, policies, procedures, baselines, and the configuration management database (CMDB) are updated, and the ticket is closed with a record of the outcome.

Figure 2.1: A typical change management workflow with its feedback and failure paths Phase Key question answered Main artifacts

Request What do we want to change and why? Change request ticket

Assess What could this affect and how risky is it? Impact analysis, test results, backout plan Approve Should we do this, and is the plan sound? CAB decision, approval record Schedule When will it cause the least disruption? Maintenance window, stakeholder notice Implement How exactly do we perform it? SOP or runbook, implementation log Verify Did it work without side effects? Post-change test results, monitoring Document Does our documentation match reality? Updated diagrams, policies, CMDB, version history

Business Processes Impacting Security Operations

Change Advisory Board (CAB) and the Approval Process

A change advisory board (CAB) is a group of people who review proposed changes and recommend or grant approval. A CAB typically includes representatives from IT operations, security, networking, application owners, the service desk, and sometimes business units that depend on the affected systems. Because members come from different areas, the CAB can spot risks that the person proposing the change might miss: the network engineer does not know that the finance team runs month-end close on the night of the planned switch upgrade, but the finance representative does. The approval process defines who must approve which changes. Most organizations do not send every change to a full board meeting. Instead, they classify changes by risk and route them accordingly: Change type

Description Approval path Example

Standard Low risk, frequent, well understood, follows a pre-approved procedure

Pre-approved; no CAB review each time

Resetting a password, adding a user to a group, routine signature updates

Normal (minor or major)

Requires assessment because risk or impact varies

Must happen immediately to restore service or address an active threat

Expedited approval by an emergency CAB (ECAB) or designated authority, with documentation completed afterward

Patching an actively exploited zero-day, blocking an attacker's IP during an incident

The security team's role on the CAB is to evaluate whether a change introduces new vulnerabilities, weakens existing controls, or conflicts with policy or compliance requirements. A proposal to open RDP to the internet "temporarily" for a vendor, for example, should prompt the security representative to ask for an alternative such as a VPN or a jump server with MFA.

Exam tip

Emergency changes still go through change management—just faster. If a question describes an urgent patch for an actively exploited vulnerability, the correct answer is usually to use the emergency change process (expedited approval, then retroactive documentation and review), not to skip the process entirely and not to wait for the next scheduled CAB meeting.

Common trap

Approval is a control only if the approver is independent of the person doing the work. An administrator who approves their own change has defeated separation of duties (Chapter 1). If a scenario says the same person requested, approved, and implemented a high-risk change, identify that as the process failure.

Ownership

Every change needs a clearly identified owner: the person or team accountable for the change from request through closure. The owner is responsible for describing the change accurately, coordinating the impact analysis, ensuring testing is done, preparing the backout plan, and confirming the outcome. Ownership answers the question, "Who do we call when something goes wrong at 3 a.m.?" Ownership also applies to the systems being changed. A system owner or application owner (often a business manager) is accountable for the asset and typically must agree to changes that affect it. The technician who makes the change is not necessarily the owner.

Stakeholders

Stakeholders are the people and groups who are affected by a change or who have an interest in its outcome. They include end users, business unit managers, customers, help desk staff, security and compliance teams, third-party vendors, and sometimes regulators. Stakeholders must be identified early so they can contribute to the impact analysis and so they can be notified before the change happens. A change can be technically perfect yet disastrous for the business because it happened during a sales event or because the help desk was not told to expect calls.

Real-world scenario

An e-commerce company's infrastructure team upgrades the TLS configuration on its public API gateway to disable TLS 1.0 and 1.1—a sound security change. The change was approved by the CAB, but no one notified the logistics partner whose decade-old shipping system connects to the API. The next morning, the partner's system fails to connect and orders stop shipping. The security improvement was correct; the failure was in stakeholder identification and communication. A proper process would have identified the partner as a stakeholder, warned them in advance, and perhaps provided a transition period.

Impact Analysis

An impact analysis examines what a proposed change will affect and how badly things could go wrong. It considers:

Scope: which systems, applications, users, and locations are touched.
Risk: the likelihood that the change will fail or have unintended effects, and how severe those effects would be.
Security impact: whether the change alters the attack surface, permissions, encryption, logging, or compliance posture.
Operational impact: expected downtime, performance changes, and effects on dependent systems.
Risk of not changing: what happens if the change is delayed or rejected—for example, leaving a critical vulnerability unpatched.

That last point matters. Impact analysis is not just a list of reasons to say no. A patch for an actively exploited vulnerability has some risk of breaking an application, but the risk of not applying it may be far greater. Good impact analysis weighs both sides so the CAB can make an informed decision. The output of an impact analysis is often a risk rating (low, medium, high) that determines the approval path, the required level of testing, and whether the change needs a maintenance window.

Test Results

Before a change reaches production, it should be tested in an environment that resembles production as closely as possible. Test results provide evidence to the CAB that the change works as intended and does not break anything else. Typical environments include:

Development: where changes are built.
Test/QA: where functional and regression testing occurs.
Staging (pre-production): a near-copy of production used for final validation.
Production: the live environment.

Testing should verify both functionality and security: does the application still enforce authentication after the update? Are the expected ports still closed? Does logging still reach the SIEM? Test results are attached to the change request so approvers can see that the change was validated. A change request that arrives at the CAB with no test results—or with tests performed only on the developer's laptop— should be sent back.

A test environment that does not match production (different OS versions, missing integrations, smaller data volumes) can produce false confidence, which is one reason backout plans remain necessary even for well-tested changes.

Backout Planning

A backout plan (also called a rollback plan) describes how to reverse a change and return the system to its previous known-good state if the change fails or causes unacceptable side effects. Every non-trivial change should have one, written before the change begins.

A good backout plan includes:

Trigger criteria: the conditions that will cause the team to back out (for example, "if the application health check fails for more than 10 minutes" or "if users cannot authenticate").
Steps: the specific actions to restore the previous state, such as reverting a configuration file from version control, restoring a VM snapshot, uninstalling a patch, or restoring a database backup.
Time required: how long the backout will take, which must fit inside the maintenance window.
Verification: how the team will confirm that the rollback succeeded.
Prerequisites: backups or snapshots that must be taken before the change starts.

CHANGE REQUEST CR-2026-0418 -- Backout Plan

Pre-change: Snapshot VM app-prod-02 (verify snapshot ID logged in ticket)

Export current firewall ruleset to config repo (commit hash recorded)
Trigger: Login success rate < 95% for 10 min OR P1 incident opened
Steps: 1. Revert VM app-prod-02 to pre-change snapshot

2. Re-apply firewall ruleset from recorded commit
3. Restart app service; run smoke test suite

Duration: 25 minutes (window ends 04:00; decision point no later than 03:15)

Verify: Smoke tests pass; monitoring dashboard green for 15 min

Figure 2.2: The backout decision point must leave enough time to roll back and verify before the maintenance window closes

Exam tip

Notice the "decision point" in the example above. The backout must be started early enough to finish before the maintenance window closes. If a question asks why a failed change extended beyond its window, a missing or unrealistic backout timeline is a likely answer.

Fail Forward

Sometimes rolling back is impossible, more dangerous than continuing, or simply slower than fixing the problem. Fail forward (also called fix forward or roll forward) means responding to a failed or problematic change by applying a further corrective change rather than reverting to the previous state. Situations where failing forward may be the right choice include:

Irreversible changes, such as a database schema migration that has already transformed data in a way that the old application version cannot read.
Security fixes, where rolling back would reintroduce a known, actively exploited vulnerability.
Small, well-understood defects, where a quick patch is faster and less disruptive than a full rollback.
Modern CI/CD pipelines, where deploying a new version takes minutes and rolling back may be no faster than rolling forward.

Fail forward is not an excuse to skip backout planning. It is a deliberate decision, ideally made in advance as part of the change plan, that recognizes rollback is not always the safest option. Fail-forward changes still require approval (often through the emergency process), testing proportional to the risk, and documentation.

Approach What happens Best when Risk

Backout (rollback)

Return to the previous known-good state

Change is reversible and the old state is safe

Reintroduces whatever the change

was meant to fix

Fail forward

Apply a new fix on top of the failed change

Rollback is impossible, slower, or would reintroduce a vulnerability

The fix itself is a rushed change that may introduce new problems

Real-world scenario

A healthcare provider patches its web portal to fix a critical remote code execution vulnerability that is being exploited in the wild. After the patch, the appointment-booking page shows a formatting error. Rolling back would restore the booking page but reopen the actively exploited vulnerability. The team decides to fail forward: it keeps the security patch in place, applies a small CSS fix through an emergency change, and documents the decision. Here, failing forward protects security better than a rollback would.

Maintenance Window

A maintenance window is a pre-scheduled period during which changes may be made, chosen to minimize disruption to users and the business. Maintenance windows are commonly set during nights, weekends, or other low-usage periods, and they are often written into service level agreements (SLAs) so customers know when brief outages may occur.

Maintenance windows matter for security in several ways:

They reduce the business impact of downtime caused by changes.
They ensure that the right staff are available and focused during the change.
They create a predictable time when monitoring teams can expect alerts and service restarts, so that unexpected activity outside the window stands out as suspicious.
They can conflict with patching urgency. A critical vulnerability may not be able to wait two weeks for the next window, which is when the emergency change process applies.

A security operations center (SOC) should know the maintenance schedule. If the SOC sees a domain controller reboot at 2 a.m. during an approved window, that is expected; the same reboot at 2 p.m. on a Tuesday with no change ticket deserves investigation.

Common trap

Attackers know about maintenance windows too. Holiday weekends and overnight windows are periods of reduced staffing and expected noise. Change management helps here: if every legitimate change is ticketed, analysts can quickly separate approved activity from suspicious activity.

Standard Operating Procedures (SOPs)

A standard operating procedure (SOP) is a documented, step-by-step set of instructions for performing a routine task consistently and correctly. In change management, SOPs serve two purposes. First, they make standard (pre-approved) changes safe: because the steps are documented and proven, the change can be performed without a CAB review each time. Second, they make implementation of normal changes repeatable, reducing the chance that a technician skips a step or improvises. SOPs are part of the managerial and operational control framework you will see again in Chapter 22, where procedures, runbooks, and playbooks are discussed as governance artifacts. A good SOP includes prerequisites, exact steps, expected results at each step, verification checks, and escalation contacts. SOPs must be kept current: an SOP that references a retired system or an old command syntax is worse than useless, because it gives false confidence.

Memory aid

The business-process elements form a natural story: an owner writes the request, stakeholders are consulted, an impact analysis and test results are attached, a backout plan (or fail-forward decision) is prepared, the CAB approves, the work happens in a maintenance window, and technicians follow the SOP. If a question describes a broken story, find the missing chapter.

Technical Implications

Business processes govern how a change is approved. Technical implications describe what the change can affect in the environment. The CAB and the change owner should consider each of the following during impact analysis.

Allow Lists and Deny Lists

An allow list (formerly called a whitelist) permits only explicitly approved items—applications, IP addresses, domains, file hashes, or users—and blocks everything else. A deny list (formerly called a blacklist or block list) blocks specific known-bad items and permits everything else. Allow lists are more restrictive and generally more secure; deny lists are easier to manage but miss anything not yet listed. Chapter 14 covers application allow listing and block listing as mitigation techniques. Change management interacts with these lists in two directions:

Changes may require list updates. Installing a new application on endpoints protected by application allow listing will fail—or the application will be blocked at launch—unless the allow list is updated to include the new executable or its signing certificate. Upgrading software changes file hashes, so hash-based allow lists must be updated for every version. A new partner integration may require adding the partner's IP range to a firewall allow list.
List updates are themselves changes. Adding an entry to an allow list widens what is permitted; removing an entry from a deny list does the same. These modifications must be reviewed, because an overly broad entry (such as allowing an entire cloud provider's IP range, or allowing a whole directory rather than a specific executable) can create a significant hole.

Real-world scenario

A manufacturer uses application allow listing on its engineering workstations. The IT team pushes an updated version of the CAD software through its deployment tool, but the next morning no engineer can open the application. The new version has a different file hash, and the allow list was not updated as part of the change. The impact analysis should have identified the allow list as a dependency, and the change plan should have included updating it—preferably by allowing the vendor's code-signing certificate rather than individual hashes.

Restricted Activities

Restricted activities are actions that are limited or prohibited during a change, or that a change is not permitted to perform without explicit additional approval. Change requests define a scope, and technicians should not go beyond it. Examples include:

Making changes to systems that are not listed in the approved change request ("While I was in there, I also updated the other server").
Modifying security controls such as firewall rules, logging settings, or EDR policies as part of an unrelated change.
Performing changes outside the approved maintenance window.
Using privileged accounts for activities not covered by the change.
Making changes during freeze periods, such as the weeks before a major retail holiday or the close of a fiscal year, when only emergency changes are permitted.

Scope creep during implementation is a significant risk. An unapproved "small fix" bypasses impact analysis, testing, and the backout plan, and it leaves documentation out of date. If the unapproved change causes an outage, troubleshooting is harder because the change record does not reflect what was actually done.

Exam tip

If a scenario describes a technician who made an additional, unapproved modification during an approved change—and that modification caused the problem—the issue is a violation of restricted activities and change scope. The fix is to submit a separate change request for any work outside the approved scope.

Downtime

Downtime is the period during which a system or service is unavailable. Some changes require planned downtime (for example, rebooting a server after a kernel patch or migrating a database). Impact analysis must estimate how much downtime a change will cause, whether that fits within the maintenance window and SLA commitments, and whether redundancy can avoid downtime entirely.

High-availability designs (Chapter 13) reduce change-related downtime. With a load-balanced cluster, administrators can drain traffic from one node, patch it, return it to service, and repeat for the next node—a rolling update that keeps the service available throughout. Blue-green deployments, in which a new environment is built alongside the old one and traffic is switched over, serve the same goal and also make backout easy: switch traffic back.

Downtime has security implications beyond inconvenience. Security tools themselves may be affected: if the SIEM collector, the EDR management server, or the authentication service is down during a change, the organization may be blind or unable to enforce controls during that window.

Service Restart and Application Restart

Many changes take effect only after a service restart or application restart. Configuration file edits, certificate replacements, library updates, and patches often require restarting a daemon, a Windows service, a web server, or an entire application stack.

Restarts have several implications:

Brief unavailability: even a quick restart drops active connections and sessions. Users may lose unsaved work or need to log in again.
Startup failures: a service that ran fine for months may fail to start after a restart because of an unrelated latent problem—an expired certificate, a changed password on a service account, a missing dependency, or a configuration error introduced long ago but never loaded.
Order of operations: some services must start before others (a database before the application that uses it).
Security state: a restart may reset in-memory settings, clear temporary blocks, or load a configuration that differs from what was running. It is also the moment when malicious persistence mechanisms execute, so unexpected restarts deserve attention.

A service restart restarts a background process (such as sshd or a Windows service); an application restart restarts a user-facing program or whole application stack, which may involve multiple services and require users to reconnect.

# Linux: validate config before restarting to avoid a failed start
$ sudo nginx -t
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ sudo systemctl restart nginx
$ systemctl status nginx --no-pager | head -3

nginx.service - A high performance web server

Active: active (running) since Sun 2026-10-04 02:14:07 UTC; 4s ago

# Windows: restart a service from PowerShell

PS> Restart-Service -Name "W3SVC" -Force

Note

Validating a configuration before restarting (as with nginx -t above) is a simple but powerful practice. Many outages happen because a service with a syntax error in its configuration file refuses to start after a restart, turning a minor change into an unplanned outage.

Legacy Applications

Legacy applications are older applications that are still in use but may be unsupported by the vendor, built on outdated platforms, poorly documented, or understood by only a few people. They present special challenges for change management:

Fragility: legacy applications may break when underlying operating systems, libraries, or protocols change. Disabling an old protocol (such as SMBv1 or TLS 1.0) for security reasons can stop a legacy application from working.
Lack of vendor support: there may be no patches available, no one to call when something goes wrong, and no documentation of dependencies.
Limited testing: there may be no test environment, because the original installation media or licenses are long gone.

Because legacy applications are hard to change safely, organizations often protect them with compensating controls (Chapter 1) such as network isolation, strict access controls, and enhanced monitoring rather than modifying them directly. When changes are unavoidable, impact analysis must be especially thorough and backout plans especially robust. Chapter 7 discusses unsupported and obsolete systems as a vulnerability category.

Dependencies

A dependency is a relationship in which one system, service, or component relies on another to function. Changes to one component can break everything that depends on it. Dependencies include:

Service dependencies: an application depends on a database, DNS, an authentication service, a message queue, or an external API.
Software dependencies: an application depends on specific versions of libraries, frameworks, runtimes (such as Java or .NET), or operating system features.
Infrastructure dependencies: services depend on network paths, firewall rules, load balancers, certificates, and storage.
Startup dependencies: services must start in a particular order.

Dependencies are a primary focus of impact analysis. Tools such as a configuration management database (CMDB), application dependency mapping, and up-to-date network diagrams help identify them. Missed dependencies are one of the most common causes of change-related outages: the team patches a server without realizing that a critical batch job on another system connects to it every night.

Real-world scenario

A systems administrator renews the TLS certificate on an internal LDAP server and switches it to a new internal certificate authority. The directory works perfectly for Windows clients, which trust the new CA through Group Policy. But a Linux-based HR application that binds to LDAP over TLS has its own trust store containing only the old CA. HR logins fail. The dependency—the HR application's trust store—was never mapped. A thorough impact analysis would have listed every system that connects to the LDAP server and checked which CAs each one trusts (certificate trust is covered in Chapter 3).

Figure 2.3: A missed dependency in which one client trusts the new CA and another trusts only the old CA Documentation

Change management is not complete until documentation reflects the new reality. Outdated documentation is a security risk because incident responders, auditors, and administrators make decisions based on it. If the network diagram shows a segment as isolated but a recent change connected it to the corporate network, a responder may fail to contain an incident properly.

Updating Diagrams

Network diagrams, data flow diagrams, architecture diagrams, and rack diagrams must be updated whenever a change alters what they depict. Diagrams are used for:

Incident response: responders use diagrams to understand where an attacker could move and what to isolate.
Impact analysis: future change requests rely on accurate diagrams to identify dependencies.
Audits and compliance: assessors (for example, for PCI DSS) require accurate diagrams showing where sensitive data flows and which systems are in scope.

A change that adds a new VLAN, a new firewall, a new cloud connection, or a new data flow should include "update diagrams" as an explicit task in the change plan, with the change not considered closed until the update is done.

Updating Policies and Procedures

Changes can also make policies and procedures obsolete. If an organization replaces its VPN with a Zero Trust network access solution, the remote access policy, the onboarding procedure, the help desk troubleshooting guide, and the incident response playbook for compromised remote accounts may all need revision. If a new logging platform is deployed, the log retention procedure and the SOC's investigation procedures must reflect it.

Policy and procedure updates often need their own approval because policies are managerial controls owned by management. The change process should flag when a technical change triggers a documentation change, so the policy owner can review it. Chapter 22 covers policies, standards, and procedures as governance artifacts.

Exam tip

When a question asks what step should follow a successful change to network architecture, look for "update the network diagram" or "update documentation." When a question describes responders being misled by inaccurate documentation during an incident, the root cause is a failure to update documentation as part of change management.

Version Control

Version control is the practice of tracking and managing changes to files over time, so that every revision is recorded with who made it, when, and why, and earlier versions can be retrieved. Software developers use version control systems such as Git for source code, but version control applies equally to:

Configuration files for servers, network devices, and firewalls.
Infrastructure as code (IaC) templates such as Terraform or CloudFormation (Chapter 10).
Scripts and automation playbooks (Chapter 19).
Policies, procedures, SOPs, and diagrams.
Group Policy objects and security baselines.

Version control supports security and change management in several ways:

Accountability and audit trail: every change is attributed to an identity with a timestamp and description, supporting accounting and non-repudiation (especially when commits are digitally signed).
Rollback: a backout plan can be as simple as reverting to a previous commit.
Comparison: diffs show exactly what changed between versions, which helps troubleshooting and detects unauthorized modifications.
Review: pull requests (merge requests) let a second person review and approve a change before it is merged, enforcing separation of duties.
Integrity of the baseline: the repository holds the known-good configuration that systems should match.

$ git log --oneline -3 firewall/edge-fw01.conf

a41c9e2 CR-2026-0418: allow TCP/443 from partner range 203.0.113.0/24 to api-gw 7be1f03 CR-2026-0391: remove legacy FTP rule (TCP/21) per decommission

19d0aa4 CR-2026-0350: baseline after quarterly review
$ git diff 7be1f03 a41c9e2 -- firewall/edge-fw01.conf
+ permit tcp 203.0.113.0/24 host 198.51.100.20 eq 443

Notice that each commit message references a change request number. Linking version control commits to change tickets ties the technical record to the approval record, so an auditor can confirm that every configuration change was authorized.

Common trap

Version control systems can leak secrets. Committing passwords, API keys, or private keys to a repository —especially a public one—is a serious and common mistake, and removing the file in a later commit does not remove it from history. Chapter 14 discusses secrets scanning for repositories, and Chapter 7 covers public repositories as an attack surface.

Change Management and Security Operations Together

Change management connects to much of the rest of the security program. Patches are changes, so vulnerability management (Chapter 16) depends on it. Approved change records let monitoring teams (Chapter 17) separate authorized activity from suspicious activity. Containment actions during incident response (Chapter 20) are emergency changes, and lessons learned often produce new change requests. CI/CD pipelines and infrastructure as code (Chapter 19) build change control into the toolchain with automated tests, required reviews, and automatic rollback.

Real-world scenario

A SOC analyst receives a file integrity monitoring alert: the sshd_config file on a production Linux server changed at 01:12, enabling password authentication and root login. She checks the change management system and finds no approved change for that server. That absence turns a routine-looking configuration edit into a probable security incident. She escalates, and the investigation finds that an attacker with stolen credentials modified the file to maintain access. Strong change management made the unauthorized change stand out.

Chapter Summary

Change management is the formal process for requesting, assessing, approving, implementing, verifying, and documenting changes. It protects availability, integrity, and confidentiality by preventing poorly planned or unauthorized changes.
The change advisory board (CAB) reviews and approves changes. The approval process scales with risk: standard changes are pre-approved, normal changes go through review, and emergency changes receive expedited approval with documentation afterward.
Every change needs a clear owner, and all affected stakeholders should be identified, consulted, and notified.
Impact analysis evaluates scope, risk, security impact, dependencies, and the risk of not making the change. Test results from a production-like environment provide evidence that the change works.
A backout plan describes how to restore the previous known-good state, with trigger criteria and a timeline that fits the maintenance window. Fail forward fixes a problem with a further change when rollback is impossible, slower, or would reintroduce a vulnerability.
Maintenance windows schedule changes for low-impact times and help analysts distinguish expected activity from suspicious activity. SOPs make routine changes consistent and repeatable.
Technical implications include updating allow lists and deny lists, respecting restricted activities and change scope, planning for downtime, service restarts, and application restarts, protecting fragile legacy applications, and mapping dependencies.
Documentation must be kept current: update diagrams and update policies and procedures after changes. Version control provides an audit trail, rollback capability, and peer review for code, configurations, and documents.

Key Terms

Change management; change control; configuration management; request for change (RFC); change advisory board (CAB); emergency CAB (ECAB); approval process; standard change; normal change; emergency change; change owner; system owner; stakeholder; impact analysis; test results; staging environment; backout plan; rollback; fail forward; maintenance window; change freeze; standard operating procedure (SOP); allow list; deny list; restricted activities; scope creep; downtime; rolling update; blue-green deployment; service restart; application restart; legacy application; dependency; configuration management database (CMDB); network diagram; version control; commit; pull request; configuration drift.

Review Questions

1. A network engineer submits a change request to replace the core switches at a regional office. The CAB rejects the request because it does not describe how the team would restore connectivity if the new switches fail. Which element is missing from the request?

A. Impact analysis
B. Backout plan
C. Stakeholder list
D. Standard operating procedure

2. A critical vulnerability in an internet-facing VPN appliance is being actively exploited, and the vendor has released a patch. The next scheduled CAB meeting is in nine days. What should the security team do?

A. Wait for the next CAB meeting to ensure proper review
B. Apply the patch immediately without creating a change record
C. Submit an emergency change for expedited approval and complete documentation afterward
D. Disable change management for security patches

3. During an approved change to update a web server's TLS certificate, a technician notices an outdated firewall rule and deletes it. The next day, a nightly backup job fails because it relied on that rule. Which change management principle did the technician violate?

A. Fail forward
B. Restricted activities and change scope
C. Version control
D. Maintenance window

4. A company deploys a new version of its accounting software to workstations protected by application allow listing. After deployment, the application will not launch. What is the MOST likely cause?

A. The application requires a service restart on the domain controller
B. The allow list was not updated to permit the new version's executable
C. The deny list contains the vendor's domain
D. The change was performed outside the maintenance window

5. A development team deploys a database schema migration that converts customer records to a new format. A bug in the new application release causes errors on one report. The old application version cannot read the converted data. What is the BEST approach?

A. Restore the database from last week's backup
B. Roll back the application to the previous version
C. Fail forward by deploying a corrected release
D. Leave the bug in place until the next quarterly maintenance window

6. After a firewall change creates a new DMZ segment, which of the following should be updated as part of closing the change? (Select TWO.)

A. Network diagrams
B. The acceptable use policy signed by employees
C. The version-controlled firewall configuration
D. The organization's risk appetite statement
E. The CAB membership list

7. A SOC analyst notices that a production database server rebooted at 2:30 p.m. on a weekday. Which piece of information would MOST quickly help the analyst determine whether the reboot was authorized?

A. The server's CPU utilization history
B. The change management records and maintenance schedule
C. The organization's data classification policy
D. The vendor's end-of-life notice

8. An organization runs a 15-year-old inventory application that only supports TLS 1.0. The security team wants to disable TLS 1.0 across the environment. Which considerations are MOST relevant to the change? (Select TWO.)

A. Legacy application compatibility
B. Key escrow requirements
C. Dependencies on the inventory system by other business processes
D. Wildcard certificate support
E. Salting requirements

9. Which change type is typically pre-approved, low risk, and performed by following a documented procedure without CAB review each time?

A. Emergency change
B. Normal change
C. Standard change
D. Major change

10. A change to replace an LDAP server's certificate causes logins to fail for a Linux-based application, while Windows clients work normally. The impact analysis did not consider the application. Which aspect of the impact analysis was MOST likely inadequate?

A. Identification of dependencies
B. Scheduling of the maintenance window
C. Approval by the CAB
D. Selection of the change owner

11. An administrator wants to ensure that every change to router configurations is attributed to a specific person, can be compared against prior versions, and can be reverted quickly. Which practice BEST meets these goals?

A. Maintenance windows
B. Version control
C. Deny lists
D. Stakeholder notification

12. A retailer's CAB approved a payment gateway upgrade, and testing in staging succeeded. However, the change was scheduled for the Saturday before a major holiday, and when it caused a 40-minute outage, sales were lost. Which elements of the process should have prevented this timing problem? (Select TWO.)

A. Stakeholder involvement from the business
B. Hash-based allow listing
C. Selection of an appropriate maintenance window and observation of change freeze periods
D. Application restart
E. Version control

Answers and Explanations

1. B. A backout plan describes how to reverse a change and restore the previous state if it fails. The request lacks a way to restore connectivity, which is precisely what a backout plan provides. An impact analysis describes what could be affected, not how to recover. A stakeholder list and an SOP do not address recovery from failure.
2. C. Emergency changes still follow change management, using an expedited approval path (such as an emergency CAB) with documentation completed afterward. Waiting nine days leaves an actively exploited vulnerability open. Patching with no record at all bypasses accountability and makes later troubleshooting and auditing harder. Disabling change management for patches removes an important control.
3. B. The technician made a change outside the approved scope—a restricted activity. Unapproved changes bypass impact analysis, which would likely have identified the backup job's dependency on the rule. Fail forward, version control, and maintenance windows do not describe the violation.
4. B. Application allow lists permit only approved executables, often identified by hash, path, or publisher. A new version usually has a new hash, so the allow list must be updated as part of the change. A domain controller service restart is unrelated, a deny list on the vendor's domain would not block a local executable, and the timing of the change would not prevent the application from launching.
5. C. Because the data migration is irreversible and the old version cannot read the converted data, rolling back the application would make things worse. Restoring last week's backup would lose a week of data. Failing forward with a corrected release is the best option. Leaving a known bug in production until next quarter is not appropriate.
6. A, C. A new DMZ segment changes the network architecture, so network diagrams must be updated, and the firewall configuration should be committed to version control so the new baseline is tracked. The acceptable use policy, risk appetite statement, and CAB membership are not directly affected by a new network segment.
7. B. Change records and the maintenance schedule show whether a reboot was approved and expected. An unexplained reboot with no matching change record warrants investigation. CPU history, the data classification policy, and the vendor's end-of-life notice do not show authorization.
8. A, C. The inventory application is a legacy application that may break if TLS 1.0 is disabled, and other business processes may depend on it, so the change could have wider effects. Key escrow, wildcard certificates, and salting are cryptographic topics unrelated to this compatibility question.
9. C. Standard changes are low risk, frequent, and pre-approved, following an SOP. Emergency changes receive expedited approval because of urgency. Normal and major changes require assessment and CAB review.
10. A. The application depended on the LDAP server and on its own certificate trust store, and the impact analysis failed to identify that dependency. The timing, approval, and owner selection do not explain why one dependent system was overlooked.
11. B. Version control records who made each change and when, shows differences between versions, and allows quick reversion to a previous version. Maintenance windows govern timing, deny lists block items, and stakeholder notification communicates changes but does not record or revert them.
12. A, C. Business stakeholders would have identified the holiday weekend as a high-risk time, and choosing an appropriate maintenance window while respecting change freeze periods would have moved the change to a lower-impact time. Allow listing, application restarts, and version control do not address scheduling.