3.3 Support and Implement the Change Management Lifecycle

Support and Implement the Change Management Lifecycle

SSCP Knowledge Area 1.6 asks you to support and/or implement the change management lifecycle. In operations, an untracked change is one of the most common ways preventative controls silently die: someone opens a firewall port "for the weekend," a sysadmin disables a SIEM forwarder to quiet an alert, or a vendor tunes a cipher suite at 03:00. Domain 3 later treats unauthorized change as an event of interest. Domain 1 is where you learn the process that should have produced an authorized one.

Change management is the process that reviews, approves, communicates, implements, and audits modifications. Configuration management (CM) is the state: known-good baselines for configuration items (CIs). You need both. A perfect asset register with no change process still drifts. A busy change advisory board (CAB) with no baseline cannot tell authorized work from tampering.

Roles, Responsibilities, Processes, Communications, and Audit

Write roles down before the 02:00 outage, not during it.

The process is predictable: request, classify, analyze impact (including SIA), approve or reject, schedule and communicate, implement with a backout plan, verify, close, and audit. If your organization uses an Information Technology Infrastructure Library (ITIL)-style tool, the SSCP still cares about the same bones — the exam will not require a specific vendor workflow.

Communications are a control. A silent firewall change that blocks a hospital interface is an availability incident even if the packet-filter logic is "more secure." Notify stakeholders, record the window, and say how to escalate if the change fails.

Audit closes the loop: sample emergency changes, look for implementers who approve their own work, and compare the configuration baseline to reality. Segregation of duties still applies — the person who codes the firewall rule should not be the only person who marks the RFC approved.

Standard, Normal, and Emergency Changes

Classify by risk and predictability, not by how impatient the requester is.

Standard does not mean "small enough that we skip the ticket." It means the organization already assessed that this procedure is low risk and pre-authorized. Weekend vendor Remote Desktop from the internet is not a standard change just because it is temporary.

Emergency is not a free pass. The database administrator who applies an unlisted hotfix at 02:10 to restore service is in the emergency path: expedited authorization (even a recorded bridge approval), a backout idea, and an RFC filed when the smoke clears so SIA and audit can catch up. "We will mention it on Monday" is unauthorized change.

Normal is the default for anything that alters exposure, authentication, logging, or a production baseline.

Security Impact Analysis

Security impact analysis is the SSCP-specific heart of this knowledge area. For each proposed change, ask:

• Does it weaken confidentiality, integrity, or availability?
• Does it add or remove authentication, multi-factor authentication (MFA), encryption, or logging?
• Does it change network exposure (new port, new peer, public object storage, flattened segment)?
• Does it affect a regulated data set (protected health information, personally identifiable information, payment data)?
• Are compensating controls needed if a preventative control will be temporarily removed?
• What is the backout, and does backout itself have security impact?

Scenario. A product manager pings the sysadmin: "Open TCP 3389 from the internet to the jump host just for this weekend so a vendor can debug." SIA says you are exposing Remote Desktop to the world, punching a hole in a preventative firewall control, and creating an audit gap if the rule is forgotten. The SSCP's answer is an RFC (normal, or emergency only if production is already failing), compensating controls if the business insists (time-bound rule, virtual private network (VPN) instead of raw 3389, MFA, session recording, automatic expiry), and a backout that deletes the rule. Chat messages are not CAB approval.

SIA is required even when the change "only" updates a library. Dependency changes can introduce known exploited vulnerabilities or license conflict — that is why asset inventory and change management meet.

Configuration Management

CM identifies configuration items, records their attributes, and protects a baseline — the known-good state. Baselines include operating-system gold images, infrastructure as code, firewall policy revisions, and container manifests. Tools vary; the idea does not. Infrastructure as code (IaC) is simply a machine-readable baseline you can review in the same RFC as any other change.

When a change is approved and implemented, update the baseline. If you do not, the next drift report will flag a legitimate change as rogue, or worse, a rogue change will look legitimate.

Unauthorized change — production differs from baseline with no RFC — is an event of interest. Treat it like an anomaly in Domain 3: investigate, determine whether it was malicious, sloppy, or an undocumented emergency, and either roll back or ratify through the process.

Scenario. Security operations center (SOC) analysts see a production web server's TLS cipher suite change at 03:14 with no matching RFC. The baseline still lists the old suite. That is not nightly maintenance. It is unauthorized change. Pull change tickets, admin logs, and who had privileged access. If it was a vendor "optimization," it still needed a change record. If it was an attacker disabling strong ciphers, you are in incident response.

Putting the Lifecycle Together

A healthy operations team can answer four questions for any production delta: Who requested it? Who approved it after SIA? What baseline did it move from and to? Who verified it and told the users? If any answer is "we are not sure," the change-management lifecycle is not implemented — it is a slide in a policy deck.

SSCPs rarely chair the CAB, but they are the people who notice that a "standard" catalog item now includes a new internet port, that an emergency change from last week never received a post-implementation SIA, or that configuration drift on a jump host matches no ticket. That is Domain 1 work, and it is how preventative controls stay preventative after the change window closes.