RANGER CompTIA Security+ (SY0-701) · chapter 4 of 27
Week 2: The change board
In this chapter Objectives 1.3
Objective 1.3
Business processes that shape a change
Why change management is security
Change management is the formal process for proposing, reviewing, approving, testing, scheduling and documenting changes to systems. Without it, changes cause outages (availability), weaken configurations (a firewall rule opened "for a minute" and forgotten) and leave no record for investigators. Most organizations run changes through a change advisory board (CAB).
Exam tip Exam angle: unauthorized or untested changes are both a security risk and an audit finding.
Approval, ownership, stakeholders
The approval process sends a change request through review (often the CAB) before any work starts; emergency changes get a faster path, not no path. The owner is the person or team accountable for the change and its result, usually the one asking for it; they may not do the technical work. Stakeholders are everyone affected (other departments, customers, management), so they are consulted and told about timing.
Exam tip Trap: the owner manages and is accountable for the change; the technician who types the commands may be someone else.
Impact analysis and test results
Impact analysis asks what this change could break, how risky it is (often rated high, medium or low), and what the risk is of NOT making it. Test results come from trying the change first in a sandbox or test environment that mirrors production, so problems show up there, not in front of customers.
Exam tip Impact analysis happens before approval. "Risk of not doing it" counts too: skipping a critical patch has its own impact.
Backout plan, maintenance window, SOP
A backout plan is the tested way to undo the change and return to the last good state if it fails, for example restoring a snapshot or the previous config. A maintenance window is the agreed time when changes may be made with the least business impact (for a pet shop, maybe Tuesday 2 a.m.). A standard operating procedure (SOP) documents the step-by-step way routine changes are done, so they are done the same safe way every time.
Exam tip If the question says "the change failed; how do we recover quickly?", the answer is the backout plan, not a new change.
Check yourself 1A firmware update for the core switch is approved, but the team wants to be able to return to the previous version within 15 minutes if it fails. Which part of the change request covers this?
- Impact analysis
- Maintenance window
- Backout plan
- Standard operating procedure
Show the answer
Answer: C. Backout plan
A backout plan is the documented way to undo a change and restore the last good state. Impact analysis predicts what could go wrong but doesn't describe how to undo it.
Objective 1.3
Technical implications
Allow/deny lists and restricted activities
A change can collide with security controls. A new app version may be blocked by the allow list (or flagged by a deny list) until the list is updated, so update the lists as part of the change. Restricted activities means the change has a defined scope: the technician does only what was approved. If they find something else to fix, that is a new change request.
Exam tip Clue: "the tech also tweaked the firewall while he was in there" = violating the approved scope (restricted activities).
Downtime and restarts
Downtime is the time a service is unavailable during the change; plan it inside the maintenance window and tell stakeholders. Many changes need a service restart (for example restarting the web service so a new config loads) or an application restart. Restarts can fail or behave differently, so they are part of testing and the backout plan.
Exam tip Even a "quick restart" counts as downtime and needs to be scheduled.
Legacy applications and dependencies
Legacy applications are old systems that may not be supported, may lack documentation, and may break when anything around them changes, so treat changes near them carefully. Dependencies are things that rely on each other: updating a database server may require the app servers to be updated first, or a service may not start until another one is running. Map dependencies before you schedule.
Exam tip Trap: a change can be correct on its own and still cause an outage because of a dependency nobody mapped.
Objective 1.3
Documentation and version control
Update the paperwork
After a change, updating diagrams (network maps, data flows) and updating policies/procedures keeps documentation true. Stale diagrams mislead the next technician and slow incident response. If the change alters how something is done, the SOP must change too.
Exam tip The change isn't "done" until the documentation matches reality.
Version control
Version control tracks every version of code, configurations, scripts and documents: who changed what, when and why. It lets you compare versions and roll back to a known good one. Examples: a Git repository for firewall configs, numbered versions of Group Policy objects, versioned infrastructure-as-code templates.
$ git log --oneline fw-edge.conf 9f3c2a1 CR-1182 allow 443 to shop LB (priya) 41b7e0d CR-1170 remove old FTP rule (dev) 0ac91f2 baseline after audit (maya)
Exam tip Version control is how you answer "what changed?" in seconds during an outage.
Check yourself 2During an approved change to update the shop's web server, a technician notices an unrelated firewall rule he dislikes and deletes it. Which change management concept did he violate?
- Restricted activities
- Dependencies
- Service restart
- Legacy applications
Show the answer
Answer: A. Restricted activities
Approved changes have a defined scope, and work outside it is a restricted activity that needs its own request. Dependencies describe systems that rely on each other, not scope.
CompTIA, A+, Network+, Security+ and Linux+ are trademarks of CompTIA, Inc. Ranger Gamez is not affiliated with or endorsed by CompTIA. The practice questions are written to the published exam objectives; they are not real exam questions.