What is change management?
Change management is the set of business processes that controls how production systems change. Every change, whether a firewall rule, a patch, a new server or a software release, is requested, assessed, approved, scheduled, carried out, verified and recorded. The goal is that nothing reaches production without an owner, an approval and a way back.
It is a security process as much as an operations one. An untested change can take a service down, which is an availability failure. An unauthorized configuration edit is an integrity failure, and a rule that opens access to the wrong people is a confidentiality failure. Change records also help detection: when every legitimate change has a ticket, a change without one stands out as a possible intrusion.
The change process from request to closure
| Stage | What happens |
|---|---|
| Request | A request for change (RFC) states what, why, which systems and when |
| Assessment | Impact analysis, test results and a backout plan are attached, and the risk is rated |
| Approval | The change manager or the change advisory board (CAB) approves, defers or rejects |
| Scheduling | The change goes into a maintenance window and stakeholders are notified |
| Implementation | Implementers carry out the approved steps, and only those |
| Verification and closure | Someone confirms it worked, documentation is updated and the record is closed |
Many organizations use the three change types from ITIL. Standard changes are low risk and pre-approved, done by following a standard operating procedure. Normal changes are assessed and approved one by one. Emergency changes, such as patching an actively exploited VPN appliance, get expedited approval from a small emergency group and are fully documented afterward. Urgency shortens the approval; it never removes it.
Backout plans and failing forward
A backout plan is written before the change, not during the outage. It records what is captured first (a configuration export, a snapshot, a database backup), the trigger for backing out, the steps and how long they take, and who decides. A change that reaches approval without test results or a backout plan should be deferred. Failing forward is the alternative when going back is impossible or unsafe, for example when rolling back would reopen an exploited vulnerability or lose data; the fix is deployed as its own recorded change.
Technical implications to check
- Allow lists and deny lists may need updating so a new application isn't blocked and a retired one isn't left allowed.
- Restricted activities keep implementers inside the approved scope.
- Downtime, service restarts and application restarts have to fit the window and be announced.
- Legacy applications and dependencies often break first, including systems nobody listed in the request.
- Documentation, diagrams and version control must match the system afterward, so the next administrator and the next investigation work from accurate records.
Example: the rule nobody removed
On a Friday afternoon, an engineer opens TCP 3389 from any address to a file server so a vendor can troubleshoot a backup job. There is no change request, no owner and no expiry date. The vendor finishes in twenty minutes, the rule stays, and weeks later it is how a ransomware crew gets in. A change record with an owner, a source limited to the vendor's address and a removal date would have prevented both the exposure and the forgotten cleanup.
Change management on the CompTIA Security+ exam
Change management is SY0-801 objective 1.2, a scenario objective, so expect questions that place you partway through the process and ask what should happen FIRST or NEXT. Submit a change request before touching production. Use the emergency process, rather than skipping approval, for an urgent patch. Defer a request that has no backout plan. Notify stakeholders before the window. Treat a configuration change with no matching record as unauthorized and investigate it. Distractors include applying a fix immediately because it is urgent and having the CAB implement the change; the CAB approves changes but doesn't carry them out. Change management also appears in A+ Core 2 (220-1202) objective 4.2.