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
Building IT Risk Scenarios
Why scenarios
“Cyber risk” can’t be rated or owned. “A criminal group phishes finance staff and diverts a 500,000 payment” can. Risk scenarios make risk concrete enough for the business to judge likelihood and impact and decide what to do.
Anatomy of a scenario
Top-down and bottom-up
Example. Top-down, the sales director asks what could stop the online store at peak season. Bottom-up, the security team lists threats to the web platform. Together they produce eight scenarios, each linked to the peak-season objective.
Building them well
- Involve business owners and technical experts together.
- Use generic scenario libraries only as a starting point.
- Keep the number manageable, focused on what matters.
- Link each scenario to an objective and an owner.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| PRIMARY benefit of risk scenarios | Make risk concrete for business decisions |
| BEST way to build scenarios | Workshops with business and technical stakeholders |
| Top-down approach starts with | Business objectives |
| Using another firm’s scenario list | Tailor it to this organisation |
In short
- A risk scenario describes an actor, a threat event, the asset affected, the consequence and the timing or context.
- Scenarios turn abstract risk into concrete stories that owners can recognise, rate and own.
- Top-down scenarios start from business objectives; bottom-up scenarios start from assets and threats.
- Use both approaches: top-down for relevance, bottom-up for realism.
- Build scenarios with business and technical stakeholders together.
- Generic risk lists from other organisations are a starting point, not a substitute.
Exam traps
- Writing one-word scenarios such as 'hackers' or 'cyber'.
- Building scenarios only with the IT team.
- Copying another organisation's scenario list without tailoring.
- Producing hundreds of technical scenarios with no business link.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Anatomy of a scenario
Top-down and bottom-up
ExampleTop-down, the sales director asks what could stop the online store at peak season. Bottom-up, the security team lists threats to the web platform. Together they produce eight scenarios, each linked to the peak-season objective.
1 / 8