A security manager is designing the control set for a new customer-facing service and notices that authentication, logging and encryption requirements are being specified differently by each project team, producing inconsistent and partly conflicting implementations. To make control implementation consistent and reusable across current and future systems, which measure should the security manager establish first?
- ADefine a reference security architecture with standard control patterns and approved building blocks teams must reuse. Correct
- BIssue a written policy stating that all systems must be secure and hold teams accountable in audits.
- CRequire each project to commission an independent security assessment before its go-live date.
- DCentralise approval so the security team signs off every system's control choices individually.
Why A is correct: A reference security architecture codifies authentication, logging and encryption as standard patterns and pre-approved building blocks, so each team implements from the same blueprint, eliminating the divergent and conflicting designs and accelerating future projects.
Why B is wrong: A high-level secure-by-default policy sets expectation and is necessary, but it gives teams no concrete, reusable specification, so each project will keep interpreting requirements differently and the inconsistency persists.
Why C is wrong: Independent assessments before go-live catch defects late and per project, which is appealing for assurance, but they neither prevent divergence nor make controls reusable and they discover the same inconsistencies after the cost of building them has already been incurred.
Why D is wrong: Centralised individual sign-off can enforce some consistency through a single reviewer, but it scales poorly, depends on one team's availability and still relies on case-by-case judgement rather than a shared standard, so it controls the symptom rather than the cause.