In July 2024, a faulty content update for a widely used endpoint detection product crashed about 8.5 million Windows computers in a few hours. Because the affected machines crashed during startup, many of them couldn't receive the corrected file, and administrators recovered them one at a time by hand, often typing a BitLocker recovery key into each one.
Few changes go that badly, but every change raises the same three questions: what could this break, how do we know it won't, and how do we get back if it does? On the CompTIA Security+ SY0-801 exam these questions belong to objective 1.2, which asks you to apply change management to scenarios and judge its effect on security. This lesson covers impact analysis, test results, backout planning, and failing forward, the option of fixing a failed change with another change instead of undoing it.
Impact analysis decides how risky a change is and who must approve it
Impact analysis is the assessment done before approval to predict what a change will affect and how badly things could go. The change owner usually writes it with help from technical reviewers and attaches it to the request for change. A useful impact analysis answers five questions:
- Scope: which systems, services and users does the change touch, directly and through dependencies?
- Likelihood and severity: how likely is it to fail, and how much damage would a failure do?
- Security effect: does it change the attack surface, access rights, logging or an existing control?
- Business effect: how much downtime, what performance change, what effect on data or compliance scope?
- Cost of doing nothing: what risk remains if the change is postponed or rejected?
The result is a risk rating, often low, medium or high, that routes the change to the right approver. A low-risk change might need a peer review; a high-risk change goes to the full change advisory board.
Here is a worked example. A vendor needs ongoing access to the management interface of a storage array to support it. The request is a firewall rule allowing the vendor's support network, 198.51.100.0/24, to reach the array on TCP 443. The impact analysis notes that the change exposes an administrative interface to an outside network, so the vendor's accounts need multifactor authentication and the sessions must be logged. Because rule additions on this firewall don't drop existing sessions, there is no downtime. The CAB approves with conditions: source limited to that one range, MFA required, and a review of the rule every 90 days.
The last question matters more than it looks. Postponing a patch for an internet-facing flaw that attackers are exploiting can be far riskier than a short outage. A good impact analysis states both sides so the approvers can compare them.
Test results are the evidence an approval rests on
A CAB shouldn't approve a change on the implementer's word. Test results show that the change worked in an environment that resembles production, and they belong in the change record alongside the request.