Information Security Risk Management Cycle – Overview


Information security risk management is a wide topic, with many notions, processes, and technologies that are often confused with each other.

In this series of articles, I explain notions and describe processes related to risk management. I also review NIST and ISO standards related to information security risk management.

In the previous article, I reviewed the definition of risk, goals of risk management and listed the main NIST and ISO standards related to information security risk management.

In this article, I will introduce information security risk management cycle.

Cyclic approach – again

The cyclic approach is critical if certain task or process is to be improved in time. The same applies to information security risk management.

In my series of articles on incident management, I explained in detail the incident management cycle. I also mentioned so-called Deming cycle, which is (or should be) the basis of all quality management processes. The main idea of cyclic process approach is that the output of the final phase of the cycle is analyzed and the results are used to improve the input and the cycle itself.

Let’s see how the risk management cycle looks in the main general-level standard on risk management – ISO 31000.

The risk management cycle of ISO 31000

ISO 31000 is a general-level ISO standard on risk management. It can be applied to any risk-related area. It is not dedicated to information security (cybersecurity), but its risk management cycle is the basis of risk management cycles directly used to manage risks related to information security.

Main phases of the risk management cycle of ISO 31000 are:

  • context establishment;
  • risk assessment;
  • risk treatment;
  • monitoring and review.

Context establishment

I call this phase a pre-processing phase. The main goal of risk management is to address the risks (in practice, in information security management, this will most often mean minimizing them – but there could be exceptions to this rule in other areas, like sales, more on that later).

To be able to address the risks, we need to assess them (most often, to calculate them). To be able to assess them, we need to decide on certain parameters and on the method we will use to assess them.

Then, we need to address these risks. This has to be done according to some rules. Given risk can be addressed differently in different organizations. Each organization has to define rules for addressing risks. These rules need to be aligned with organization’s mission, general policies, etc.

And at the very beginning, we need to decide on a scope of risk assessment (the whole organization? a chosen information processing system? a chosen process?), which also includes listing the relevant processes and resources related to these processes.

So, context establishment phase consists in general of these actions:

  • deciding on a scope of risk assessment;
  • deciding on a method and parameters for risk assessment;
  • deciding on rules for addressing the risks.

The context establishment phase is critical for proper risk management. There is no purpose in conducting risk assessment if we don’t know how to start it and if we don’t know what to do with the results. Unfortunately, many organizations use “risk management” tools without context establishment which means that these tools are not aligned with specifics of these organizations. This, in turn, means that instead of helping these organizations manage risks, these tools give a false sense of security.

I will get into more details on and give examples of context establishment in next articles in this series.

Risk assessment

The goal of this phase is to identify risks and assess (most often: calculate) their levels.

A multitude of risks affects information processing. It is not possible (and, what maybe is even more important, it doesn’t make sense) to try to assess all these risks. We need to identify the risks that affect particular processes and resources that are in the scope of our risk assessment. Sometimes this is based on so-called risk scenarios and on deciding whether these risk scenarios apply.

Then we need to calculate (or evaluate) the risk levels for each analyzed risk. This can be done in a very simple way or with the use of an advanced methodology based on mathematical formulas. Any method is good here if it serves its purpose.

I will get into more details on and give examples of risk assessment methodologies in next articles in this series.

I will also review requirements for risk assessment methodologies set by NIST and ISO standards.

Risk treatment

The risk levels calculated in the previous phase should give a clear image on the “risk situation”. The risk assessment results can be presented e.g. via so-called risk maps. This helps to understand where are the highest risks.

But the goal of risk management is to address the risks, not only to learn about them.

So this phase – risk treatment phase – is the phase in which risks are addressed, that is steps are taken to reduce the risks. This has to be done:

  • according to policies set earlier (context establishment phase);
  • according to priorities.

I will get into more details on risk treatment in next articles in this series.

Monitoring and review

Steps taken to reduce the risks must be monitored. Otherwise, it would not be possible to see if these steps were effective.

The goal of this phase – monitoring and review phase – is to:

  • monitor the effectiveness of risk treatment phase;
  • review the effectiveness of the whole risk management process.

The output of this phase becomes part of the input of the first phase (context establishment). This way the Deming management cycle closes up.


Results of each risk management phase can and should be communicated to relevant stakeholders. Finally, it is the top management that has to accept the risks that cannot be reduced (for any reasons – more on that later). So it is important to choose risk management approach and methodology that allows for clear communication both horizontally and vertically. No proper decisions can be made without proper communication.

Next article

In next article, I will review the tiered risk management approach described in NIST Special Publication 800-39: “Managing Information Security Risk: Organization, Missions and Information System View”.

References and further reading

Information Security Risk Management – Introduction
ISO 31000:2009: “Risk management — Principles and guidelines” (currently under review)
ISO/IEC 27005: “Information technology — Security techniques — Information security risk management”
NIST SP 800-39: “Managing Information Security Risk: Organization, Missions and Information System View”
NIST SP 800-30 Rev 1: “Guide for Conducting Risk Assessments”


No comments yet. Be the first to chime in!