Change Management: Documentation, Approval, and Rollback

Why Change Management Is a Security Control

Change management is the discipline of controlling modifications to systems, applications, infrastructure, and procedures. It is not paperwork for its own sake. It reduces the chance that a well-intended change causes an outage, weakens security, breaks compliance, or leaves no record for troubleshooting. Many security operations incidents begin with a change — a firewall rule, a permission grant, a software update, a cloud storage setting, a network route, or a server configuration.

In the CC Domain 5 context, change management connects to the CIA triad: an uncontrolled change can break availability (outage), harm integrity (bad config), or expose confidentiality (an over-broad access rule). The exam rewards the controlled path over the heroic ad-hoc fix made directly in production.

What a Change Request Should Contain

A practical change request documents the following, scaled to the risk:

Documentation matters before, during, and after. Before, it lets reviewers gauge impact; during, it gives the implementer a checklist; after, it creates a record for responders. If a customer portal fails at 9:15 p.m. and the change log shows a database connection string was updated at 9:00 p.m., responders have an immediate lead — that traceability is the security payoff.

Approval, the CAB, and Separation of Duties

Approval means an authorized person or group reviews the change and accepts the risk. In many organizations a Change Advisory Board (CAB) reviews normal production changes; security-sensitive changes add a security review, and financially important systems require business-owner sign-off.

Changes generally fall into three types:

• Standard change — low-risk, pre-approved, repeatable (for example, a routine password-rotation script).
• Normal change — reviewed and approved through the CAB before implementation.
• Emergency change — needed when delay creates greater risk, such as patching an actively exploited vulnerability or restoring a failed service.

Separation of duties ensures one person cannot propose, approve, implement, and conceal a risky change without oversight. Emergency changes still require authorization appropriate to the situation, careful notes, communication, and retrospective documentation and review once the immediate problem is controlled — skipping the after-action review is a wrong answer.

Testing, Rollback, and a Worked Scenario

Testing verifies the change works and avoids obvious harm. Ideally changes are validated in a nonproduction environment first. For a firewall change, testing confirms the desired connection works and that no broader access was opened than intended.

Rollback is the planned return to a known-good state if the change fails. A strong rollback plan specifies who decides to roll back, what condition triggers it, which steps restore service (revert config, roll back a release, disable a new rule, restore from backup, or shift traffic to a prior environment), and how success is verified. A weak request just says "we will fix it if there is a problem."

Scenario: An administrator is asked to open Remote Desktop Protocol (RDP) from the internet so a vendor can troubleshoot quickly. The poor response is to add the rule now and document it later. The better response is to use an approved remote-access method, or submit an urgent change with a defined source address, a time limit, business-owner approval, monitoring, and a rollback step that removes the rule afterward. If the risk is unacceptable, the right answer may be to deny the shortcut and offer a safer path.

Configuration Management and the Audit Trail

Change management is closely tied to configuration management — knowing the approved, documented state of every system. A configuration baseline records the expected settings; configuration drift is the gap that opens when undocumented changes accumulate. Unauthorized changes that bypass the process create drift, which is why responders compare a failing system against its baseline. The change record plus the configuration baseline together answer the two incident-response questions: what changed, and what was it before?

The lifecycle of a controlled change follows a predictable order, and CC questions often reward picking the correct sequence:

1. Request the change with a documented business reason.
2. Assess risk and impact.
3. Approve through the CAB or appropriate authority.
4. Test in a nonproduction environment where practical.
5. Communicate to affected users and schedule a window.
6. Implement during the approved window.
7. Verify results and monitor.
8. Close the record, retaining the rollback option until stability is confirmed.

Skipping straight from request to implementation — the "just make the fix" answer — is what change management exists to prevent. A related distractor: patch management is a specialized form of change management, so even a routine security patch flows through the same request, test, approve, and rollback discipline rather than being applied silently to production.