If you are an IT expert and are asked to estimate, you may have experienced the frustration of having to estimate based on poorly formulated scenarios. If you are a risk manager and have had to build a risk register, you may also have experienced that it can be tiring to build a consistent and comprehensive risk register.
Many companies have or are trying to build good risk registers. We see many honest but poorly executed attempts, which is why we saw a great need for an article like this.
What is a risk scenario?
A risk scenario is a prosaic description of a future event that may result in losses for the company. A collection of these risk scenarios is what we understand as a risk register.
The prosaic description must meet several minimum requirements to be a good risk scenario. It must contain enough information to make an unambiguous estimate. If the scenario does not meet the minimum requirements, you will experience problems throughout the analysis.
Degree of detail in the scenario
Risk scenarios can vary in detail, depending on the use and need of the risk assessment. A narrow scenario describes a detailed incident, a detailed threat (incl. a very specific description of the sequence of events and attack technique) and a detailed description of the consequence of the incident.
However, if you want an overview of many different risks, then you must work with broader scenarios. This will help you see the risk picture as a whole and get a starting point for carrying out more specific analyzes in certain areas.
The structure of the scenario
What information must a risk scenario contain?
A risk scenario must contain a description of a potential negative incident, incl. the consequence one imagines the incident could have. A risk scenario must consist of the following: Threat + Actor + Asset + Consequence.
Let’s look at three examples:
- “Insufficient patch level on server A”
- “Massive data breach”
- “Incident where an external malicious person carries out a cyber-attack using the phishing technique, which causes sensitive personal data in the CRM system to lose its confidentiality.”
Can you guess which of these examples is a good risk scenario? Let’s look at them one at a time.
Example 1 – “Insufficient patch level on server A”
This example does not meet the requirements to be a risk scenario. It describes a vulnerability (not a threat) on server A and lacks both a threat, actor and consequence.
The example describes a state of the asset (server A) that could result in an event if exploited, but you will not be able to answer the question, “What is the possible loss for insufficient patch level on server A?”
Example 2 – “Extensive data breach”
Definitely closer to being a risk scenario. But still not good enough. It describes a consequence but still lacks an actor, asset and threat.
We do not know anything about where the data breach will occur and which data will be affected. Is it anonymised logs of physical access cards, or is it customer data with references to personally sensitive data for each customer? There is a big difference in how a respondent assesses the consequence depending on whether it’s one or the other.
Example 3 – “Incident where an external malicious person carries out a cyber-attack using the phishing technique“
A Cyber attach with the phishing technique causes sensitive personal data in the CRM system to lose its confidentiality.
Now, we’re getting there. The scenario meets the requirements:
- Actor = External malicious actor
- Active = Sensitive personal data in the CRM system
- Threat = Cyber-attack using the phishing technique
- Consequence = Lost confidentiality of the sensitive personal data in the CRM system
Procedure for building scenarios
There are many ways to work with your scenarios. We would suggest the following 6-step procedure.
- Make a list of your assets. Only include those assets that you intuitively know have value for your business.
- Make a list of your threats. Don’t think about what is possible, but more about what is likely.
- Connect your assets with your threats and specify the consequence of the threat on your asset.
- Remove irrelevant combinations and combine scenarios where one threat has the same consequence across assets.
- Formulate scenarios in clear and actionable language using expressions such as “Incident where [INSERT THREAT] affects [INSERT ACTIVE] in such a way that [INSERT CONSEQUENCE].”
- Work through the formulations so that the scenarios become identifiable across the company.
Summary
A risk scenario must contain sufficient information to answer questions about possible losses and their probability. The minimum requirement for scenarios is that they must describe what will be hit and with what consequence it will be hit. A good scenario consists of Threat + Actor + Asset + Consequence.
If we increase the level of detail for assets and/or threats, the number of scenarios increases drastically. It’s about balance. We should only create scenarios as long as we can make a proper and thorough analysis. You can always decompose your scenarios further, but you must set the limit somewhere so you don’t end up with an endless list of risk scenarios that you don’t have the resources to analyse.
