Risk assessment methods, ALE calculations, treatment options, BIA recovery objectives, and risk frameworks — the analytical core every CISM candidate must master.
Study with Practice Tests →Domain 2 covers the end-to-end process of identifying, analyzing, evaluating, treating, and monitoring information security risk.
CISM Exam Focus (20%): This domain is heavily scenario-based and math-light — while you must know ALE formulas, most questions test judgment: choosing the right treatment option, interpreting a risk scenario, or selecting the best response when risk exceeds tolerance. Always think in terms of business impact and risk appetite.
Any circumstance or event with the potential to exploit a vulnerability and cause harm to an asset. Threats can be natural (flood), human (attacker), or environmental (power failure). Threats cannot be eliminated — only the vulnerabilities they exploit can be reduced.
A weakness in an asset, system, or control that could be exploited by a threat. Vulnerabilities are what organizations can directly control through patching, hardening, and process improvements.
The potential for loss or damage when a threat exploits a vulnerability. Risk = Threat × Vulnerability × Impact. Risk is a function of both likelihood (probability) and impact (consequence). Risk cannot be fully eliminated — only managed.
The level of risk that exists BEFORE any controls are applied. The raw, uncontrolled risk of a business activity. Used as a starting point for risk assessment to understand worst-case exposure.
The risk that REMAINS after controls have been implemented. Residual Risk = Inherent Risk − Control Effectiveness. Residual risk must be formally accepted by management if it exceeds risk appetite.
Appetite: Total risk the org is willing to accept (strategic, board-set). Tolerance: Acceptable variance around the appetite. Threshold: Point at which action is triggered. Threshold ≤ Tolerance ≤ Appetite.
| Concept | Must-Know Detail |
|---|---|
| ALE formula | ALE = SLE × ARO; SLE = Asset Value × Exposure Factor |
| Control cost rule | Implement control only if cost of control < reduction in ALE it provides |
| Residual risk | Risk remaining after controls; must be formally ACCEPTED by management with authority |
| Risk acceptance | Must be documented, approved by appropriate authority — not a passive decision |
| Risk treatment options | Mitigate (reduce), Accept, Transfer (insurance/outsourcing), Avoid (stop the activity) |
| RTO vs RPO | RTO = max acceptable downtime; RPO = max acceptable data loss (in time) |
| RTO relationship to MTD | RTO must always be LESS THAN MTD (Maximum Tolerable Downtime) |
| Qualitative vs quantitative | Qualitative = subjective (High/Med/Low matrix); Quantitative = monetary values (ALE) |
| Risk register purpose | Living document tracking all identified risks, assessments, treatment decisions, and ownership |
| Risk assessment first step | Identify and value assets FIRST — you cannot assess risk without knowing what you're protecting |
| BIA primary purpose | Identify critical business processes and the impact of their disruption — not a technical exercise |
| Third-party risk | Organizations remain accountable for risk even when outsourced — responsibility transfers, not accountability |
The systematic process of identifying, analyzing, and evaluating risk — the foundation of all risk management decisions.
Define the boundaries of the risk assessment — which assets, processes, systems, or business units are in scope. Understand organizational objectives and risk appetite. This step sets the frame for everything that follows.
Identify all assets and their value, threats that could harm them, and vulnerabilities that threats could exploit. Sources include threat intelligence, past incidents, interviews, questionnaires, and vulnerability scans. Output: list of risk scenarios.
Evaluate the likelihood and impact of each identified risk scenario. Can be qualitative (High/Medium/Low), quantitative (ALE = SLE × ARO), or semi-quantitative (scoring scales with monetary context). Output: risk ratings and priorities.
Compare risk ratings against the organization's risk criteria and risk appetite. Determine which risks require treatment, which can be accepted, and which are priorities. Output: list of risks ranked for treatment decisions.
Select and implement appropriate responses: Mitigate (controls), Accept (document and approve), Transfer (insurance/contract), or Avoid (cease activity). Document treatment decisions in the risk register. Output: risk treatment plan.
Continuously monitor risks, control effectiveness, KRIs, and changes in the risk environment. Update the risk register as risks change. Report to management. Risk management is a continuous cycle, not a one-time event.
Risk communication occurs throughout ALL steps — not just at the end. Senior management must be kept informed so they can make timely decisions about risk tolerance and treatment.
| Attribute | Qualitative | Quantitative |
|---|---|---|
| Method | Subjective ratings — High / Medium / Low, color-coded risk matrices | Objective monetary values — SLE, ALE, ARO, asset value |
| Speed | Fast — can be done quickly with minimal data | Slow — requires detailed asset valuation and probability data |
| Accuracy | Less precise; depends on expert judgment and consensus | More precise; based on actual financial figures |
| Data needed | Expert opinions, threat scenarios, vulnerability ratings | Asset values, historical incident data, loss statistics |
| Best for | Initial assessment, prioritization, communicating to non-technical stakeholders | Cost-benefit analysis of controls, regulatory reporting, executive decisions |
| Output | Risk matrix, risk heat map, risk ratings (H/M/L) | ALE, expected loss figures, ROI of security investment |
| Disadvantage | Subjectivity; different analysts may rate same risk differently | Requires hard-to-obtain data; can create false precision |
| Likelihood ↓ / Impact → | Low Impact | Medium Impact | High Impact | Critical Impact |
|---|---|---|---|---|
| High Likelihood | Medium | High | Critical | Critical |
| Medium Likelihood | Low | Medium | High | Critical |
| Low Likelihood | Low | Low | Medium | High |
| Very Low Likelihood | Low | Low | Low | Medium |
Risk rating = Likelihood × Impact. Critical and High risks require immediate treatment. Medium risks require a treatment plan. Low risks may be accepted with documentation.
US federal risk assessment methodology. Three-step process: prepare for assessment, conduct assessment (identify threats/vulnerabilities/likelihood/impact), communicate results. Widely used beyond government.
Enterprise-wide risk framework — not security-specific. Principles, framework, and process. Used to integrate security risk into the broader organizational risk management program.
Qualitative, self-directed risk assessment method by CMU CERT. Three phases: Build asset-based threat profiles, Identify infrastructure vulnerabilities, Develop security strategy. Used when external consultants aren't available.
Quantitative risk analysis model. Decomposes risk into Loss Event Frequency (LEF) and Loss Magnitude (LM). Produces monetary risk estimates. Increasingly used for board-level financial risk reporting.
Intel-developed framework focused on threat agents (who is attacking) rather than vulnerabilities. Maps threat agent goals and methods to assets. Useful for targeted threat modeling.
Central artifact of risk management — not a framework but a critical deliverable. Contains: risk description, likelihood, impact, rating, owner, treatment decision, treatment status, residual risk, review date.
The formulas, calculations, and cost-benefit logic behind quantitative risk assessment — a guaranteed exam topic.
| Term | Definition | Example |
|---|---|---|
| Asset Value (AV) | Total value of the asset — includes replacement cost, business value, data sensitivity, and recovery cost | Database server worth $200,000 |
| Exposure Factor (EF) | Percentage of asset value lost in a single threat event (0–100%). Not the probability of occurrence. | Fire destroys 60% of server capacity → EF = 0.60 |
| SLE | Expected loss from ONE incident = AV × EF | $200,000 × 0.60 = $120,000 |
| ARO | Expected number of times the threat occurs per year. ARO < 1 means less than once per year (e.g., 0.1 = once per 10 years) | Fire expected once every 10 years → ARO = 0.10 |
| ALE | Expected annual loss = SLE × ARO | $120,000 × 0.10 = $12,000/year |
Full lifecycle cost of a security control — purchase price + implementation + training + maintenance + support + decommissioning. Must be compared against the ALE reduction the control provides to determine ROI.
ROSI = (ALE × Mitigation Ratio) − Annual Control Cost. Measures the financial return of a security investment. Positive ROSI = control is worth implementing. Used to justify security spending to executives.
Average time between system failures. Used in availability calculations: Availability = MTBF ÷ (MTBF + MTTR). Higher MTBF = more reliable system. Important for hardware and system risk assessment.
Average time to restore a failed system. Used alongside MTBF to calculate availability and inform RTO planning. Shorter MTTR = faster recovery = lower downtime risk.
Availability = MTBF ÷ (MTBF + MTTR)
Example: MTBF = 190 hrs, MTTR = 10 hrs → Availability = 190 ÷ 200 = 95%. "Five nines" (99.999%) = ~5 min downtime/year.
Annual cost of implementing and maintaining a security control. Decision rule: implement the control if ACS < (ALE before − ALE after). If ACS > the ALE reduction, the control is not cost-effective.
How to respond to identified risks, and how to determine recovery priorities through BIA.
Implement controls to reduce the likelihood or impact of the risk to an acceptable level. The most common treatment — examples include patching, encryption, access controls, and monitoring.
Acknowledge the risk and consciously decide to accept potential consequences. MUST be documented and formally approved by management with appropriate authority. Not the same as ignoring risk.
Shift the financial impact of the risk to a third party. Examples: cyber insurance, contracts with liability clauses, outsourcing to an MSSP. Transfers financial loss — does NOT eliminate the risk itself.
Eliminate the risk by stopping the activity that creates it. Most effective treatment but often not feasible as it may conflict with business objectives. Examples: discontinuing a high-risk product, exiting a market.
Critical exam point: Transferring risk (e.g., buying cyber insurance) does NOT transfer accountability. The organization remains accountable for the risk and any consequences — only the financial burden transfers to the insurer. This is especially important for outsourcing scenarios.
The BIA identifies critical business processes, their dependencies, and the maximum time they can be unavailable before unacceptable damage occurs. Recovery objectives are set by the business — not by IT.
Rule: RTO < MTD. Rule: RTO + WRT < MTD. If RTO is set equal to or greater than MTD, recovery is impossible within acceptable bounds — the BIA is flawed.
| Risk Area | Key Considerations | Management Controls |
|---|---|---|
| Vendor Risk Assessment | Evaluate security posture before onboarding; ongoing monitoring throughout relationship | Security questionnaires, SOC 2 reports, ISO 27001 certification review, on-site audits |
| Contractual Controls | Security requirements must be in contracts — not assumed | SLAs, data processing agreements, right to audit clauses, incident notification requirements |
| Data Handling | Third parties processing sensitive data are a major risk; GDPR and other regulations impose requirements | Data processing agreements, data minimization, encryption in transit and at rest |
| Concentration Risk | Over-reliance on a single vendor creates single points of failure | Multi-vendor strategy, escrow arrangements, contingency vendors |
| Accountability Principle | Organizations remain accountable for risk even when outsourced — you can delegate responsibility, not accountability | Governance oversight, regular vendor reviews, incident response integration |
10 CISM-style questions covering Domain 2: Information Security Risk Management.
Mnemonics and mental shortcuts for the most-tested risk management concepts.
Build it from left to right: AV × EF = SLE (one event), then SLE × ARO = ALE (annualized). The chain: Asset Value → × EF → SLE → × ARO → ALE. Control is worth it only if it saves more than it costs: ALE(before) − ALE(after) > Control Cost.
Think MATA. Mitigate = add controls. Accept = document and approve formally (never passive). Transfer = insurance/contract (accountability stays with you). Avoid = stop the activity. Transfer does NOT remove accountability — the org is still responsible for what happens.
RTO = when you're aiming to be back up. MTD = the absolute deadline before catastrophic damage. RTO must ALWAYS be less than MTD — if they're equal, you have no buffer. RPO is separate: it's about data loss, not time to restore. RTO + WRT < MTD.
Inherent risk is the raw exposure before you've done anything. Apply controls → you get residual risk. Residual risk must be formally accepted by management with appropriate authority — never just left hanging. Document it in the risk register.
Qualitative uses subjective ratings (High/Medium/Low, color heat maps) — fast but imprecise. Quantitative uses monetary values and formulas (ALE) — precise but data-hungry. Most real risk programs use both: qualitative to prioritize, quantitative to justify control budgets.
When you use a vendor or buy cyber insurance, you transfer financial exposure or operational responsibility — but the organization remains accountable for the risk and outcomes. Regulators hold you responsible, not your vendor. Always keep governance oversight of outsourced functions.
| Concept | Key Fact |
|---|---|
| SLE formula | SLE = Asset Value × Exposure Factor |
| ALE formula | ALE = SLE × ARO |
| Control cost decision | Implement if: ALE(before) − ALE(after) > Annual Control Cost |
| ARO < 1 | ARO of 0.1 = once every 10 years; 0.5 = once every 2 years |
| Exposure Factor (EF) | % of asset VALUE lost per incident — NOT probability of occurrence |
| Inherent risk | Risk BEFORE controls; Residual risk = risk AFTER controls |
| Risk acceptance | Must be documented + approved by management with appropriate authority |
| Risk transfer | Moves financial impact only; accountability stays with the organization |
| RTO vs RPO | RTO = max downtime; RPO = max data loss (both measured in time) |
| RTO < MTD rule | Always: RTO must be less than MTD; RTO + WRT must also be less than MTD |
| BIA purpose | Identify critical processes and impact of disruption — driven by business, not IT |
| Risk register | Living document: risk description, rating, owner, treatment, residual risk, review date |
| Availability formula | Availability = MTBF ÷ (MTBF + MTTR) |
| Risk assessment first step | Identify and value assets — can't assess risk without knowing what you're protecting |
Click a card to flip it and reveal the answer.
Personalized guidance for Domain 2.
Test your risk management knowledge with full-length CISM practice exams on FlashGenius — scenario-based questions built on the ISACA job practice framework.
Unlock Full Practice Tests on FlashGenius →