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

Objective 1.3 in this course covers change management — CompTIA's scope note for it explains business processes, technical implications, documentation and version control. It is an entire objective out of twenty-eight, 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. CompTIA put change management 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. The technical implications list — allow and deny lists, restricted activities, downtime, service and application restart, legacy applications, dependencies — is a list of things that break, and several Domain 4 scenarios are really change management questions wearing an operations costume.

The lesson

Approval, ownership, stakeholders and the change advisory board

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.
• 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 the commonest exam scenario: the change worked and broke something nobody had asked.
• Approval is the recorded decision, and it is what separates an authorised change from an incident.
• The change advisory board (CAB) is the group that reviews non-routine changes: representatives from operations, security, the business and sometimes the vendor. Its job is to weigh the risk of making the change against the risk of not making it.

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

Impact analysis, test results, backout plan and maintenance window

Four artefacts turn a proposal into an approvable change.

• 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.
• 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.
• Backout plan — the steps to return to the previous state, written before you start and specific enough to follow at 3am by someone tired. An unrehearsed backout plan is a wish. If the change is irreversible, the plan must say so explicitly, because that changes the approval decision.
• Maintenance window — the agreed period during which the change may be made, chosen so the disruption lands where it costs least.

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.

Standard operating procedures, and what makes a change 'standard'

A standard change is one that is pre-approved: low risk, well understood, performed often, with a documented procedure and a known outcome. Adding a user to a group that a manager has approved. Applying the monthly patch set that has already been through test. Replacing a failed disk in a redundant array.

What makes it standard is not that it is small — it is that the risk decision has already been made and written down, so it does not need making again each time. The standard operating procedure is that written decision plus the steps.

Two consequences the exam tests. A change that has been classified as standard but whose circumstances have changed — a new dependency, a different environment — is no longer standard and goes back through the full process. And a standard change is still logged; pre-approved does not mean invisible.

Technical implications: allow and deny lists, restricted activities, downtime, dependencies

This is CompTIA's own list of what goes wrong, and it is worth knowing as a checklist.

• 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 egress firewall was not part of the plan.
• Restricted activities. Some things may only be done by certain roles, in certain windows, or not at all without additional 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.
• Service restart and application restart. The change itself may be instantaneous 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 the single most common real-world blocker to a security-driven change, and the compensating-control conversation from lesson 1 starts here.
• Dependencies. What else relies on this, in both directions. Certificate expiry, hard-coded addresses, and scheduled jobs that nobody owns are the classics.

Version control and documentation as the evidence an auditor actually reads

Version control means the configuration, the infrastructure-as-code templates, the firewall rule sets and the 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 diff the current state against the approved one to detect unauthorised change, and you can revert precisely rather than from memory.

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

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, 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.
• The four artefacts: impact analysis, test results, backout plan, maintenance window. Match the failure in the scenario to the missing one.
• "Standard change" means the risk decision is pre-made and written down, not that the change is trivial.
• Legacy applications and dependencies are the named reasons a security change gets blocked, and they lead to compensating controls.
• Version control's security value is provable state, drift detection and clean reversion.