Topics in this domain
- IT Risk Events, Loss Types and Business Outcomes
- Threat Sources, Actors and Motivations
- The Changing Threat Landscape and Threat Modelling
- Vulnerabilities, Control Deficiencies and Risk Conditions
- Identifying Internal and External Risk Factors
- Building IT Risk Scenarios
- Evaluating Scenarios for Completeness and Relevance
- Common Risk Scenario Errors
- Risk Assessment Concepts and Standards
- Qualitative, Semi-Quantitative and Quantitative Analysis
- Quantitative Methods: ALE, FAIR and Monte Carlo
- Risk Analysis Techniques: Bow-Tie, Fault Tree, Event Tree and Delphi
- Choosing a Consistent Assessment Methodology
- Translating Technical Events into Business Impact
- Business Impact Analysis for Risk Prioritisation
- Inherent and Residual Risk
- Evaluating Risk Against Business Objectives and Appetite
- Creating and Maintaining the IT Risk Register
- Using the Risk Register to Support Decisions
Common Risk Scenario Errors
Weak versus better
The five common errors
| Error | Fix |
|---|---|
| Too vague | Add the actor, event, asset and consequence |
| Too technical | State the business outcome |
| Only worst case | Add a realistic severe case |
| Too many, overlapping | Group similar scenarios |
| Several events in one | Split into separate scenarios |
Realistic versus worst case
If every scenario is “total loss of all systems”, everything rates critical and nothing can be prioritised. Assess the realistic severe case alongside the extreme, so ratings reflect what’s actually likely.
Example. “All data centres destroyed” was rated critical and then ignored as unthinkable. Replacing it with “regional flood closes the main data centre for 3 days” produced a rating management acted on: a tested failover plan.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Scenario reads “cyber risk” | Too vague; make it specific |
| Scenario is a CVE number | It’s a vulnerability; describe the business event |
| All scenarios rate critical | Scenarios are too extreme; use realistic cases |
| Scenario covers several events | Split it |
In short
- Vague scenarios such as 'cyber risk' can't be rated or owned.
- Purely technical scenarios (a CVE number) describe a cause, not a business risk.
- Worst-case-only scenarios exaggerate; use realistic severe cases as well.
- Too many scenarios dilute attention; group and focus on what matters.
- Scenarios must be refreshed when systems and threats change.
Exam traps
- Arguing about a rating when the real problem is the scenario wording.
- Including only catastrophic scenarios, which makes everything look critical.
- Writing scenarios as vulnerabilities rather than events with consequences.
- Combining several different events into one scenario.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Weak versus better
1 / 7