A basic risk management method for information security

One of the requirements for good information security is to have a method for risk identification and assessment. This article describes one simple and practical method that can be used by any organisation. This page is part of a series on ISO 27001 controls and our free ISO27001 and GDPR templates.

ISO 27001 High-Level Structure is all about risk management

Before diving into the risk assessment method itself, it helps to understand where risk management sits within the broader ISO 27001 framework. ISO 27001 follows the High-Level Structure (HLS), which organises the standard into chapters 4 through 10. These chapters map onto the well-known Plan-Do-Check-Act (PDCA) cycle:

Risk assessment is described in detail in Chapter 6: Planning. Section 6.1.2 of ISO 27001 defines the exact criteria your risk assessment method must meet. In essence, the standard requires you to identify information security risks, analyse their likelihood and impact, evaluate and prioritise them, and select appropriate treatment options. The method described in this article satisfies these requirements. For a more detailed walkthrough of the full Harmonized Structure, see our article on The ISO 27001 Harmonized Structure, or watch our free video course on SieuwertExplains, the ICT Institute YouTube channel with detailed courses on ISO 27001 implementation.

Why risk assessment is important

If you want to do information security right, you should not blindly implement every security measure available. Instead, you need to understand what assets you want to protect, identify the risks to those assets, and assess the importance of each risk.  Only then should you begin treating the most significant risks by implementing controls.

A structured risk assessment ensures that the right security measures are taken: measures that deliver real value, rather than measures that are simply easy to implement. Organisations that do not use such a risk assessment approach tend to take many similar measures in areas that they know well (e.g. IT infrastructure). They risk ignoring other areas that they are not aware off.
Risk management is a core element of the ISO 27001 standard. If you want to be compliant with ISO 27001 (or the similar standard Security Verified) you must adopt a formal risk management method. Compliance platforms such as Vanta can help streamline this process by tracking your risk register alongside other compliance activities.

Basic risk management process

There are many risk management methods (see for instance the iso27k FAQ on risk management for an overview). This article provides one method that works well in practice, and is based on an agile way of working. If you haven’t chosen a method yet, feel free to adopt this one. If you have a different method that works well, keep using that method.

The risk assessment workshop

In this method, risks are identified in a workshop, where 3-10 people from all parts of the organisation participate. The workshop is typically led by the information security team. It is important that the workshop is representative, with people from different parts of the organisation present. People from different parts will have different perspectives and this ensures all types of risks will be identified.

• Each participant individually writes down 3 to 10 risks, each on a separate sticky note. At this stage, participants work individually without discussing their ideas.
• Participants take turns sharing one risk at a time by reading their sticky note aloud. The facilitator collects the note and asks the group whether the risk is understood and whether it is considered likely and impactful.
• Based on the group discussion, each risk is placed on the risk matrix (see below) at the appropriate position.
• After all risks have been shared, the facilitator asks whether any significant risks are missing. For example, based on incidents people have experienced or heard in similar cases.
• After the workshop, the information security team transforms the input into a formal risk register with clear descriptions and assessments. This register is shared with management and archived with the other information security documents.

The IS team can use a pre-populated library of standard risks like RAVIB to check if they might have missed anything.

Mapping risks on a risk matrix

A risk can be defined as a possible event with a negative business impact. The most accurate way of describing a risk would be to determine the exact likelihood/probability/expected number of occurrences of the event, together with the expected financial damage per occurrence. E.g. the risk of an earthquake could be described as having 1% of occurence and an expected damage of 778.000 euros.

In practice it is very difficult to agree on exact estimates for the likelihood and for the expected impact. A practical solution is to only work with a handful of broad categories. In our experience, three likelihood categories and three impact categories is sufficient for most organisations.

It is necessary to agree on definitions for each category. Our typical definitions are:

• High Impact: Long business interruption, with major inconvenience for customers or other outside parties
• Medium impact: Shorter or isolated business interruption, with only minor inconvenience for customers or other outside parties
• Low impact: Limited business interruption, not noticeable for customers or other outside parties
• High probability: More than 50% likelihood of occurrence in a year
• Medium probability: Between 20% and 49% chance of occurrence in a year
• Low probability: 20% or less chance of occurence in a year

It is possible to use other definitions, as long as these are clearly defined in your documentation. For the purpose of ranking risks, each category has been assigned a score, shown in the matrix below. A higher score means that there is more risk. The most urgent risks are in the bold red cell (score 5×5 = 25). Risks with high impact but low probability score 5 (1×5) and the least important risks are the ones with low impact and low probability.

According to ISO27001, you should define the risk acceptance criteria. We suggest that you accept risks with score 4 or lower, and take action on risks with score 5 or higher. This acceptance criterium should be documented, for instance in your information security policy.

Risk treatment options

If a risk cannot be accepted, a treatment option should be selected. The process for deciding what to do a bout a risk is called risk treatment. A simple structure for deciding on the right option is PRACT. We described this structure in our article on project risk management, but it is project-independent and can also be used here. The PRACT actions are:

• Prevent: take action to circumvent the risk completely
• Reduce: Reduce the probability of the event occurring
• Accept: Do nothing as the cost of measures is higher than the value. (Listed for completeness, Accept is not allowed if the risk score is higher than your acceptance criteria)
• Control: Reduce the impact of the risk after occurrence, for instance by taking action now or planning and rehearsing the right response when the event occurs
• Transfer: Transfer the costs of risks to another party, by making them responsible or buying insurance.

In each case you should do a practical cost benefit analysis of a treatment option, to make sure the cure is not more expensive than the risk. It is also important to discuss any decision with the people involved. The information security team should not force decisions on other parts of the organisation, but support the rest of the organisation in making the right decisions.

Continuous risk evaluation

The first time risks are identified, the scores are based on the expert estimates of the participants of the workshop. This informal estimate is good enough for an initial estimate, but to make the risk management method reliable it is necessary to adjust the assessments based on actual data. The information security team should regularly check which events did or did not happen, and adjust the estimations based on the actual data. At the same time, the security team wil probably become aware of new risks, based on questions or signals from the rest of the organisation. If a risk assessment exercise is part of the security awareness training, this can also lead to discovery of new risks. The security team should make sure all information available is captured and combined in the risk register.

Tips and tricks

Defining risks. The event part of a risk should be described concisely but clearly. If an event description is too vague (‘e.g. performance issues’) it is not possible to check whether an event has happened. If the event description is too technical (port configuration error), it is not possible to understand the impact. Some organisations therefore use the format ‘X leads to Y’ for describing risks. X can be any technical or non-technical cause, and Y would be a business impact. e.g. hard disk crash leads to loss of customer data.

Standard risk library. RAVIB offers a well-maintained library of standard information security risks that can serve as a useful checklist and help participants think beyond their immediate area of expertise. Using such a library does not replace the workshop discussion, but it can help ensure completeness.

Risks and assets. Many information security teams use the asset inventory as input for the risk assessment. Every information asset that a company has, probably has a few associated risks such as being lost or compromised. Checking whether all assets have at least one risk attached can help complete the risk assessment. Another useful method for making sure all assets and risks are addressed is to identify different risk types. The list People – Equipment – Environment – Software – Data – Organisation – Third parties (abbreviated PEES DOT) is a useful checklist that can be used for finding additional risks. The framework is shown below.

Owners. One of the most important elements of risk management is the concept of risk owners. For every risk,  you must assign a business person that ‘owns’ it. The risk owner is responsible for determining a) whether the risk is acceptable or should be mitigated, and b) making sure any treatment plans are executed. If you already have assigned information assets owners and a risk is about a specific asset, you can probably assign the risk to the asset owner. If not, you need to make an informed decision based on best match. The CFO could for instance be risk owner for financial systems related risks, the head of sales for risks involving sales and customer data, etc. Each risk owner should approve the treatment option you have chosen for the risk.

Learning more

If you want to deepen your understanding of ISO 27001 risk management and the broader standard, we recommend the following resources:

• SieuwertExplains on YouTube: the ICT Institute YouTube channel with free, detailed video courses on ISO 27001 implementation, covering everything from scoping to certification.
• ISO 27001 training: formal classroom and online training courses from the ICT Institute, designed for security teams who want to ensure the standard is applied correctly.
• Security Verified :our lightweight information security standard for organisations that want a solid security baseline without the full complexity of ISO 27001.
• More articles on information security: the full collection of ICT Institute articles on ISO 27001 Annex Controls.

Suggestions and feedback

If you decide to use this method, make sure that you either copy this text in your information security policy or to include a link to this article in your policy. If you want to do information security right according to ISO 27001 or Security Verified, you must make explicit what method you use.
If you have additional suggestions, feel free to email us and we will add these to the tips and tricks. For more articles about information security, visit this page.