Several recent outages and data exposures were traced to changes that went into production without anyone considering their security impact. What should the information security manager recommend?
Select an answer to reveal the explanation.
Short Explanation
If every renovation's done without asking the structural engineer, sooner or later a wall comes down. You build the risk check into the change process, scaled to how big the change is. The trap is making security a bottleneck for every tiny tweak, or only checking after the damage is done.
Full Explanation
Change management is the natural control point for preventing changes from introducing unassessed risk. Integrating a security risk review into that process, with criteria that identify significant changes such as those affecting critical systems, sensitive data, access paths or security controls, ensures security impact is considered before implementation while routine low-risk changes move quickly. This embeds risk management into business-as-usual operations rather than relying on after-the-fact detection. Requiring security approval for every change regardless of size creates a bottleneck, slows the business and spreads security attention thinly across trivial changes. Scanning production after each release detects some technical vulnerabilities, but only after exposure has occurred, and it would not identify many design or process risks, such as altered data flows or access rights. Freezing all changes until an enterprise assessment is finished halts legitimate business activity and does not fix the process gap that caused the problem. Exam caveat: standard pre-approved changes can bypass the review if they were assessed once and follow a defined pattern. Operational check: confirm the change request template includes security impact criteria, that significant changes show a recorded security review before approval, and that post-implementation reviews track related incidents.