Approval, Backout, Maintenance Window: Why Security+ Calls Change Management a Security Control
Chris Rees
25+ years in IT · Pluralsight author, 4.6/5 across 2,000+ ratings
The firewall rule added "just for a minute" that stayed for a year. The patch pushed on a Tuesday afternoon that took the payment gateway down. The network diagram nobody updated, so responders isolated the wrong segment. None of these were attacks, and all of them were security failures. Objective 1.3 exists because most of the damage an organization does to its own security posture arrives through unmanaged change, and the exam tests it in one recognizable shape: a stem describes a change that went wrong and asks which step was skipped. Learn the steps as a chain and the questions answer themselves.
Why a business process is on a security exam
Change management is the structured process for proposing, evaluating, approving, testing, implementing and documenting changes to systems. Operations teams run it to protect uptime. Security+ lists it in Domain 1 for three reasons the guide states directly.
It prevents unauthorized change. When every legitimate change passes through a request, an approval and a record, a change that did not is visible by its absence: an attacker's new firewall rule or scheduled task stands out because no ticket matches it. It forces risk evaluation before the change lands, through impact analysis and testing, rather than in production. And it guarantees a path back, through a backout plan written before the work starts.
In the vocabulary of the control matrix, change management is a managerial control: preventive of unauthorized change, directive in that it tells people how work must be done, and detective after the fact through its records. That classification is a fair exam question on its own.
The business process, as a chain
The outline lists eight business-process elements. Hold them as a sequence, because the exam's questions are about order and about what happens when one link is missing.
| Element | What it is | The symptom when it is skipped |
|---|---|---|
| Approval process | formal review and sign-off, usually by a change advisory board | a change nobody authorized; an attacker's change that looked normal |
| Ownership | one named person or team accountable end to end | the change stalls, or fails and nobody notices |
| Stakeholders | everyone materially affected or who must be informed | users surprised mid-day; a dependent team broken without warning |
| Impact analysis | what could break: security, availability, dependencies, compliance | the "minor" change that caused the major outage |
| Test results | evidence from staging that it works and does not weaken security | a production failure a test would have caught |
| Backout plan | a rehearsed procedure back to the last known-good state | a failed change with no way back |
| Maintenance window | a scheduled, communicated period, usually low usage | downtime at peak; a blast radius nobody limited |
| Standard operating procedure | step-by-step instructions so anyone qualified executes it the same way | a forgotten step; security done from memory |
The CAB approves on evidence, meaning the impact analysis and the test results, not on the requester's confidence. Approval before testing is a recognizable wrong answer.
Ownership versus stakeholders
Two elements are confused constantly. Ownership is accountability: the one person or team that drives the change through the process, verifies the result and answers for the outcome. Stakeholders are everyone the change touches: security, operations, the application owner, business units, sometimes customers. The owner is a stakeholder; most stakeholders are not owners. In a stem, "nobody was responsible for verifying the change" is ownership; "the finance team was not told the system would be offline" is stakeholders. Assigning an owner is a governance decision; consulting stakeholders is a communication step inside impact analysis.
Impact analysis has one subtlety the exam likes: it weighs both directions. The risk of applying a patch is an outage; the risk of not applying it is an exploited vulnerability. A team that declines a critical patch because "changes are risky" has done half an impact analysis.
The technical implications
Approving a change is a business act. Implementing it has technical consequences, and the outline names seven. Each is a question the impact analysis must have answered before the CAB voted.
Allow lists and deny lists are the pair worth a table of their own, because the exam tests the default behind each.
| Allow list | Deny list | |
|---|---|---|
| Default | deny: only what is listed may run or connect | allow: everything runs except what is listed |
| Posture | stronger, more restrictive | weaker, easier to operate |
| Change implication | the new application must be added before go-live or it fails on day one | a new threat is not blocked until someone identifies and lists it |
| Failure mode | false positives: legitimate things blocked | false negatives: unknown bad things allowed |
An application that "fails immediately after go-live" on a system with application control is an allow list that was not updated. Malware that "ran despite the blocklist" is the inherent weakness of a deny list.
Restricted activities define what the implementer may not touch during the change: security tooling, production databases, logging. Work outside that scope is itself unauthorized change, even inside an approved window. Downtime is an availability impact that must be scheduled, minimized and communicated, and it carries a security cost when the services going down are monitoring or authentication, because exposure rises until they return. Service restart and application restart share a principle the exam turns into a question: a change is not effective until the component reloads. A patched binary on disk with the old process still in memory is still vulnerable; application restarts add session loss and data in flight.
Legacy applications and dependencies: why simple changes are not
Legacy applications are the reason a change can be risky or impossible: no vendor support, undocumented behavior, incompatibility with a modern operating system, protocol or patch. When the change cannot be made, the answer is a compensating control, isolation, extra monitoring, a stricter allow list, rather than forcing the change or ignoring the risk. The word "cannot" in a change stem points to compensating, just as it does in objective 1.1.
Dependencies are what impact analysis mostly exists to find. Systems rely on databases, APIs, libraries, certificate chains and authentication services, and a change to one ripples into the others. Dependencies also dictate order: the database schema before the application that reads it, the certificate before the service that presents it. The unmapped dependency is the classic origin of "we only changed one thing." When a change to one system breaks a different system, dependencies is the technical implication and impact analysis is the skipped step.
Documentation and version control: the change is not finished when it works
A change is finished when the records match reality. The outline names three duties. Updating diagrams: network topology, data flows and architecture diagrams must reflect the new state, because incident responders and auditors act on them as if they were true. Updating policies and procedures: if the change alters how work is done, the SOPs and runbooks that describe the work change with it. Version control: every revision of configuration, code and documents is tracked, attributed and reversible.
Version control deserves the security framing the exam gives it. It provides integrity and accountability for the changes themselves: who changed what, when, and the ability to return to any prior version, which is a built-in backout capability. During an incident, comparing the running configuration against the version-controlled baseline is one of the fastest ways to find an attacker's unauthorized change, which ties this objective to the incident response lifecycle. Stale documentation, by contrast, causes misdiagnosed incidents, misconfigured controls and failed audits; responders working from a wrong diagram is a documentation failure, not a responder failure.
Four stems, decoded
- A firewall rule is added during an incident to block an address and is still present a year later; nobody can say who added it. Ownership and approval both missing, and the rule bypassed the process. The security concern is that an attacker's rule would look identical.
- A patch is applied to a web server during business hours and the site is down for forty minutes. Maintenance window, and probably test results. Downtime is the technical implication; scheduling is the process step.
- A new payroll application is deployed and every user receives an execution-blocked error on launch. Allow list not updated. Application control is working as designed; the change plan omitted the list change.
- After a database upgrade, an unrelated reporting system stops working and the team has no rollback. Dependencies missed in impact analysis, and no backout plan. Two skipped steps; the exam will ask about whichever the stem emphasizes.
Key takeaways
- Three security purposes. No unauthorized change, risk evaluated before deployment, and a guaranteed path back. That is why a business process lives in Domain 1.
- The chain: request, impact analysis, approval, test, window, implement per SOP, verify, back out if needed, document. The stem describes a failure; find the missing link.
- The owner answers; stakeholders are affected. The CAB approves on evidence, meaning impact analysis and test results, never on confidence.
- Allow list is default deny and stronger; deny list is default allow. A patch is not a fix until the service restarts and the new version is verified running.
- Legacy means compensating control, dependencies mean impact analysis, version control means integrity, accountability and rollback. The change is done when the records match reality.
Change management is objective 1.3 of Security+ Domain 1, General Security Concepts, 12% of the exam, and it returns in the patching questions of Domain 4 and the policy questions of Domain 5. Work all 22 Domain 1 topics, from the control matrix and the CIA triad through every cryptographic solution on the exam, with our free Security+ Domain 1 study guide.
#SecurityPlus #SY0701 #ChangeManagement #BackoutPlan #ImpactAnalysis #VersionControl #ExamPrep #CompTIA #InfoSec #CyberSecurity
Build the foundation first
Zero Trust is one of 22 topics in Security+ Domain 1, the foundation the rest of the exam builds on. Master all 4 objectives, from control categories through cryptography, with our objective-mapped guide and 60 practice questions.
Get the Domain 1 guideKeep reading
MSA, SOW, SLA, BPA, NDA: The Third-Party Risk Alphabet, and Which Document Answers Which Question
Your vendors are your attack surface, and Security+ Domain 5 tests whether you know the paperwork that manages them. Objective 5.3 end to end: the vendor lifecycle from due diligence to offboarding, the agreement stack (master agreement, statements of work, service levels, business partners, non-disclosure, memoranda), right-to-audit and rules of engagement, questionnaires and ongoing monitoring, and supply chain analysis.
Read Security+ deep divesEstablish, Deploy, Maintain: Secure Baselines, Hardening Targets, BYOD vs. COPE vs. CYOD, and WPA3 on Security+
Objective 4.1 is the widest bullet in the biggest domain, and it hides its questions in verbs and ownership: which baseline step failed when settings drifted, which mobile model gives the least control, why WPA3 ends the offline handshake attack, which application control stops which flaw. The baseline lifecycle, hardening emphasis by device class, site surveys and heat maps, MDM and deployment models, 802.1X with RADIUS, and the application security checklist, decoded the way the exam asks them.
Read Security+ deep divesSPF, DKIM, DMARC, and Friends: The Enterprise Security Capabilities Security+ Expects You to Configure
Objective 4.5 is where Security+ stops asking what a control is and starts asking where it goes. Email authentication drawn as one flow (SPF checks the sender, DKIM signs the message, DMARC decides what happens), web and DNS filtering, DLP and what it can actually see, EDR versus XDR, NAC posture checks, file integrity monitoring, and the placement map that answers every scenario in the objective.
ReadFollow Skillthropic
Keep learning between study sessions
The same exam-focused teaching, in smaller pieces, wherever you scroll.
Enjoyed this? Get the AI security news that matters.
Join The AI Security Brief for the top AI security news, plus what's important to the C-suite. Free, straight to your inbox.
No spam. Unsubscribe anytime.