Change Management and Its Security Impact
Explain the importance of change management processes and the impact to security
What you will learn
- Explain why change management is a security topic and not merely an administrative one.
- Put the steps of an approved change in order and know where each document belongs.
- Tell an owner from a stakeholder, and a standard change from an emergency one.
- Identify the technical implications to expect before implementing: dependencies, legacy systems, restarts and downtime.
This objective can look administrative; it is thoroughly a security one. Most outages and vulnerabilities come not from an attacker but from a change made without weighing its effect: a firewall rule opened "temporarily" and forgotten, an update that broke a dependency nobody had mapped, a setting altered with no record of who altered it or how to put it back. Change management is what prevents that — and the exam question is usually about which step was skipped.
An approved change, step by step
Request the change and name its owner
The owner is one person accountable for the change from request to closure, not a committee.
Impact analysis
What does this touch? Dependencies, connected services, affected users — and what happens if it fails.
Approval
An authorised body reviews and approves before implementation. Approval is what separates a legitimate change from tampering.
Test, and record the results
In a non-production environment. Test results are part of the change record, not a verbal step.
Backout plan
How do we get back to before, if this goes wrong? Written before implementation, not during.
Implement inside the maintenance window
A time chosen so disruption is least — usually outside working hours.
Update the documentation
Diagrams, policies and procedures. The most neglected step, and its cost shows up in the next incident.
Process terms
| Ownership | Who owns the change and answers for it. One named person. |
|---|---|
| Stakeholders | Those affected by it: owners of connected systems, users, support. They are consulted; they do not own it. |
| Impact analysis | Working out what the change touches and what breaks if it fails, before approving it. |
| Backout plan | The steps back to the previous state. It may be removing a patch or restoring a full backup. |
| Maintenance window | The agreed period for implementation, chosen to minimise disruption. |
| SOP | Standard operating procedure: the written, approved way to perform a recurring task, so it does not depend on who performs it. |
Real-world example: a rule opened without approval
An engineer chasing a slowness complaint opens a port on the firewall to test a theory. The test works, they get pulled elsewhere, and the rule stays. No request, no approval, no record. Two months later, unauthorised access is found through that port. The failure is not technical: the change was reasonable as a diagnostic step, but with no request there was no impact analysis, with no documentation the later review could not see it, and with no backout plan "temporary" came to mean "permanent". Three missing steps, one vulnerability.
Standard vs emergency change
| Standard | Emergency | |
|---|---|---|
| Approval | Before implementation | Expedited or retrospective — but never skipped |
| Timing | In a scheduled maintenance window | Immediately, because waiting is the greater risk |
| Documentation | During the process | Straight afterwards — and this is what usually gets forgotten |
The owner is not a stakeholder
The question lists several parties affected by a change, then asks who approves it or who answers for it. Stakeholders are consulted; the owner is one person and is accountable. Read the verb: "informed" and "consulted" point to stakeholders, "accountable" and "decides" point to the owner or the approving body.
Technical implications to expect
| Dependencies | What relies on the thing you are changing. The commonest reason a change that "passed" testing still fails. |
|---|---|
| Legacy applications | Old systems that may break on update and cannot be patched. They usually need a compensating control instead of the update. |
| Allow / deny lists | Lists of what is permitted and what is blocked. Changing them widens or narrows the attack surface directly. |
| Restricted activities | Work the change blocks or limits, temporarily, while it is applied. |
| Service / application restart | Many changes do not take effect until a restart — which is itself an outage to be planned for. |
| Downtime | The expected outage. Estimated and announced before implementation, not after. |
Two parts are still routinely skipped: updating documentation, and version control. A diagram left un-updated is not merely an old document — it is the source of a wrong decision in the next incident, when a responder relies on a network that no longer exists. Version control keeps the history of every edit to configuration and scripts, answering the three questions that come up in every investigation: what changed, when, and who changed it — and it turns a rollback into one command instead of a rebuild.
Four questions before any change
What will it touch (impact analysis), who approved it (approval), how do we get back (backout plan), and where is it written down (documentation)? Whichever has no answer is the step the exam will ask about.
What matters on the exam
- The question describes a change that went wrong and asks for the missing step. Look for what is not mentioned: no approval? no testing? no backout plan?
- "How do we revert" = backout plan. "When do we do it" = maintenance window. "What will break" = impact analysis.
- An emergency change shortens approval; it does not remove it, and it does not remove documentation. Any option saying "no approval at all" is wrong.
- A legacy system that cannot be updated is handled with a compensating control — a direct link back to objective 1.1.
Quick check
Answer in your head first, then reveal.
An update is applied at peak hours and takes the service down for hundreds of users. Which step was skipped?Reveal the answer
The maintenance window: a time that minimises disruption should have been chosen. Possibly impact analysis too, since neither the number of affected users nor the outage length was estimated.
What separates the owner of a change from its stakeholders?Reveal the answer
The owner is one person accountable for the change from request to closure. Stakeholders are those affected by it — consulted and informed, but not accountable.
Why is failing to update diagrams a security problem and not an administrative one?Reveal the answer
Because an incident responder makes decisions from them. A diagram describing a network that no longer exists points containment at the wrong place, lengthening the incident instead of ending it.
An urgent security update for a vulnerability being exploited right now. Is it applied without approval?Reveal the answer
No. It is handled as an emergency change: expedited or retrospective approval, and documentation immediately afterwards. Shortening the path is not removing it — otherwise we lose the ability to know what changed and who changed it.
Sign in to track your progress on this topic.
Your next step
Read the lesson, then mark it complete
Sources
Used to verify the facts. The writing is original to Passuit.