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
Evaluating Scenarios for Completeness and Relevance
Checking each scenario
Checking the whole set
| Coverage question | If the answer is no |
|---|---|
| Are all critical processes covered? | Add scenarios for the gaps |
| Are all event types represented? | Add errors, failures and supplier events |
| Are key third parties included? | Add supplier and outsourcing scenarios |
| Do recent incidents map to a scenario? | The set is missing something |
Validating with the business
A scenario is ready when its owner reads it and says “yes, that could happen to us, and here’s what it would cost”. If the owner doesn’t recognise it, it will be mis-rated or ignored.
Example. A practitioner maps the last two years of incidents against the scenario set. Three incidents, all caused by failed changes, have no matching scenario. A “failed change on a core system” scenario is added and rated high.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| BEST way to validate scenarios | Review them with business owners |
| Test of scenario completeness | Compare with incidents, assets and processes |
| When to update scenarios | On significant business, technology or threat change |
| Scenario no owner recognises | Rework it before rating |
In short
- Check each scenario before rating: realistic, specific, business-linked, owned and current.
- Check the set as a whole: does it cover key processes, assets, threat types and third parties?
- Validate scenarios with the business owners who will own them.
- Compare the set with incidents, audit findings and industry data to find gaps.
- Review scenarios when the business, technology or threat landscape changes.
Exam traps
- Rating scenarios before checking whether they're realistic and complete.
- Covering only cyberattacks and missing errors, failures and supplier events.
- Keeping scenarios that no longer match current systems.
- Accepting scenarios no business owner recognises.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Checking each scenario
1 / 7