CISM

17%  ·  Aligning the security program with business strategy through governance structures and clear accountability.

Governance fundamentals

• Governance sets direction and oversight; management executes — the board owns risk appetite, the CISO runs the program.
• A security strategy must trace to business objectives — every control answers to a business driver, not the reverse.
• Governance value drivers — strategic alignment · risk management · value delivery · resource optimisation · performance measurement.

Roles and responsibilities

• Define accountability with a RACI — board · steering committee · CISO · data owners · custodians · users.
• The steering committee bridges business and security, prioritising investment against risk.

Frameworks and standards

• Map the program to a recognised framework — ISO/IEC 27001 · NIST CSF · COBIT 2019.
• Governance, risk, and compliance (GRC) tooling keeps policy, risk, and control evidence in one place.

20%  ·  Identifying, assessing, and treating information risk to a level the business accepts.

Risk concepts

• Inherent versus residual risk; risk appetite (how much you’ll pursue) versus tolerance (how much you’ll bear).
• Quantitative terms — SLE (single loss expectancy) · ARO (annual rate of occurrence) · ALE = SLE × ARO.

Risk assessment

• Identify assets, threats, and vulnerabilities; assess likelihood and impact (qualitative or quantitative).
• Keep a living risk register — owner · score · treatment · review date — not a one-off spreadsheet.

Risk treatment

• Treat each risk explicitly — accept · avoid · transfer · mitigate — then monitor the residual.
• Spend on controls in proportion to asset value and exposure; a control must cost less than the risk it removes.

33%  ·  Building and running the program — resources, controls, metrics, and assurance. The heaviest domain.

Program development

• A program turns strategy into a roadmap — people · process · technology — with a defined operating model.
• Align control objectives to the framework; baseline with standards such as NIST SP 800-53 and tailor to context.

Controls and operations

• Layer administrative, technical, and physical controls; prefer preventive, detect what you cannot prevent.
• Define an awareness program — phishing simulation · role-based training · measurable behaviour change.

Metrics and assurance

• Measure with KPIs (performance) and KRIs (risk) that a business audience can read — not raw tool output.
• Use independent assessment — internal audit · SOC 2 · penetration tests — to validate the program, not just self-attest.

Third-party and supply-chain risk

• Assess vendors before onboarding and on a cycle; bake security terms, audit rights, and breach notification into contracts.
• Track the residual risk a provider carries on your behalf — outsourcing the work never outsources the accountability.

30%  ·  Preparing for, detecting, responding to, and recovering from security incidents — and learning from them.

Incident response lifecycle

• Prepare → detect and analyse → contain → eradicate → recover → post-incident review (NIST SP 800-61).
• Define severity tiers and escalation up front; an incident is no time to invent the decision tree.

Preparation and detection

• Stand up an incident response plan, a trained team (CSIRT), and tested playbooks before you need them.
• Centralise detection — SIEM · continuous monitoring · threat intelligence — and tune for signal over noise.

Business continuity and recovery

• Tie response to continuity metrics — RTO (downtime) · RPO (data loss) · MTD (maximum tolerable downtime).
• Test the plan with tabletop and failover exercises; an untested plan is an assumption, not a capability.

Communication and lessons learned

• Pre-agree who speaks to executives, customers, and regulators, and on what timeline — breach laws set hard clocks.
• Close every incident with a blameless review that feeds concrete fixes back into the program.