This article provides an overview of the risk scenarios within the COBIT 5 for risk management framework.
A risk scenario is defined as the description of a possible IT risk event, that when it occurs, will have an uncertain negative or positive impact on achieving business goals and objectives.
They are an effective tool in helping to ask the right questions and to prepare for future uncertainty. They help to expanding thinking, uncover inevitable or near-inevitable futures and protect against inhibitors to free flow of debate.
An IT risk scenario should include the following components:
- Actors – including things like internal (staff, contractor), external (competitor, outsider, business partner, regulator and market).
- Threat Types – including things like malicious, accidental/error, failure, natural and external requirement.
- Events – including things like disclosure, interruption, modification, theft, destruction, ineffective design, ineffective execution, rules and regulation and inappropriate use.
- Assets/Resources – including things like people and organisation, process, infrastructure (facilities), IT infrastructure, information and applications.
- Time – including things like duration, timing of occurrence (critical and non-critical) and timing to detect.
When a risk scenario materialises, a loss event occurs. The loss event is triggered by a threat event (threat type plus event). The frequency of the threat event is influenced by a vulnerability. The vulnerability is usually a state; it can be decreased/increased by vulnerability events i.e. controls strength of by threat strength.
There are 2 ways to derive risk scenarios:
- A top down approach – one based on the business objectives and the identification of those risk scenarios most likely to impact them.
- A bottom up approach – one based on a generic list risk scenarios (provided by COBIT 5) which are refined/customised as required to reflect the business.
Both approaches are complementary and should be used in collaboration to gain the best set of risk scenarios.
Here is an example of effectively combining both approaches:
- Start with a list of generic risk scenarios to produce an initial set of likely risk scenarios applicable for the business.
- Validate and further refine the initial list against business objectives.
- Categorise them in line with the criticality of the business.
- Record the validated list in a system (risk register), available for next stage risk analysis and for future iterations of risk scenario definition.
Once risk scenarios are approved/produced, they are risk assessed to determine risk frequency and impact – risk factors help in assessing this.
They will help decision makers to make better informed decisions on risk responses, making risk responses an extremely effective and valuable tool in IT risk management.
For more information please contact Morland-Austin at firstname.lastname@example.org.