Change management, which is a security control and is examined as one

Objective 1.2 is about change management, and its verb is scenario-based: you are shown a change and asked what the process should have caught, or what a step does to security. It covers the business process around a change, the technical side effects a change can have, the documentation that must follow it, and version control. It is a whole objective in the domain that opens the exam, which is a strong hint about how seriously it is taken.

Why this matters

Candidates skim this objective because it sounds like project administration. It is not. Change management sits in General Security Concepts, beside CIA and zero trust, because unmanaged change is one of the largest sources of security incidents there is -- and because the exam wants you to recognise that the correct answer to a scenario is often "follow the process", not "make the technical fix faster".

There is a second, more testable reason. Many technical side effects of a change are things that break, and several Domain 4 scenarios are really change management questions in an operations costume.

V8 adds one idea to this objective: failing forward, the option of fixing a failed change in place rather than undoing it.

The lesson

The change advisory board, ownership, stakeholders and what 'approved' has to mean

The process exists so that a change is somebody's decision rather than somebody's afternoon.

• The owner is the person accountable for the system being changed. They do not have to do the work; they have to be the one who says it may happen, and the one who answers for it afterwards.
• Stakeholders are everyone the change affects -- the application team whose service restarts, the helpdesk who will take the calls, the business unit whose reporting run is at 2am, the third party whose integration uses the endpoint you are about to move. The commonest failure in real organisations is an incomplete stakeholder list, and it is also a common exam scenario: the change worked and broke something nobody had asked about.
• The change advisory board (CAB) is the group that reviews changes that are not routine: representatives from operations, security, the business and sometimes the vendor. It weighs the risk of making the change against the risk of not making it.

Approval is the recorded decision, and it is what separates an authorised change from an incident. For it to mean anything, three things must be true: the people approving had the impact analysis, test evidence and backout plan in front of them; the approval names exactly what was approved, so a different change cannot ride in under it; and it is recorded somewhere that can be shown later.

Not every change needs the CAB. A standard change is pre-approved because it is low risk, performed often and has a known outcome -- applying the monthly patch set that has already been through test, adding a user to a group a manager approved. The standard operating procedure (SOP) is the written version of that pre-made decision plus the steps. Pre-approved does not mean invisible: standard changes are still logged, and one whose circumstances have changed goes back through the full process.

Note the asymmetry the exam likes: an emergency change may proceed before the CAB meets, but it is still documented and still reviewed afterwards. Skipping the record is never the correct answer.

Impact analysis, test results, maintenance windows and the backout plan written first

Four artefacts turn a proposal into something the CAB can approve.

• Impact analysis -- what this touches, what depends on it, what the blast radius is if it goes wrong, and what the security consequence is either way. A firewall change that opens a port is a functional change and also a change in attack surface.
• Test results -- evidence that it worked somewhere that was not production. "It worked on my machine" is not test results; a record from a staging environment that resembles production is.
• Maintenance window -- the agreed period during which the change may be made, chosen so any disruption lands where it costs least.
• Backout plan -- the steps to return to the previous state, written before you start and specific enough to follow at 3am by someone tired. It says what will trigger it, who decides, and how long it takes. An unrehearsed backout plan is a wish. If the change cannot be reversed, the plan must say so plainly, because that changes the approval decision.

On the exam, a scenario where a change went wrong and could not be undone is almost always testing the backout plan, and a scenario where the change went fine but at the wrong time is testing the maintenance window.

Failing forward: when fixing in place beats rolling back, and the risk it carries

Failing forward means that when a change goes wrong, you correct it with a further change rather than reversing it. Instead of restoring the old version, you apply a fix to the new one and carry on.

There are honest reasons to choose it:

• Rolling back is impossible or worse. A database schema migration has already transformed live data, a certificate authority has already revoked the old certificate, or a security patch closes a vulnerability that is being actively exploited -- going back would reopen it.
• The fault is small and understood. A single missing firewall entry or one wrong configuration value is quicker and safer to correct than undoing a large, otherwise successful change.
• Modern delivery makes it cheap. Teams that deploy small changes through an automated pipeline can often ship a tested fix faster than they could restore the previous state.

The risks are what make it a security topic. A fix written under pressure is a new, untested change applied to a system already in an unexpected state. Each further attempt can compound the problem, and the original approval did not cover any of it. Done badly, failing forward is just an unauthorised change with a good excuse.

So it belongs in the plan, not in the moment. A good change record says in advance which way the team will go if it fails, and sets a decision point -- if the fix is not working by a given time, back out. Any forward fix still goes through emergency change approval and is documented. On the exam, failing forward is a reasonable answer when the scenario makes rollback unsafe or impossible; it is the wrong answer when it is simply being used to avoid the process.

Technical implications: allow and deny lists, restarts, downtime, legacy applications and dependencies

These are the ways a change reaches beyond the thing being changed, and they make a useful checklist for impact analysis.

• Allow lists and deny lists. New software often needs a new entry, and the change that installs it fails silently if application allow-listing or an outbound firewall rule was not part of the plan. The reverse matters too: a change that loosens a list to make something work has changed the attack surface.
• Restricted activities. Some actions may only be done by certain roles, in certain windows, or not at all without extra authorisation. A change request that quietly includes one of those is not approvable as written.
• Downtime. Whether there is any, how long, and who has agreed to it. An unplanned outage of a security service -- logging, EDR, the VPN -- is a security gap for its duration.
• Service and application restarts. The change itself may be instant while the restart it requires is not, and the restart is where the outage actually lives.
• Legacy applications. The thing that breaks when you disable an old protocol, raise a TLS minimum, or tighten a cipher suite. This is one of the most common real-world blockers to a security-driven change, and it is where the compensating-control conversation from lesson 1 starts.
• Dependencies. What else relies on this, in both directions. Expiring certificates, hard-coded addresses and scheduled jobs that nobody owns are the classics.

Updated diagrams and procedures, and version control, as the evidence an auditor actually reads

Documentation here means updating the network and data-flow diagrams and the policies and procedures as part of the change, not afterwards. A diagram that is eighteen months stale is worse than no diagram, because incident responders trust it.

Version control means configuration files, infrastructure-as-code templates, firewall rule sets, scripts and policy documents live somewhere that records who changed what, when and why. Its security value is threefold: you can prove what the state was at any past date; you can compare the running state against the approved one to detect unauthorised change; and you can revert precisely rather than from memory -- which is also what makes a backout plan dependable.

The auditing point is the one to carry into Domain 5: when an auditor asks whether you have change management, they are not asking whether you have a process. They are asking for the records -- approvals, test evidence, backout plans, updated diagrams, and a version history that matches the running configuration. A perfect process with no evidence fails the audit.

What to take into the exam

• When a scenario offers a fast technical fix and a slower documented one, the documented one is usually correct -- including for emergency changes, which are documented after.
• Match the failure to the missing artefact: impact analysis, test results, maintenance window or backout plan.
• A standard change is one whose risk decision is pre-made and written into an SOP, not one that is merely small.
• Failing forward is legitimate when rollback is unsafe or impossible, planned in advance, and still approved; otherwise it is an unmanaged change.
• Legacy applications and dependencies are the usual reasons a security change gets blocked, and they lead to compensating controls.
• Version control gives provable state, drift detection and clean reversion.