ISO 27001 Implementation Guide
Identifying risks and adopting risk-based thinking for ISO 27001 risk management
Learn how to adopt a risk-based mindset and identify your risks for your ISO 27001 risk management documentation
In this article, we will show you how to adopt a risk-based mindset so you can effectively identify risks for your ISO 27001 risk management documentation. We will cover:
Reading time: 7 minutes
What is risk-based thinking
ISO 27000 defines risk as “the effect of uncertainty on objectives”, where “effect” is the deviation from what is expected. In plain English and in the context of ISO 27001, risk can be defined as “uncertainty that can have an impact on your objective of keeping your information secure”.
Sometimes this uncertainty may have a positive result, in which case the risk is also an opportunity. To keep things simple, we define risks and opportunities as follows:
- Opportunity: an uncertainty that will likely have a positive impact if it occurs.
- Risk: an uncertainty that will likely have a negative impact if it occurs.
“Risk-based thinking” in ISO standards refers to the conscious evaluation of uncertainty when making everyday decisions and changes to the way you work, the product you offer, etc, and the conscious evaluation of the impact this uncertainty might have on your objectives if the uncertain event occurs.
In other words, you should be thinking about risks and opportunities all the time so you can manage them to your advantage.
Your ISO 27001 risk management framework
“The organisation shall retain documented information about the information security risk assessment process.” – Buy the standard!
This means you must have a process for assessing risk, and it must be documented. In other words, you must have a Risk Management Framework that is written down somewhere. Some call it the Risk Policy, Risk Management Policy, Risk Procedure, or some other variation- all meaning the same. We like to call it a framework because what you’ll be producing will include a policy, a procedure describing a process and a spreadsheet for the register and scoring method.
Over the next few sections, we’ll show you how to develop your own Risk Management Framework based on a straightforward 5-step process:
- Identify the risks
- Assess the risks
- Prioritise and decide what actions you’ll take to mitigate the risks (i.e. determine the risk treatment plan in ISO language)
- Implement the risk treatment plan
- Communicate to employees how the plan might affect the way they do their work, monitor if the plan was effective and review if need be.
If you haven’t already created your asset register, we suggest you read this article and create an asset register prior to following the rest of this article.
Identifying your risks
The way you go about identifying risks is not exactly prescribed by the standard. ISO 27005 (the guidelines for information security risk management) proposes two approaches: the scenario-based approach and the asset-threat-vulnerability approach.
The scenario-based approach is more instinctive and probably easier to understand. It consists, largely, of getting people together, thinking of various scenarios and brainstorming on what could go wrong. While this is an easy method to understand, in practice, people who have never done this before will pretty quickly come up with around a dozen risks and then run out of ideas. While there isn’t a target number of risks you should come up with, twelve isn’t enough!
The alternative asset-threat-vulnerability approach is more difficult to understand but is more thorough and will likely help you identify risks you wouldn’t have thought of otherwise.
The underlying concept of this approach is that risks can be identified and assessed through an evaluation of assets, threats, and vulnerabilities. A threat exploits a vulnerability to compromise the confidentially, integrity and/or availability of an item of information, which is referred to in the method as an “asset”.
In other words, according to the asset-threat-vulnerability approach, assets (including business activities, processes, and people), combined with threats & vulnerabilities, is where risks come from.
To get you started quickly in identifying the risks that are relevant to you, we have used this second approach to build an example Risk Register template. You can use this template as an example, to help you define the risks that apply to you based on the types of assets you have and the activities you undertake as an organisation.
Once you’ve identified the risks that apply to you, this template can become your official Risk Register for certification. You’ll notice that a number of columns on the right of the risks are hidden. You will use those in the next steps to document the controls you have in place, assess the risks, and determine how you will handle each risk. Please ignore them for now.
Asessing your risks
You’ll find the requirements below in clause 6.1.2 in relation to having an information security risk assessment process that:
a) ensures that repeated information security risk assessments produce consistent, valid and comparable results
b) analyses the information security risks:
- assess the potential consequences that would result if the risks identified …were to materialise
- assess the realistic likelihood of the occurrence of the risks identified and
- determine the levels of risk
You’ll notice that, as with the risk identification approach, it doesn’t actually specify what risk criteria are or how you meet these requirements. Watch the video below to understand what you need to achieve to meet the requirements.
After watching the video, download the Risk Consequences and Likelihood scales and the 5×5 matrix example template you’ll need to define your own consequences and likelihood scales so the scores are meaningful to everyone in your organisation and the results are the same no matter who does the risk assessment.
Accepting or treating risks
You’ll find the requirements below in clause 6.1.2 in relation to having an information security risk assessment process that establishes and maintains information security risk criteria that include:
- the risk acceptance criteria, and
- criteria for performing information security risk assessments
In plain English, this means you need to have a way to determine what you will do with each risk you’ve scored (point 1 above); and a way to determine WHEN you do you a risk assessment (point 2).
The risk acceptance criteria are already defined for you in the Risk Consequences and Likelihood Scales spreadsheet and look like this:
Risk acceptance criteria and risk treatment:
The values here are based on the scores according to the table below.
5 x 5 risk scoring matrix:
Regarding the second requirement of having a way to determine WHEN to do a risk assessment, this is also documented for you in the Risk Management Framework document you’ll find in the “Writing documentation” step.
Assessing risks is not a one-off exercise as part of implementing your ISMS. It’s on-going and will need to be done at a minimum annually or when you change the way you work, on-board new suppliers, new legislation is enacted, etc. You can obviously change any of this to suit your situation if you wish.
You should now have a Risk Register which contains:
- a list of all the risks to the confidentiality, integrity and availability of your information assets
- the controls you already have in place to either
- reduce the impact (or consequences) if the risk does occur
- reduce the likelihood of the risk occurring
- or do both
- a score against each risk that considers the consequences for confidentiality, integrity and availability of your information assets
- a score that is colour coded according to the 5×5 matrix shown in the previous step
- an owner for each risk
If you don’t have that or are not confident what you have is correct, make an appointment with your ISO consultant to discuss. They’ll make sure you’re on the right track and you don’t waste time – click here to arrange a convenient date/time.
The work you’ve done so far meets all the requirements laid out in clause 6.1.2, except 6.1.2 e) 2):
2) prioritize the analysed risks for risk treatment.
That requirement is already documented for you in the Risk Management Framework– it goes like this:
Risks are prioritised based on:
- Their assessment score
- The complexity of the chosen solution
- The resources required
- Whether the work can be done as part of an existing project