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.

Why risk assessment is important

If you want to do information security right, you should not blindly implement security measures that are available. You should first understand what the assets are that you want to protect. Then you must check if there are any risks (risk identification) and assess the importance of each risk. Only then should you start treating the most important risks by implementing controls. The risk management method ensures that the right security measures are taken: Measures that will have a real value, instead of measures that are just 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 risk management method. In ISO27001, section 6.1.2 states the exact criteria that the risk assessment method must meet.

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.

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 person in the workshop is asked to write down between 3 and ten risks, each on an individual sticky notes. At this point in the workshop, each person should work individually, without talking to other participants. When everyone has completed writing down their risk, participants take turns in sharing a risk by reading one of their notes out loud. The note is then given to the facilitator, who asks the other participants whether they understand the risk and whether they think it is likely and has a significant impact. Based on the responses, the risk is placed on a whiteboard in one of the squares of the risk matrix.
After everyone has shared their risks, the facilitator asks if any significant risks are missing, for instance based on incidents that people have already experienced. After a short discussion, the workshop ends.
After the workshop, the information security team uses the input to create an official risk register with all the risks clearly described and estimated. This risk register is then sent to management and archived with the other information security documents.

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 hard to give exact estimates for the likelihood and for the expected impact. Trying to get consensus in an organisation on exact numbers is therefore difficult. 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-indepent 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 occuring
• 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

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. harddisk crash leads to loss of customer data.
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.

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.

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.