ISACA CISM Study Guide

Domain 1 — Information Security Governance 17%

Governance vs. management

Governance sets direction and oversight — it evaluates, directs, and monitors. It is the board/executive responsibility: defining what the organization wants security to achieve and holding it accountable. Management plans, builds, runs, and monitors within that direction. The exam loves this distinction: setting a risk appetite is governance; implementing a control to stay within it is management.

Strategy & alignment

The security strategy exists to support business objectives, not the other way around. A strategy needs a desired end state (often expressed through a maturity model like CMMI), the current state (from a gap analysis), and a roadmap between them. Drivers include business goals, regulation, the threat landscape, and stakeholder requirements. Value is delivered through a business case and measured in business terms.

Frameworks & standards

• ISO/IEC 27001 — certifiable standard for an Information Security Management System (ISMS); 27002 gives the control guidance.
• NIST Cybersecurity Framework (CSF) — outcome-based functions (Govern, Identify, Protect, Detect, Respond, Recover); great for risk-based prioritization.
• COBIT — ISACA's own governance-and-management framework; separates governance objectives from management objectives, mapping IT to enterprise goals.
• Supporting: NIST 800-53, ITIL (service management), and balanced-scorecard thinking.

Roles, responsibilities & culture

Senior management owns accountability and sets tone at the top; the steering committee aligns security with business priorities and arbitrates resources; the CISO owns the strategy and program. Crucial idea: accountability can't be delegated even when a task is. Governance succeeds only with executive sponsorship and an organizational culture that supports it.

Metrics

Governance metrics must be meaningful to leadership and tied to objectives — not raw technical counts. Good metrics are SMART, show trends, and inform decisions (e.g., percentage of critical risks within appetite, time-to-remediate, control coverage). Report in the language of business value and risk, not packets and patches.

Domain 2 — Information Security Risk Management 20%

The risk equation & vocabulary

Risk is the effect of uncertainty on objectives — informally, threat × vulnerability × impact, moderated by likelihood. Know the parts cold: asset (what has value), threat (the potential cause), vulnerability (the weakness exploited), likelihood, and impact.

Assessment: qualitative vs. quantitative

Qualitative assessment ranks risk on scales (high/medium/low, heat maps) — fast and common. Quantitative assessment puts money on it. Memorize the chain:

• SLE = AV × EF — Single Loss Expectancy = Asset Value × Exposure Factor.
• ALE = SLE × ARO — Annual Loss Expectancy = SLE × Annualized Rate of Occurrence.
• A control is worth buying when its annual cost is less than the reduction in ALE it produces (cost-benefit / cost of the safeguard vs. value protected).

Inherent vs. residual risk

Inherent risk is the risk before any controls. Residual risk is what remains after controls are applied. Residual risk must be brought within the organization's risk appetite/tolerance — and whatever is left must be formally accepted by the right person.

Ownership & who accepts risk

Don't confuse the two roles. The risk owner (a business owner of the asset or process) is accountable for the risk and is the one who accepts residual risk — not the CISO or security team. The control owner is responsible for the control's design and operation. Security advises and facilitates; the business owns and accepts. This is a favorite exam trap.

Risk treatment options

• Mitigate / modify — apply controls to reduce likelihood or impact.
• Transfer / share — insurance, outsourcing (you transfer the financial impact, but accountability stays with you).
• Avoid — stop the activity that creates the risk.
• Accept — knowingly retain the risk within appetite, with formal sign-off.

Monitoring: KRIs and registers

The risk register tracks each risk, its owner, treatment, and status. Key Risk Indicators (KRIs) are leading metrics with thresholds that warn when risk is trending toward (or past) appetite — they trigger action before a loss event. Risk is a continuous cycle: identify → assess → treat → monitor → reassess as the business and threat landscape change.

Domain 3 — Information Security Program 33%

The largest domain: turning strategy and risk decisions into a running program.

Program resources

A program needs people, processes, and technology aligned to the strategy. Manage the resource mix — staffing and skills, the architecture, and the budget — and integrate security into existing enterprise processes (HR onboarding/offboarding, change management, procurement, SDLC) rather than bolting it on.

Asset classification

You can't protect what you haven't valued. Classify assets and data by sensitivity/criticality (e.g., public → internal → confidential → restricted) so controls are proportional to value. Each asset needs an owner (accountable, sets classification) and a custodian (implements the protective controls).

Document hierarchy

Know the order and what each layer is — a frequent exam item:

• Policy — high-level intent and direction, approved by senior management; mandatory, slow to change.
• Standard — mandatory, specific rules that enforce policy (e.g., "use AES-256").
• Procedure — mandatory step-by-step "how to" instructions.
• Guideline — recommended, non-mandatory best-practice advice.
• Baseline — the minimum required security configuration for a system or platform.

Controls: types & categories

By category: administrative/managerial (policies, training, risk assessments), technical/logical (firewalls, encryption, access control), and physical (locks, guards, cameras). By function/type: preventive, detective, corrective, deterrent, compensating, and directive. Expect scenarios that ask you to name both — and to choose a control that's cost-justified against the risk it addresses.

Security awareness & training

People are a primary control. Differentiate awareness (broad, ongoing, changes behavior) from training (role-specific skills) and education (deeper, career-oriented). Tailor content to the audience, measure effectiveness (e.g., phishing click-rate trends), and refresh it regularly.

Third-party & SLAs

Manage vendor and supply-chain risk across the lifecycle: due diligence before onboarding, security requirements and a right-to-audit clause in contracts, and ongoing monitoring. The SLA defines measurable service and security commitments; related agreements include MSA, MOU/MOA, NDA, and BPA. Remember: you can outsource the work, not the accountability.

Program metrics: KGI, KPI, KRI

• KGI (Key Goal Indicator) — did we achieve the objective? (outcome/lagging)
• KPI (Key Performance Indicator) — how well is a process performing toward the goal? (leading)
• KRI (Key Risk Indicator) — is risk trending toward our thresholds? (early warning)

Report a small set of decision-useful metrics that connect program performance to business risk.

Domain 4 — Incident Management 30%

The planning trio: IRP, BCP, DRP

• IRP (Incident Response Plan) — detect, respond to, and recover from security incidents.
• BCP (Business Continuity Plan) — keep critical business functions running during disruption.
• DRP (Disaster Recovery Plan) — restore IT/technology services after a disaster (a subset that supports the BCP).

Business Impact Analysis (BIA)

The BIA is the foundation: it identifies critical processes, their dependencies, and the impact of downtime over time — and it produces the recovery objectives below. You can't set sound recovery targets without it.

Recovery objectives

• RTO — Recovery Time Objective: how fast a process/system must be back.
• RPO — Recovery Point Objective: how much data loss is tolerable (drives backup frequency).
• MTD — Maximum Tolerable Downtime: the absolute ceiling; RTO must be shorter than MTD.
• WRT — Work Recovery Time: time to validate/restore data and resume normal operations after systems are back. (RTO + WRT ≤ MTD.)

Classification & triage

Categorize and prioritize incidents by severity and business impact so response effort matches stakes. Clear criteria and escalation paths prevent both over- and under-reaction — and define when an incident becomes a crisis that invokes the BCP/DRP.

Testing the plans

Plans are only as good as their last test. In rough order of rigor and disruption: checklist/read-through → walkthrough/tabletop → simulation → parallel test (recovery site runs alongside production) → full interruption (production fails over — highest risk, run with care). Test regularly and feed lessons back into the plans.

The response lifecycle

A common model: Preparation → Identification/Detection → Containment → Eradication → Recovery → Lessons Learned. Within that, manage containment (short-term to stop the bleeding, then long-term), eradication (remove the root cause — malware, compromised accounts), and recovery (restore to known-good and monitor for recurrence). Don't skip ahead: eradicating before you've contained can tip off an attacker.

Communications & chain of custody

Plan communications in advance: who is notified, who speaks publicly, and which legal/ regulatory breach-notification obligations apply. Preserve evidence with a documented chain of custody (who handled what, when, and how) so it stays admissible — touch evidence as little as possible and image before analyzing.

Post-incident review

After recovery, run a blameless lessons-learned review: root cause, what worked, what didn't, and concrete improvements to controls, detection, and the plan itself. This closes the loop back to governance, risk, and the program.