7 steps to a successful ISO 27001 risk assessment

Risk assessments are at the core of any organisation’s ISO 27001 compliance project.

They are essential for ensuring that your ISMS (information security management system), which results from implementing the Standard, addresses the threats comprehensively and appropriately.

What is an information security risk assessment?

In the context of information risk management, a risk assessment helps organisations assess and manage incidents that have the potential to cause harm to your sensitive data.

The process involves identifying vulnerabilities that a cyber criminal could exploit or mistakes that employees could make.

You then determine the level of risk they present and decide on the best course of action to prevent them from happening.

So, how should you get started? Let’s break down the ISO 27001 risk assessment process.

How to conduct an ISO 27001 risk assessment

Risk assessments can be daunting, but we’ve simplified the ISO 27001 risk assessment process into seven steps:

1. Define your risk assessment methodology

There is no set ISO 27001 risk assessment procedure. Instead, you should tailor your approach to the needs of your organisation.

To do this, you need to review certain things. First, you should look at your organisation’s context.

This consists of your legal, regulatory and contractual obligations, your objectives concerning information security and the business more widely, and the needs and expectations of its stakeholders.

Next, you should look at the risk criteria. This is an agreed way of measuring risks, usually according to the impact they will cause and the likelihood of them occurring.

These need to be clearly defined and widely understood so that any two risk assessments produce comparable results.

Finally, you need to determine your risk acceptance criteria. You can’t eradicate every risk you face, so you must decide the level of residual risk you are willing to leave unaddressed.

2. Compile a list of your information assets

ISO 27001 gives organisations the choice of evaluating through an asset-based approach (in or a scenario-based approach.

Although each have their pros and cons, we generally recommend taking an asset-based approach – in part because you can work from an existing list of information assets.

This includes hard copies of information, electronic files, removable media, mobile devices and intangibles, such as intellectual property.

3. Identify threats and vulnerabilities

Once you’ve created your list of information assets, it’s time to determine the risks associated with them.

For example, when analysing work-issued laptops, one of the risks you highlight will be the possibility of them being stolen. Another will be that when in a public place, employees might use an insecure Internet connection, or someone might see sensitive information on their screen.

4. Evaluate risks

Some risks are more severe than others, so you need to determine which ones you need to be most concerned about at this stage.

This is where your risk criteria come in handy. It provides a guide that helps you compare risks by assigning a score to the likelihood of it occurring and the damage it will cause.

By evaluating the risks in this way, you get a consistent and comparable assessment of the threats your organisations face.

ISO 27001 doesn’t state how you should score risks – whether that’s high to low, 1 to 5, 1 to a 100 or otherwise. It doesn’t matter as long as everyone responsible for evaluating risks uses the same approach.

5. Mitigate the risks

There are four ways that organisations can treat risks:

  • Modify the risk by applying security controls to reduce the likelihood of it occurring and/or damage it will cause.
  • Retain the risk – accept that it falls within previously established risk acceptance criteria or via extraordinary decisions.
  • Avoid the risk by changing the circumstances that are causing it.
  • Share the risk with a partner, such as an insurance firm or a third party that is better equipped to manage the risk.

ISO 27001 requires all risks to have an owner responsible for approving any risk treatment plans and accepting the level of residual risk. The person who owns risk treatment activities may be different from the asset owner.

6. Compile risk reports

Next comes the documentation process, which is necessary for audit and certification purposes.

The most important documents are the RTP (risk treatment plan), which documents the decisions you’ve made regarding risk treatment, and the SoA (Statement of Applicability).

Clause 6.1.3 of the Standard states an SoA must:

  • Identify which controls an organisation has selected to tackle identified risks;
  • Explain why these have been selected;
  • State whether or not the organisation has implemented the controls; and
  • Explain why any controls have been omitted.

Every control should have its own entry. In cases where the control has been selected, the SoA should link to relevant documentation about its implementation.

7. Review, monitor and audit

ISO 27001 requires your organisation to continually review, update and improve the ISMS to ensure it is working as intended.

You will need to repeat the assessment process annually to ensure you’ve accounted for changes in how your organisation operates and the changing threat environment.

You should also use the opportunity to look for ways in which your ISMS can be improved. This might involve using a different control to address a risk or switching to a different risk treatment option altogether.

Learn more about risk assessments

You can learn more about each of these steps by reading Nine Steps to Success – An ISO 27001 Implementation Overview.

This concise guide helps you get to grips with the requirements of the Standard and make your ISO 27001 implementation project a success.

Written by Alan Calder, Nine Steps to Success guides you through an ISO 27001 implementation project step-by-step, covering the most essential aspects, including gaining management support, scoping, planning, communication, risk assessment and documentation.


A version of this blog was originally published on 19 September 2017.