A SOC analyst wants to push an EDR policy change that blocks suspicious script execution across production workstations. The change could reduce malware risk but might break legitimate applications and monitoring. What should happen before production deployment?
Select an answer to reveal the explanation.
Short Explanation
Think of a production EDR policy like live traffic lights: one bad change can freeze legitimate apps or blind your alerts. You want change control because it makes someone review impact, approvals, and a rollback plan before rollout. Testing one host is useful, but it does not manage the operational risk of a fleet-wide change.
Full Explanation
Change control exists to treat detection and response modifications as operational changes, not just technical edits. When an analyst alters an EDR policy, the change can stop malicious script execution but also block approved business software, alter telemetry, or reduce visibility. A controlled change process requires impact review, approval, rollback, and communication, which lowers the chance of creating monitoring gaps while still improving security posture. Validation on a lab host is useful evidence, but by itself it does not establish production readiness, stakeholder approval, or a tested rollback path. Adding a SIEM alert for script execution is a detection-engineering activity; it may improve coverage but does not govern whether the endpoint policy should be deployed fleet-wide. Documenting the change in the runbook after deployment is helpful for knowledge retention, yet it is retrospective and cannot prevent an outage or blind spot caused by an unreviewed change. Exam caveat: CompTIA expects efficiency to mean reducing risk and toil with repeatable process, not simply approving changes slowly. Operational check: require the ticket to list affected asset groups, expected telemetry changes, rollback command, and a post-change monitoring window.