Explain the importance of change management processes and the impact to security
Approval chains, maintenance windows, backout plans, and why undocumented change is a security problem.
- Reading time
- 16 min read
- Flashcards
- 20 cards
- Practice questions
- 10 questions · 3 PBQs
This objective looks like paperwork, and people skip it. Then they lose easy marks, because it is only 4 to 6 questions of pure recall and the terms are unambiguous.
The security argument is simple: most outages are self-inflicted. Somebody changed something. Change management is how an organisation stops an unrecorded change from becoming an incident nobody can explain — and how it can tell "we were attacked" apart from "Dave pushed a firewall rule at 4pm on Friday".
The business processes
Approval process
Who must sign off before a change proceeds. Prevents unilateral changes and creates accountability.
Ownership
The person accountable for the change end to end. Not necessarily the person doing the work — the person answerable for it.
Stakeholders
Everyone affected by the change. Identifying them is what stops "nobody told us the API was changing" outages.
Impact analysis
What breaks if this goes wrong, and what else depends on the thing being changed.
Test results
Evidence the change works in a non-production environment before it reaches production.
Backout plan
How to undo the change if it fails. Required before the change starts, not improvised during the outage.
Maintenance window
The agreed period when the change may be made — typically when impact on users is lowest.
Standard operating procedure (SOP)
The documented, repeatable way a routine change is performed.
Check yourself
A team deploys a firewall change that breaks production access. They spend four hours working out how to restore the previous configuration. Which change management element was missing?
The CAB
A Change Advisory Board is the group that reviews and approves changes. It exists so that risk decisions are made by people who can see across the whole environment rather than by the one engineer who wants the change.
Emergency changes are the exception: they follow an expedited path and get reviewed after the fact, because waiting for the next CAB meeting during an active incident would cause more harm than the process prevents.
Technical implications
This is the sub-list people skip, and it appears more than expected.
Allow lists / deny lists
- A change may require updating what is permitted
- Forgetting this is why 'it works in test' fails in production
Restricted activities
- Some changes are out of scope for a given window or role
- Prevents scope creep mid-change
Downtime
- Planned unavailability during the change
- Drives the choice of maintenance window
The tellThese are the practical consequences of a change that the plan must account for in advance, not surprises to handle live.
Three more that carry their own risk:
Service restart / application restart. Some changes only take effect after a restart, and the restart itself is a moment of unavailability. The exam wants you to recognise that "the change is applied" and "the change is in effect" are not the same instant.
Legacy applications. Old systems that cannot be changed safely, or at all. They are the standing reason compensating controls exist (see 1.1).
Dependencies. Changing one component affects others that rely on it. Unmapped dependencies are the most common cause of a change causing damage far from where it was made.
Check yourself
An administrator updates a shared authentication library. Several unrelated applications stop working. Which technical implication was not accounted for?
Documentation and version control
Two closing items, both easy marks.
Updating diagrams and policies. A network diagram that no longer matches reality is worse than none, because responders trust it during an incident and act on stale information. Every change that alters architecture updates the documentation.
Version control. Tracking changes over time so you can see what changed, when, and by whom — and roll back to a known-good state. Note the overlap with non-repudiation from 1.2: version history attributes changes to people.