Different project teams make conflicting security design choices: one encrypts data at rest, another relies only on network controls, and design reviews argue every decision from scratch. What would MOST effectively bring consistency to these decisions?
Select an answer to reveal the explanation.
Short Explanation
Without a shared playbook, every team invents its own rules and every review turns into a debate. Principles give you the same starting point on every project. The trap is relying on one person's judgment or testing after the fact; neither tells your teams how to design consistently up front.
Full Explanation
Security architecture principles are concise, approved statements of design intent, for example that sensitive data is protected at rest and in transit, that access follows least privilege, and that components are segmented by trust level. Because they are documented and endorsed by management, they give every project the same reference point, reduce repeated debate in design reviews and make exceptions visible and deliberate. Approval by an individual engineer on personal judgment produces decisions that vary with the reviewer, creates a bottleneck and leaves no durable rationale for teams to follow. Letting each project manager choose controls according to budget optimizes for cost within one project and almost guarantees the inconsistency already observed, while ignoring enterprise risk. A penetration test after go-live may reveal weaknesses, but it is a late detective activity; it does not guide design choices and finds problems when they are most expensive to fix. Exam caveat: CISM views the security manager as setting direction through principles, standards and governance rather than making every design call personally. Operational check: confirm that design review templates require teams to show how each principle is met or to record an approved exception, and track exceptions by principle to see where guidance needs refining.