On a Monday morning, the security team switches its new EDR agent from audit mode to block mode on 2,000 endpoints. By 9:00 the warehouse can't ship orders. The 15-year-old inventory application, which writes executables into its own folder and loads an unsigned DLL, has been quarantined on every packing station. The EDR worked exactly as configured; the change review never asked what else it would touch.
On the CompTIA Security+ SY0-801 exam, objective 1.2 lists the technical side effects a change review has to account for, and its scenarios ask you to predict them or diagnose them after the fact. This lesson covers allow and deny lists, restricted activities, downtime, service and application restarts, legacy applications and dependencies.
Allow lists and deny lists have to change when systems change
An allow list permits only what is listed and blocks everything else. A deny list blocks only what is listed and permits everything else. Both are written against a specific set of files, addresses or domains, so when a change alters any of those, the lists have to change with it.
Application allow listing shows the problem clearly. Windows AppLocker, for example, can identify an allowed program by its publisher, its path or its file hash. A hash rule matches one exact file, so the next update produces a new hash and the updated program is blocked on every locked-down workstation. A publisher rule, based on the vendor's code-signing certificate, keeps working across updates from the same vendor as long as it isn't pinned to one version, which is why frequently updated software usually gets publisher rules. In an allow-listed environment, every software update needs a matching allow list update in its change plan.
Network lists behave the same way. Firewall rules, cloud security groups and API allow lists often name IP addresses. Moving a server to a new address, adding a cloud region or a vendor changing its outbound range all require list updates, or traffic simply stops. Deny lists catch changes from the other side: a new SaaS tool may be blocked by the web proxy's category filter or by DNS filtering until someone adds an exception.
Removing access is a change too. When a server is decommissioned or a vendor contract ends, its allow list entries should be removed in the same change. Cloud addresses get reassigned, so a stale entry can end up allowing a stranger's system. Temporary entries, such as a broad rule added for testing, need an owner and an expiry date in the change record.
On the exam, "after the update, the application won't start on the kiosk machines" points to an allow list that wasn't updated. Application control itself is covered in the hardening section, and firewall rule writing in the network defenses section.
Restricted activities keep the implementer inside the approved scope
An approved change defines what the implementer may do: which systems, which steps, which accounts and which hours. Anything outside that scope is a restricted activity, even if it seems helpful.
Suppose an administrator is patching web servers under an approved change and notices a misconfigured share on a nearby file server. Fixing it "while I'm in there" feels efficient, but that fix has no impact analysis, no testing, no backout plan and no stakeholder notice. If the file server breaks the next morning, nobody will connect the failure to a web server patch, because the change record doesn't mention it.
Change records commonly restrict other activities as well:
- No access to production data beyond what the change requires.
- Only the approved accounts, such as a privileged account checked out of the privileged access management system for the length of the window.
- No work outside the approved window.
- No disabling security tools to make an installation easier unless the plan says so.
If the scope has to grow during the change, the implementer stops and gets additional approval rather than expanding the work alone. This has a security payoff beyond avoiding mistakes. An attacker using a stolen admin account looks much like an administrator making unapproved small fixes. When administrators stay strictly inside approved scope, activity outside it stands out in the logs.