Security+ 801 Countdown, T-35: Change Management Becomes a Scenario Objective

Change management is the discipline that decides how a modification to a production system is requested, reviewed, approved, tested, carried out, and verified, and who is accountable at each step. It exists because change is the leading cause of self-inflicted outages: Google’s SRE book reports that “roughly 70% of outages are due to changes in a live system” (Treynor Sloss 2016). A firewall rule, a firmware upgrade, or a one-line configuration edit can take a service down as surely as an attacker can, and the security consequences of a bad change (an exposed port, a disabled control, a host that cannot boot) are why the topic lives in a security exam and not only in an operations manual.

SY0-801 objective 1.2, “Given a scenario, demonstrate the impact of change management processes on security,” expands the topic by naming the change advisory board (CAB) and fail forward beside the other business-process elements (CompTIA 2025). Those elements are ownership, stakeholders, the CAB with its approval process, impact analysis, test results, backout planning, fail forward, the maintenance window, and standard operating procedures (SOPs). Beside them sit seven technical implications (allow lists and deny lists, restricted activities, downtime, service restart, application restart, legacy applications, and dependencies), plus documentation and version control as their own items.

A scenario objective most likely means a broken-change story and a question about which process element was missing or which recovery path fits, so this post follows that shape: the roles, one change record, the backout decision, and one real incident.

Who approves, who owns, who gets told

A change advisory board (CAB) is the body that reviews a proposed change and approves or rejects it. On SY0-801 the approval process is nested under the CAB, so a question about approval points at a body, not at a signature line. NIST SP 800-53 CM-3 requires approval “with explicit consideration for security and privacy impact analyses,” names “Configuration Control Boards or Change Advisory Boards” as the reviewers, and CM-3(4) seats security representatives on the board (NIST 2020). The exam draws no line between a CAB and NIST’s configuration control board (CCB); treat them as the same seat at the table.

Around the board sit four other roles, two of them objective terms and two of them borrowed from NIST and from practice:

Role	Job in the change	Anchor
Requester	Raises the request (user, help desk, advisory, scan)	NIST “Change Initiator”; not an 801 term
Change owner	Accountable for the change and its outcome	801 “Ownership”
CAB or change authority	Reviews; approves or rejects	801 CAB; NIST CM-3
Stakeholders	Affected; consulted, then notified of downtime	801 “Stakeholders”
Implementer	Makes the change; never approves it	NIST AC-5, CM-5(4); not an 801 term

Ownership means one named person is accountable for the change and its outcome once the window opens. Stakeholders are the people and teams the change touches; they are consulted during impact analysis and then notified of the downtime, so nobody discovers a VPN gateway reboot by losing their tunnel.

Separation of duties

The implementer row is explained by separation of duties, a control the objective does not name but which the approval process depends on. NIST AC-5 says separation “helps to reduce the risk of malevolent activity without collusion,” and CM-5(4) dual authorization (“two-person control”) requires two qualified people (NIST 2020). An engineer approving their own firewall rule is an approval-process failure; separation of duties is the supporting control.

Standard, normal, and emergency changes

Not every change deserves a board meeting. Standard, normal, and emergency changes are ITIL and industry vocabulary rather than objective terms, but they explain how a CAB can meet on a schedule and still keep a network patched. A standard change is low risk, repeatable, and pre-approved; NIST’s preapproved examples include “vendor-provided security patches, updated antivirus signatures” (NIST 2011). A normal change is assessed case by case, with the high-risk ones going to the CAB. An emergency change goes through “a smaller approval body commonly known as the Emergency Change Advisory Board (ECAB)” (Amazon Web Services n.d.-a), and NIST has the CCB review it “as soon as is practical after” it is made.

Emergency is not the same as unauthorized. An emergency change skips the regular meeting but not the approval; an unauthorized change skipped the process entirely, and the CM-3(7) review exists to catch it after the fact. SY0-801’s “Emergency access” account type (covered at T-12) is unrelated.

Anatomy of a change record

The fastest way to learn the business-process elements is to read a change record that uses all of them. This illustrative record (documentation addresses, no real CVE) gives every element a line:

CHG-2026-1187  Class: Emergency (expedited)
Title:         Vendor firmware fix, VPN gateway vpn1.example.com (203.0.113.10)
Requester:     SOC lead; vendor advisory reports active exploitation
Owner:         Network services manager (accountable)
Implementer:   On-call network engineer (cannot approve this change)
Approval:      ECAB 2026-10-14 16:40 ET; full CAB review at next meeting
Stakeholders:  Remote staff, help desk, IdP/MFA team, SOC
Impact:        Reboot drops all tunnels for about 10 minutes
Dependencies:  RADIUS 198.51.100.20, SAML IdP, MFA push, monitoring probe
Test results:  Lab gateway: auth, tunnel, failover pass;
               legacy client 4.x fails TLS 1.3 handshake
Window:        22:00 to 23:30 ET; no other network changes (restricted)
Backout:       Prior firmware is the vulnerable build. Restore it only if
               the gateway fails health checks, then block external access
               at the edge firewall.
Fail forward:  If only legacy clients fail, keep the fix; push client 5.x
               per SOP-NET-014.
Decision:      23:00 ET; owner chooses backout or fail forward
Verify:        Version string, external scan, auth logs
Docs:          Network diagram revision, VPN SOP, config repo commit

Read top to bottom, the record follows the process order that NIST SP 800-128 lays out: request, record, determine whether control applies, analyze impact, test, approve, implement and notify, verify, and close out (NIST 2011). Testing comes before approval, which is why the “Test results” line caught the legacy-client failure before the window and the ECAB approved with that result in hand. Verification comes after implementation, which is why the “Verify” line names evidence (a version string, an external scan, the auth logs). Impact analysis here is one change’s security impact, in the sense of NIST CM-4 (NIST 2020): the 10-minute tunnel drop and the systems that depend on the gateway.

The twist is the backout line. The last known good firmware is the vulnerable firmware, so a plain rollback reopens the exposure. That is why the plan pre-approves a fail-forward branch, names a decision time (23:00 ET), and names a decision maker (the owner).

The seven technical implications

The Impact, Dependencies, Test results, and Window lines map onto the objective’s seven technical implications, which describe what the change does to the systems around it:

• Allow lists/deny lists: a hash-based allow list blocks the patched binary because its hash changed; update the rule in the same change (application control is covered at T-16).
• Restricted activities: what is prohibited, such as other network changes in the window.
• Downtime: the 10-minute tunnel drop that stakeholders hear about in advance.
• Service restart: systemctl restart takes dependents down too; list them with systemctl list-dependencies --reverse or Get-Service -DependentServices, and prefer nginx -t plus systemctl reload nginx when a reload will do.
• Application restart: one app’s process or pool, so only its sessions drop (CompTIA defines neither restart type; this split is interpretation).
• Legacy applications: client 4.x failing TLS 1.3.
• Dependencies: RADIUS, the IdP, and MFA push, found in impact analysis instead of in the outage.

Backout planning or fail forward

Backout planning means pre-written steps, a trigger, and a time limit for returning to the last known good state. SP 800-128 lists “Requirements for rollback of changes in the event that problems occur,” and CM-2(3) retains prior baselines “to support rollback” (NIST 2011; NIST 2020). The baseline is the thing you roll back to, so a backout plan presupposes that someone kept it. In version control, git revert HEAD backs out a bad commit by recording a new one, so the audit trail survives; git reset --hard rewrites history and discards the evidence of what went wrong.

Fail forward has no CompTIA definition. In industry usage it means keeping the change and deploying a corrective change instead of reverting. AWS calls it fixing forward and treats it as a policy decision rather than an improvisation: “Policies should specify when a fix-forward situation is allowed” (Amazon Web Services n.d.-b). Basically, fail forward is a pre-approved branch of the plan. Choosing it because nobody wrote a backout plan is a process failure, and the business-slang sense of learning from failure does not apply.

Google’s counterweight: on a found or suspected error, the team “rolls back first and investigates the problem second” (Hilton 2017). Rolling back first protects availability when the cause is unknown; failing forward protects a security gain, or a migration that cannot be undone. When I teach this in ITN 260, I frame it as a choice the plan makes before the window opens, not at 23:00. Rows marked reasoning are inference, not a published rule.

Situation	Lean	Basis
One-way schema or data migration already ran	Fail forward	Rollback “not straightforward” (Hilton 2017)
Patch for an actively exploited flaw breaks a minor feature	Fail forward plus workaround	Reasoning: backout reopens the exposure
User-visible failure, unknown root cause	Back out	“Rolls back first” (Hilton 2017)
Change freeze in effect	Back out to the approved baseline	Reasoning: the fix is itself a new change
Failed change disables the delivery channel	Back out by an out-of-band path	Channel File 291, below

The last row covers a change that breaks the mechanism you would use to undo it, and there is a well-documented example.

Channel File 291: when the backout cannot reach the host

On February 28, 2024, CrowdStrike’s Falcon sensor 7.11 for Windows added an IPC Template Type defining 21 input fields; the calling code supplied only 20. Its 12 static test cases ran against a channel file with a wildcard in field 21, so the mismatch never fired, and instances shipped cleanly on March 5 and April 8 to 24, 2024 (CrowdStrike 2024a; CrowdStrike 2024b). Every successful deployment made the next one look safer, which is the quiet danger in test results that never exercise the failing path.

At 04:09 UTC on July 19, 2024, two new instances went to Windows sensors 7.11 and above. One used a non-wildcard criterion in field 21; a Content Validator bug passed it, and deployment rested on “trust in the checks performed in the Content Validator” and earlier successes (CrowdStrike 2024b). The out-of-bounds read crashed hosts with bugcheck 0x50 in csagent.sys. The content was reverted at 05:27 UTC, 78 minutes later; Microsoft estimated 8.5 million affected devices, “less than one percent of all Windows machines” (Weston 2024).

A 78-minute revert sounds like a working backout plan, and for machines that had not yet pulled the bad file it was one. The revert often could not reach machines already stuck in a crash loop. Microsoft reported that some recovered after multiple restarts, but many needed Safe Mode or the Windows Recovery Environment, possibly a BitLocker recovery key, and del C-00000291*.sys in C:\Windows\System32\drivers\CrowdStrike (Microsoft n.d.). The lesson is the one the decision table ends on: a backout path cannot depend on the component that failed.

Mapped to the objective’s elements, the incident touches three. Test results: narrow test data and trust in past success. Impact analysis and dependencies: one update consumed by kernel-level code on every affected host. Backout planning: no reliable revert path to crashed hosts. The RCA’s own finding is “Each Template Instance should be deployed in a staged rollout,” and CrowdStrike added canary testing, deployment rings with bake-in time and rollback, and customer control over deployment (CrowdStrike 2024a). Canary deployment is not SY0-801 vocabulary; the exam’s only canary is the canary account (covered at T-15).

What you need to know for SY0-801

• Objective 1.2 is a scenario objective; a failed-change story most likely asks for the missing process element or the right recovery path.
• The approval process is nested under the CAB; an implementer approving their own change is an approval-process failure, and separation of duties (NIST AC-5, CM-5(4)) is the supporting control.
• Standard, normal, and emergency changes support the objective but are not objective terms; an emergency change is not an unauthorized one.
• Backout planning (701 said “Backout plan”) returns to the last known good state; fail forward keeps the change and ships a planned fix; a backup restore is recovery and can lose recent data.
• Test results come before approval, verification after implementation; SP 800-128 orders request, record, determine whether control applies, analyze impact, test, approve, implement and notify, verify, close out (most likely PBQ-style ordering material).
• The maintenance window is when; restricted activities are what is prohibited; a change freeze bars non-emergency changes.
• Impact analysis in this objective is one change’s security impact (NIST CM-4); business impact analysis is a separate topic under objective 5.2.
• Objective 1.2 says “Allow lists/deny lists”; application control under objective 4.1 says “Allow lists” and “Block lists”.
• Documentation and version control are sibling items; stale diagrams mislead responders, and version control gives diffs, attribution, and a rollback point.
• A backout path cannot depend on the component that failed; a change that breaks the delivery channel needs out-of-band recovery.

Check yourself

1. An administrator writes a change request to open TCP 1433 from a new reporting server to the payroll database, marks it approved, and implements it that night. It works, but an audit flags it. Which change management element was bypassed?

• A. Maintenance window.
• B. Change advisory board approval.
• C. Fail forward.
• D. Version control.

Answer: B. SY0-801 nests approval under the CAB, and self-approval defeats it. A working change that skipped approval is still unauthorized.

2. A release ran a one-way migration that split a customer table in two, and one report now fails. The previous build cannot read the new schema, and the approved plan includes a corrective-release branch. What should the team do?

• A. Redeploy the previous application build.
• B. Restore the database from last night’s backup.
• C. Fail forward with the corrective release the plan approved.
• D. Submit a new normal change for the next CAB meeting.

Answer: C. Rollback is not straightforward after a schema change, and a restore loses data written since the backup. Fail forward fits because the plan pre-approved it.

3. During an approved 22:00 to 23:30 window for a storage firmware upgrade, a network engineer also pushes an unrelated switch change, reasoning that users already expect an outage. Policy allows only the approved change in the window. Which 1.2 element was violated?

• A. Maintenance window.
• B. Restricted activities.
• C. Backout planning.
• D. Stakeholders.

Answer: B. The window defines when approved changes run; restricted activities define what may not happen during it. The switch change is also unauthorized, which NIST CM-3(7) review should detect.

This is T-35 of the Security+ 801 Countdown: one change from SY0-701 to SY0-801 every morning until the new exam launches on November 17, 2026. Tomorrow, T-34: Cryptography Adds Protocols and Stops Naming TPM, HSM, and Key Stretching. New here? Start with T-38: The Blueprint Was Reweighted and Trimmed to 27 Objectives.

References

Amazon Web Services. n.d.-a. “Change Management Categories and Priorities.” Establishing Your Cloud Foundation on AWS. Accessed October 12, 2026.

Amazon Web Services. n.d.-b. “OPS06-BP01 Plan for Unsuccessful Changes.” AWS Well-Architected Framework. Accessed October 12, 2026.

CompTIA. 2023. CompTIA Security+ SY0-701 Certification Exam Objectives. Version 5.0.

CompTIA. 2025. CompTIA Security+ SY0-801 V8 Certification Exam Objectives. Document Version 2.0.

CrowdStrike. 2024a. External Technical Root Cause Analysis: Channel File 291. August 6, 2024.

CrowdStrike. 2024b. “Preliminary Post Incident Review.” CrowdStrike Blog, July 24, 2024.

Hilton, Adrian. 2017. “Reliable Releases and Rollbacks: CRE Life Lessons.” Google Cloud Blog, March 24, 2017.

Microsoft. n.d. “Support Article KB5042421.” Microsoft Support. Accessed October 12, 2026.

NIST. 2011. Guide for Security-Focused Configuration Management of Information Systems. NIST Special Publication 800-128, includes updates as of October 10, 2019.

NIST. 2020. Security and Privacy Controls for Information Systems and Organizations. NIST Special Publication 800-53, Revision 5, includes updates as of December 10, 2020.

Treynor Sloss, Benjamin. 2016. “Introduction.” In Site Reliability Engineering. Google.

Weston, David. 2024. “Helping Our Customers through the CrowdStrike Outage.” Official Microsoft Blog, July 20, 2024.