Topics in this domain
- The Security Program: Charter, Scope and Objectives
- Security Team Structure, Roles and Staffing
- Working with Legal, HR, IT, Audit and the Business
- Program Implementation: From Plan to Operating Controls
- Information Asset Identification and Valuation
- Data Classification: Owners, Custodians and Users
- Data Lifecycle: Retention, Archiving and Secure Disposal
- Enterprise Architecture for Security Managers
- Information Security Architecture: Principles and SABSA
- Defence in Depth and Zero Trust
- Cloud Security and Shared Responsibility
- Control Frameworks: NIST SP 800-53, CIS Controls and ISO 27002
- Security Policy Development and Lifecycle
- Security Standards and Baseline Requirements
- Procedures, Guidelines and Acceptable Use
- Policy Enforcement, Exceptions and Review
- Designing Security Metrics: KPIs, KRIs and KCIs
- Collecting, Analysing and Reporting Metrics
- Security Maturity Models and Program Assessment
- Control Types and Categories
- Control Design and Selection Based on Risk and Cost
- Control Testing: Design vs Operating Effectiveness
- Identity and Access Management
- Network and Endpoint Security Controls
- Application Security and the Secure SDLC
- Configuration, Change and Patch Management
- Cryptography for Security Managers
- Security Testing: Scanning, Pen Testing and Tracking Remediation
- Security Awareness Program Design
- Role-Based Security Training
- Phishing Simulations and Social Engineering Defences
- Third-Party Risk Management and Due Diligence
- Vendor Contracts, SLAs and Right to Audit
- Fourth-Party and Supply Chain Risk
- Outsourcing and Managed Security Services
- Security Stakeholder Communication
- Executive Dashboards and Board Reporting
- Continuous Improvement of the Security Program
Program Implementation: From Plan to Operating Controls
Installed isn’t implemented
Organisations are full of security tools that were bought, installed and left half-configured. Control implementation and integration is a named topic in CISM Domain 3 because turning plans into working controls is where security programs most often stumble.
A control is implemented when it operates reliably, has an owner and produces evidence that it works.
The implementation path
- Plan: requirements, owner, budget, success measures. Run it as a project with a sponsor.
- Design and build to fit the architecture and processes.
- Test: does it work, and does it break anything?
- Deploy and integrate through change management; train users and operators.
- Operate and hand over: runbooks, and a named owner who accepts it into business as usual.
- Monitor: metrics and evidence show it keeps working.
Integration is the hard part
- Architecture: does it fit the identity, network and cloud designs?
- Processes: does it work with joiner-mover-leaver, change and incident response?
- Other controls: do its logs reach the SIEM, and its alerts reach ticketing?
- People: do users understand it, and can operators run it?
Reviewing a new tool against the architecture before buying it avoids many integration failures.
Handover to business as usual
A project ends; the control must keep running. Before closing a project, make sure there’s:
- a named operational owner who accepts it
- runbooks and procedures
- service levels and monitoring
- budget for the ongoing running costs
Example. An EDR rollout reached 95% of endpoints and the project closed. Six months later, coverage was down to 70%: new laptops weren’t being enrolled because nobody owned onboarding. The fix: the end-user computing team took ownership, with a coverage KPI reviewed every month.
Did it work?
A post-implementation review asks whether the control meets its objective and reduces the risk it was meant to, not just whether the project finished on time and on budget. Lessons feed back into the next initiative.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Best indicator that a control is implemented | It operates as designed and produces evidence |
| Risk of skipping change management for security changes | New outages or vulnerabilities |
| Key requirement before closing a security project | A named operational owner and runbooks |
| How to judge implementation success | Against the control objective and the risk reduced |
| Avoiding tools that don’t integrate | Review against the architecture before buying |
In short
- Implementing a control means it operates reliably, has an owner and produces evidence, not just that a tool is installed.
- Security initiatives are run as projects with scope, budget, timeline, sponsor and success measures.
- Integration with existing architecture, processes and other controls is where many implementations fail.
- Changes go through change management; users and operators are trained before go-live.
- Handover to business as usual needs runbooks, a named owner and agreed service levels.
- Post-implementation monitoring confirms the control meets its objective; problems feed back into improvement.
Exam traps
- Installed is not the same as effective.
- Skipping change management to deliver security faster creates its own risks.
- Projects that end without a named operational owner leave controls nobody runs.
- Measure success against the control objective, not against project milestones.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The implementation path