CISM - Information Security Program (33% of the exam) - Section 3.7

Implement and integrate information security controls across systems, processes and third-party services.

Implement information security controls across systems, business processes, and third-party services using a defence in depth approach and sound security architecture principles. Recognise integration challenges that arise when embedding controls into existing environments and apply strategies to resolve them without disrupting business operations.

Control implementationIntegrationDefence in depthSecurity architecture

Practice question for this objective

Free sampleInformation Security Programhard

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.

A reference security architecture with reusable control patterns is what makes control implementation consistent across systems. Inconsistent per-project controls stem from the absence of a shared blueprint; a reference architecture with standard patterns and approved building blocks gives every team the same starting point, so consistency and reuse are designed in rather than enforced after the fact.

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.

See more CISM practice questions, answers explained.

Exam traps in Information Security Program

Answers that look right on this material and are not. Each one is a distractor from a different question in the CISM bank for this domain.

Requiring every project team to submit its bespoke control design to the security team for individual approval before each system goes live, reviewing each implementation case by case.
Why it is wrong: Tempting because review adds oversight, but approving bespoke designs one at a time still permits inconsistency and creates a recurring bottleneck rather than reusable, uniform controls.
Provision local platform accounts with strong password rules and review the vendor's access list manually each quarter.
Why it is wrong: Local accounts and quarterly manual reviews are tempting because they need no integration work upfront, but they fragment identity off the corporate provider, delay deprovisioning of leavers and impose recurring manual effort, which is the opposite of durable low-burden assurance.
Deploy the standalone access-control product because a dedicated tool for the new system gives the security team the finest possible control over that single application's user permissions.
Why it is wrong: Tempting because a dedicated tool can feel more precise for one system, but it creates an unmanaged silo with its own joiner-mover-leaver gaps and no consistency with enterprise governance.

Examworthy is not affiliated with or endorsed by ISACA. Original, blueprint-aligned practice material only.