Overview
Domain 2 covers how a risk practitioner identifies and analyzes risk. Part A, risk identification, deals with risk events, threat modeling and the threat landscape, vulnerability management, and building risk scenarios. Part B, risk analysis, deals with assessment concepts and standards, business impact analysis (BIA), the risk register, analysis methodologies, and the difference between inherent and residual risk.
The domain sits between governance and response. Domain 1 tells you what the enterprise values, who owns what and how much risk it will accept. Domain 2 measures actual exposure against those reference points. Domain 3 then decides what to do about the gap. If the assessment is wrong because it is too technical, too generic or rated on the wrong basis, every response built on it is wrong too. That is why the exam keeps returning to the quality of the analysis rather than the tools used to produce it.
How it's tested
Questions in this domain give you assessment inputs, such as a scan result, a threat report, a BIA finding or a register entry, and ask what they mean or what should happen next. Expect some calculation questions on annualized loss expectancy. Expect more questions where you must recognize that an assessment is incomplete, rated on the wrong basis or missing business input.
-
Severity is not risk
A technical severity score is given and you must work out the actual risk by adding asset value, exposure, likelihood and existing controls.
-
What is missing?
An assessment or scenario is described and you must identify the gap, often business impact, ownership, or validation with stakeholders.
-
Calculate and compare
You are given asset value, exposure factor and annualized rate of occurrence, and must calculate single or annualized loss expectancy or compare it with a control's cost.
A threat intelligence feed warns of a new ransomware group targeting your sector. Asked for the BEST next step, skip answers that buy a tool or patch everything. Intelligence is an input to assessment. You update the relevant risk scenarios, check the likelihood and impact against current controls, and adjust the register so owners can decide. Assess first, then respond.
Subtopics 9
Official subtopics from the ISACA outline, in outline order.
2.A.1 Risk EventsOccurrences, or changes in circumstances, that affect the achievement of objectives.
- What it means
- A risk event is something that happens, or could happen, with an effect on objectives: an outage, a data leak, a supplier failure, a regulatory change. Loss events have caused harm, and near misses could have.
- What to understand
- Collecting and analyzing events, including near misses, gives evidence for likelihood estimates and exposes weak controls. Events should be linked back to risk scenarios and the register so that experience updates the assessment.
- How it shows up
- An incident or near miss is described, and you are asked what the risk practitioner should do with that information, for example update the scenario and register, or review related controls.
- Common confusion
- Ignoring near misses because no loss occurred. They are often the cheapest evidence you will get that a control is failing.
2.A.2 Threat Modeling and Threat LandscapeWho or what could cause harm, how they would do it, and how that picture is changing.
- What it means
- Threat modeling systematically identifies how a system or process could be attacked or fail, using methods such as STRIDE or attack trees. The threat landscape is the current external picture of threat actors, their motives, capabilities and common techniques.
- What to understand
- A threat is a potential cause of harm, not the harm itself. Threat modeling is most valuable early in design, and the threat landscape must be monitored because yesterday's assessment may understate today's likelihood.
- How it shows up
- Questions ask when threat modeling gives the most value, usually during design, or how new threat intelligence should change an existing assessment.
- Common confusion
- Using threat, vulnerability and risk interchangeably. A threat exploits a vulnerability, and risk is the likelihood and impact of that happening to something of value.
2.A.3 Vulnerability ManagementFinding, rating, fixing and verifying weaknesses on an ongoing basis.
- What it means
- Vulnerability management is the continuous cycle of discovering weaknesses in technology, processes and people, prioritizing them, remediating or mitigating them, and confirming the fix worked.
- What to understand
- Prioritization should reflect risk, not just the technical severity score. A severity score such as CVSS describes how bad a flaw is in general. It does not include your asset's business value, exposure or compensating controls.
- How it shows up
- You see two or more findings with different severity scores on systems of different business importance and must choose which to address first.
- Common confusion
- Treating the highest CVSS score as the highest risk regardless of where the flaw sits or what it protects.
2.A.4 Risk Scenario Development and EvaluationWriting realistic stories of how a risk could happen and what it would cost.
- What it means
- A risk scenario describes a plausible event that would affect objectives, typically naming the actor, the threat type, the event, the asset or resource affected, and timing. Scenarios can be built top-down from business objectives or bottom-up from generic threat and event lists.
- What to understand
- Good scenarios are specific, plausible and tied to business impact, and they are validated with the business owners who understand the consequences. Combining top-down and bottom-up approaches reduces blind spots.
- How it shows up
- A set of scenarios is described, and you must identify the weakness, such as missing business input, unrealistic events or no owner, or choose the BEST approach to building them.
- Common confusion
- Writing scenarios as lists of technical threats with no link to a business consequence, which makes them impossible to prioritize.
2.B.1 Risk Assessment Concepts and StandardsThe process and vocabulary for identifying, analyzing and evaluating risk.
- What it means
- Risk assessment generally moves from identification to analysis, estimating likelihood and impact, and then to evaluation, comparing results with appetite and tolerance. Standards such as ISO 31000, ISO/IEC 27005 and NIST SP 800-30 describe this process.
- What to understand
- Assessment should be consistent, repeatable and use criteria agreed in advance, so that results can be compared and aggregated. Its scope and the assumptions behind it must be documented.
- How it shows up
- Questions ask what should be defined before an assessment starts, such as scope, criteria and stakeholders, or why two business units' results cannot be compared.
- Common confusion
- Skipping the evaluation step. Analysis tells you how big a risk is. Evaluation tells you whether that size is acceptable.
2.B.2 Business Impact Analysis (BIA)Working out how badly a disruption to each process would hurt the business over time.
- What it means
- A BIA identifies critical business processes, their dependencies, and how financial, operational, legal and reputational impact grows the longer they are disrupted. It sets recovery requirements such as the maximum tolerable downtime, recovery time objective (RTO) and recovery point objective (RPO).
- What to understand
- The BIA focuses on the impact of disruption whatever the cause. It does not estimate likelihood. Business process owners must provide its input, because only they know what an outage actually costs.
- How it shows up
- Questions ask who should provide BIA input, what the BIA determines, or what is wrong when IT sets recovery priorities without one.
- Common confusion
- Treating the BIA as a full risk assessment. It measures consequences of disruption but does not weigh how likely each cause is.
2.B.3 Risk RegisterThe central, living record of identified risks and how they are being managed.
- What it means
- A risk register typically records each risk's description, scenario, owner, inherent and residual ratings, existing controls, chosen response, action plan and status, and related indicators.
- What to understand
- The register only has value if it is current, has an owner for every risk, and feeds the enterprise risk profile. It should be updated when events, assessments or business changes occur, not only at an annual review.
- How it shows up
- A register is described with gaps such as no owners, stale ratings or IT-only entries, and you must pick the MOST important fix or explain what it is used for.
- Common confusion
- Treating the register as a compliance artifact to be completed once a year rather than as the working record behind decisions.
2.B.4 Risk Analysis MethodologiesQualitative, quantitative and semi-quantitative ways of sizing risk.
- What it means
- Qualitative analysis uses descriptive scales such as high, medium and low. Quantitative analysis uses monetary values and probabilities, for example single loss expectancy (SLE) equals asset value times exposure factor, and annualized loss expectancy (ALE) equals SLE times annualized rate of occurrence. Semi-quantitative analysis assigns numbers to qualitative scales. Techniques include Monte Carlo simulation, fault tree analysis and bow-tie analysis.
- What to understand
- No method is best in every case. Quantitative results are only as good as their data, and qualitative methods are faster and work well when data is thin. Choose the method based on the decision being made and the data available.
- How it shows up
- Expect ALE calculations, comparisons of a control's annual cost with the ALE reduction it gives, and questions on which method suits a situation with limited historical data.
- Common confusion
- Assuming quantitative is always more accurate. A precise number built on guessed inputs gives false confidence.
2.B.5 Inherent and Residual RiskRisk before controls, and risk after them.
- What it means
- Inherent risk is the exposure that exists before any controls or responses are applied. Residual risk is what remains once current controls and responses are taken into account.
- What to understand
- Residual risk is what gets compared with appetite and tolerance to decide whether further response is needed. Inherent risk shows how much the enterprise depends on its controls, which helps decide which controls need the most monitoring.
- How it shows up
- Questions ask which rating should be compared with appetite, or what a large gap between inherent and residual risk tells you about control dependence.
- Common confusion
- Comparing inherent risk with appetite and concluding that well-controlled risks need further treatment.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Single loss expectancy (SLE)
The expected loss from one occurrence of an event.
- Remember
- SLE = asset value (AV) times exposure factor (EF). Example: a $200,000 asset with a 25% exposure factor gives an SLE of $50,000.
- Tested as
- The first step in quantitative calculations.
- Trap
- Using the full asset value when only part of it is lost.
-
Annualized loss expectancy (ALE)
The expected loss per year from a given risk.
- Remember
- ALE = SLE times annualized rate of occurrence (ARO). An SLE of $50,000 with an event expected once every five years (ARO 0.2) gives an ALE of $10,000.
- Tested as
- Used to judge whether a control's annual cost is justified.
- Trap
- Writing ARO as 5 instead of 0.2 for an event that happens once every five years.
-
Control cost justification
A control is financially justified when the ALE reduction it delivers is greater than its annual cost.
- Remember
- Value of the control = ALE before minus ALE after minus annual cost of the control.
- Tested as
- Appears in cost-benefit scenarios.
- Trap
- Comparing the control's cost with the full ALE rather than with the reduction it achieves.
-
Inherent vs. residual risk
Risk before controls compared with risk remaining after them.
- Remember
- Residual risk is compared with appetite.
- Tested as
- Decides whether further treatment is needed.
- Trap
- Using inherent risk to decide treatment for risks that are already well controlled.
-
Risk scenario components
A complete scenario names who or what causes it, what kind of threat it is, what happens, what is affected, and when.
- Remember
- Actor, threat type, event, asset or resource, and time.
- Tested as
- Used to judge whether a scenario is usable.
- Trap
- Accepting a scenario that has no business consequence.
-
Top-down vs. bottom-up scenarios
Top-down starts from business objectives and asks what could threaten them. Bottom-up starts from generic threats and events and asks which apply.
- Remember
- Using both together gives the best coverage.
- Tested as
- Questions about the BEST approach to building scenarios.
- Trap
- Relying only on generic lists, which misses business-specific risks.
-
BIA outputs
Critical processes, dependencies, impact over time, and recovery requirements.
- Remember
- Maximum tolerable downtime, RTO and RPO come from the BIA, and business owners supply the input.
- Tested as
- Links to resilience in Domains 1 and 4.
- Trap
- Letting IT set recovery priorities without business input.
-
RTO vs. RPO
RTO is how quickly a process or system must be restored. RPO is how much data loss, measured in time, is acceptable.
- Remember
- RTO is about time to recover. RPO is about the age of the last usable data, and it drives backup frequency.
- Tested as
- Commonly confused pair.
- Trap
- Thinking a shorter RPO means faster recovery. It means more frequent backups or replication.
-
CVSS vs. risk
CVSS rates a vulnerability's technical severity. Risk adds likelihood in your environment and impact on your assets.
- Remember
- Severity is an input to risk, not a substitute for it.
- Tested as
- Vulnerability prioritization questions.
- Trap
- Fixing the highest CVSS score first regardless of where the vulnerability sits.
-
Fault tree vs. event tree
Fault tree analysis works backward from an undesired outcome to its causes. Event tree analysis works forward from an initiating event to its possible outcomes.
- Remember
- Fault tree is deductive and top-down. Event tree is inductive and forward.
- Tested as
- Methodology-selection questions.
- Trap
- Swapping the direction of the two.
-
Risk register
The central record of identified risks with their owners, ratings, responses and status.
- Remember
- Every entry needs an owner, and the register should be kept current and feed the risk profile.
- Tested as
- Questions on register quality and use.
- Trap
- Treating it as a one-off compliance document.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Qualitative vs. quantitative vs. semi-quantitative analysis
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Qualitative | Ratings on descriptive scales such as high, medium and low | Fast and easy to explain, and works with limited data, but subjective | Dismissing it as unprofessional when data is scarce |
| Quantitative | Monetary values and probabilities, such as SLE and ALE | Supports cost-benefit decisions, but depends heavily on data quality | Trusting precise numbers built on guessed inputs |
| Semi-quantitative | Numeric scores assigned to qualitative scales | Allows ranking and aggregation without full monetary data | Treating the scores as true monetary or probability values |
BIA vs. risk assessment
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Business impact analysis | How disruption to each process affects the business over time | Focuses on impact regardless of cause. Does not estimate likelihood | Using it alone to prioritize all risk |
| Risk assessment | Identifies, analyzes and evaluates specific risks | Combines likelihood and impact for specific scenarios | Doing it without BIA input on what matters most |
Threat vs. vulnerability vs. risk
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Threat | A potential cause of harm, such as an attacker, a failure or a natural event | The source of potential harm | Calling a threat a risk |
| Vulnerability | A weakness a threat could exploit | The opening that allows the harm | Rating it in isolation from the asset it affects |
| Risk | The likelihood and impact of a threat exploiting a vulnerability to affect objectives | The combination, measured against business impact | Equating it with severity scores |
RTO vs. RPO vs. maximum tolerable downtime
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Maximum tolerable downtime | The longest a process can be unavailable before the damage is unacceptable | A business limit set through the BIA | Setting RTO longer than this limit |
| RTO | The target time to restore a process or system | Must be shorter than the maximum tolerable downtime | Confusing it with RPO |
| RPO | The acceptable data loss measured back in time | Drives how often backups or replication happen | Thinking it governs how fast systems come back |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Highest score first
- What candidates pick
- Remediate the vulnerability with the highest CVSS score first.
- Why it looks right
- The score is objective, standardized and easy to defend.
- Why it's wrong
- Severity ignores the asset's business value, its exposure and existing controls, which together decide actual risk.
Clue to watch for If the scenario tells you what the affected systems do or who can reach them, that information is there to change the priority.
-
Treat before assessing
- What candidates pick
- Implement a control as soon as a new threat or vulnerability is reported.
- Why it looks right
- It feels proactive and reduces exposure quickly.
- Why it's wrong
- Without assessing likelihood, impact and existing controls, you may spend money on a risk that is already within appetite or miss a bigger one.
Clue to watch for New information arriving, such as threat intelligence, an audit finding or a scan result, usually calls for assessment or updating the register first.
-
Precision as accuracy
- What candidates pick
- The quantitative method because it gives exact numbers.
- Why it looks right
- Numbers look objective and support cost-benefit discussions.
- Why it's wrong
- With little historical data the inputs are guesses, so the precision misleads. A structured qualitative method can be the better choice.
Clue to watch for The scenario mentions limited data, a new technology or the need for a quick decision.
-
BIA as full risk assessment
- What candidates pick
- Use the BIA results alone to rank all risks.
- Why it looks right
- The BIA is thorough and has business input.
- Why it's wrong
- The BIA measures consequences of disruption but not likelihood, so it cannot rank risks on its own.
Clue to watch for The question asks about likelihood, threats or which risk to treat first.
-
Inherent rating drives treatment
- What candidates pick
- Add controls to a risk because its inherent rating is high.
- Why it looks right
- High inherent risk sounds dangerous.
- Why it's wrong
- If existing controls bring residual risk within appetite, more treatment may not be justified. The priority is keeping those controls effective.
Clue to watch for The scenario gives both inherent and residual ratings. Compare the residual one with appetite.
-
IT-written scenarios
- What candidates pick
- Accept risk scenarios written entirely by the IT or security team.
- Why it looks right
- They understand the technology and threats best.
- Why it's wrong
- Without business input the scenarios miss real impact and cannot be rated or owned properly.
Clue to watch for Look for missing validation with business process owners or senior management.
-
ARO written as frequency
- What candidates pick
- Use ARO = 5 for an event expected once every five years.
- Why it looks right
- The number five is in the question.
- Why it's wrong
- ARO is occurrences per year, so once every five years is 0.2. The wrong value overstates ALE by 25 times.
Clue to watch for Phrases such as 'once every' mean you need to invert the number.
Answer framework
Use these steps to reason through any Domain 2 assessment scenario before choosing an answer.
- Identify the asset or process at stake and its business value, using BIA results or owner input rather than technical judgment alone.
- Separate the threat, the vulnerability and the existing controls, and check that the scenario describes a plausible event with a business consequence.
- Estimate likelihood and impact with a method that fits the available data, calculating SLE and ALE when monetary inputs are given.
- Determine residual risk after current controls and compare it with the enterprise's risk appetite and tolerance thresholds.
- Record the result in the risk register with an owner, and choose answers that update or validate the assessment before any treatment is applied.
Practice question
Want more like this? The CRISC practice test has questions for every domain.
Checklist
0 of 14
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Begin with vocabulary: threat, vulnerability, risk, inherent and residual. Every other topic in this domain uses these terms precisely, and many wrong answers are built on mixing them up.
Next, practice the quantitative formulas until they are automatic. Work through SLE, ALE and control cost-benefit with a few made-up numbers, and pay particular attention to converting frequencies into an ARO. These are easy marks that candidates still drop through arithmetic slips.
Then study risk scenarios and the BIA together. Both are about connecting technical events to business consequences, which is the skill the exam rewards most. Candidates commonly underestimate the BIA. Learn exactly what it produces, who supplies the input, and why it measures impact without likelihood.
Finish with the risk register and analysis methodologies, focusing on when each method fits rather than memorizing technique names.
Afterwards, practice scenario questions that combine Domain 2 with Domain 3, since an assessment always leads into a response decision. Check that each answer you choose assesses before it treats.
FAQ
How much of the CRISC exam is Domain 2?
Risk Assessment is 22% of the exam under the outline effective 3 November 2025.
Will there be calculation questions?
Expect some. You should be comfortable with single loss expectancy, annualized loss expectancy and comparing a control's annual cost with the loss reduction it gives. Calculation is a smaller share than scenario reasoning.
What is the difference between inherent and residual risk?
Inherent risk is exposure before controls, and residual risk is what remains after them. Residual risk is compared with appetite to decide whether more treatment is needed.
Is a BIA part of the risk assessment?
It is a key input, not a replacement. The BIA tells you which processes matter most and how impact grows over time, but it does not estimate how likely each cause of disruption is.
Do I need to know specific threat modeling methods?
Know what threat modeling is for, when it adds the most value, and recognize common approaches such as STRIDE and attack trees. The exam focuses on applying the idea rather than the mechanics of any single method.
Which standards should I know for risk assessment?
Recognize ISO 31000 for general risk management, ISO/IEC 27005 for information security risk, and NIST SP 800-30 for risk assessments. Understand their purpose rather than their clause structure.
How does Domain 2 relate to Domain 3?
Domain 2 produces the risk ratings, and Domain 3 decides what to do about them. An error in assessment, such as using severity in place of risk, carries straight into a wrong response decision.
Other Cybersecurity certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- CISM (Certified Information Security Manager) Same subject: Domain 2: Information Security Risk Management (20%)
- CISSP Same subject: Domain 1: Security and Risk Management (16%)
- CompTIA Cybersecurity Analyst+ Study guide
- Microsoft Security Operations Analyst Associate Study guide
- Certified Ethical Hacker Study guide
- Penetration Tester Study guide
- Systems Security Certified Practitioner Study guide
- CompTIA PenTest+ Study guide
- CompTIA SecurityX (CASP+) Study guide
- Azure Security Engineer Associate Study guide
- CompTIA Security+ Study guide
- Certified Information Systems Auditor Study guide
- Certified Cloud Security Professional Study guide
Test your Domain 2 knowledge
You have covered how threats, vulnerabilities and business impact combine into risk ratings, and why severity is not risk. Test whether you can rate and prioritize correctly under exam conditions.