Shortly after deployment began, a new endpoint security agent caused a critical business application to crash on the first group of machines. What should have been done to prevent this?
Select an answer to reveal the explanation.
Short Explanation
Before you put a new part in a running engine, you try it on the test bench. Security tools touch the same systems the business depends on, so they can break things too. The trap is fixing it by skipping protection or swapping vendors; the real miss was testing first.
Full Explanation
Security controls are changes to the environment and can interact with business systems in unexpected ways. Integration testing in an environment that represents production, including critical business applications and their typical workloads, identifies conflicts before they affect users, and allows configuration exclusions or vendor fixes to be agreed in advance. Deploying the agent only to machines without business applications avoids the conflict by leaving the most important endpoints unprotected, which defeats the purpose of the control. Choosing a different vendor based on memory use assumes a cause that has not been established; any agent can conflict with an application, and without testing the replacement could fail the same way. Relying on users to report crashes so the agent can be removed is a reactive recovery approach that accepts business disruption as part of deployment, and it removes protection whenever a problem appears. Exam caveat: CISM expects control implementation to follow the organization's change and release processes, with testing and rollback planning proportionate to business impact. Operational check: confirm that the deployment plan lists the critical applications tested, records the results and approved exclusions, includes a rollback procedure, and stages deployment so the first wave is small and closely monitored.