## Clause 6.1: Actions to address risks and opportunities

[Clause 6.1.1](../../../MoCs/ISO_27001_2022_6.1.1_MoC%20General.md) ('General') isn't about information security risks specifically, it's about the ISMS, and risks *to* the ISMS.
 
Clause 6.1.1 says that when planning the ISMS, the organization shall consider the issues referred to in [4.1](../OST/27001/EN/c-4.1-Understanding-the-organization-and-its-context.md) (Context) and the requirements referred to in [4.2](../../../iso27diy-corp/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT%204.2%20Understanding%20the%20needs%20and%20expectations%20of%20interested%20parties.md) (Needs and expectations of interested parties), and determine the risks and opportunities that need to be addressed to *ensure the ISMS can achieve its intended outcomes, prevent or reduce undesired effects and achieve continual improvement.*

So  when we're thinking about establishing an ISMS, what are the situations or events that could have a negative effect on the ability of the ISMS to work as expected. Examples are resource shortages, or lack of appropriate support from management.

On the flip site, there may be opportunities to gain benefits from the ISMS beyond it's primary purpose, information security. For example, having a certified ISMS may increase commercial opportunities, or the detailed risk analysis that is part of the ISMS, may may identify opportunities to improve efficiency in certain processes, or remove duplication, etc.

Clause 6.1.1 wants us to focus on those particular risks and opportunities.

Clause 6.1.2, on the other hand, *is* about information security risks. 

## Clause 6.1.2: Information security risk assessment

Where [Clause 6.1.1](../../../MoCs/ISO_27001_2022_6.1.1_MoC%20General.md) is about risks to the *ISMS*, [Clause 6.1.2](../../../MoCs/ISO_27001_2022_6.1.2_MoC%20Information%20security%20risk%20assessment.md), on the other hand, is about risks to the *security of information*. 

Clause 6.1.2 states that the organization shall define and apply an information security **risk assessment process** that does a number of things, starting with the establishment, and following maintenance, of **risk criteria**. You may think of this as setting rules for the organization, to understand what  information security risks *are*.

### Risk Criteria

The first step in this is setting **risk acceptance criteria**: when a risk is identified, how do we decide it it's acceptable to the organization? If the organization already has some general rules or criteria for dealing with risks, you can use that as a starting point.

It's also required that we set criteria for *performing* risk assessments, so that we know when we need to do it, for instance: yearly, and/or at the start of a new project, after a major incident, etc.

The answers to these questions need to be part of a documented risk assessment process.

This risk assessment process should ensure repeatable results – we'll get back to that a little bit later.

A very important thing to bring up early, is **risk ownership**. We need to be clear about who the risk owner will be, even before we start identifying risks. Because as soon as we identify them, decisions need to be made on what to do with them. Risk owners are individuals in the organization with a level of authority and trust to make these risk decisions. It's impractical for several reasons to have a discussion of risk ownership after the fact.

As an auditor I expect to see a clearly defined and understandable risk assessment process, and evidence for its execution, by maybe getting somebody to take me through risk assessments that have been performed.

Although Clause 6.1.2 tells you what should be considered when doing risk assessments, it does not tell you *how* to conduct a risk assessment. It doesn't tell you to use a risk calculation scale of 1 to 10, or high, medium and low, or using some other kind of formula, and neither does the ISO 27002 implementation guidance, of the [ISO 27005](../ISO%2027005.md) (Guidance on managing information security risks).

What it *does* tell us, is that we need to have an agreed way of conducting risk assessments, and that we need predefined risk acceptance criteria.

A good way to start is sitting down with management to create an 'Impact Table' with different levels of impact. If the possible damage reaches a certain level, there will be set consequences. You may call this **risk escalation criteria**. So for instance if a risk could result in the loss of money beyond a certain amount, and the likelihood of that happening is above a certain level, the information security committee cannot mark it as acceptable, and it needs to come to the board for review.

These are the kind of conversations that an organization should be having to define these criteria and identify the overall level of acceptable risk when it comes to information security.

The level of acceptable risk is also called **risk appetite**, and it will vary depending on the organization. A government entity, for example, may be looking for stability and doesn't  want to take any unnecessary risks, and a such will have a low risk appetite, whereas a venture capitalist looking for rapid growth may have a much higher risk appetite, because thy believe innovating and taking risks are necessary for growth.

As an auditor it's important you're able to understand if they have defined these things and why, and does it have the appropriate support from top management.

### Comparable and reproducible results

Clause 6.1.2b says that the organization must ensure that risk assessments generate "consistent, valid and comparable results". 

This means that the results of a repeated risk assessment must be reproducible, independent of the situation and the person conducting the assessment. This is done by having (and following) a defined risk assessment methodology.


**Defining a Risk Assessment Approach**

![1000](Defining%20a%20Risk%20Assessment%20Approach.png)

There are many methodologies available – some are very simple and some of them very complex and detail orientated. It's also possible to design your own methodology. So how can an organization settle on one that makes sense?

First thing is, it must be compatible with the requirements of 27001, which means it should consider threat, vulnerability, impact and likelihood, and the three tenants of security (Confidentiality, Integrity, Availability).

Also, the terms used (the vocabulary) needs to be defined, so that when refers to the concept of threat, for example, it must be clear to all what is meant by that.


**Selecting a Risk Assessment Methodology**

![1000](Selecting%20a%20Risk%20Assessment%20Methodology.png)

Number 5 in this diagram, ease of use and pragmatism of the method, means the method must match the organization at the time of application. A large government department with low risk appetite and plenty of resources, might spend 50 days or more assessing the risks of a single system, because it justifies the type of system and the information it's trying to protect. A small startup with no previous experience in formal risk assessment, may choose to start with a simple to use spreadsheet. 

So the method you pick must be fit for purpose and suitable for the organization. This also comes back in point 3 (available tooling), point 4 (documentation and competencies) and point 6 (costs of utilization).

Costs of utilization can be broken down in the time needed, need to bring in specialists, etc.

Well known methods of risk analysis include:

- [OCTAVE](../../CISSP/CISSP_OSG8_D1_C1_1.10.md#OCTAVE) from Carnegie Mellon University
- MEHARI, mostly used in Europe
- EBIOS, now maintained by ANSSI France
- IRAM from the Information Security Forum

OCTAVE S and and Allegro are targeted at smaller organizations.

The risk management method chosen should follow the stages that are laid out in ISO 27005: Guidance on managing information security risks. 

### Risk identification in ISO 27005
The first step in Risk Management, according to ISO 27005, is risk identification.

![1000](Risk%20Identification%20in%20ISO%2027005.png)
*Risk identification according to ISO 27005, clause 7.2.1. This relates to [ISO 27001:2022, 6.1.2 c1](../OST/27001/EN/c-6.1.2-Information-security-risk-assessment.md).*

This is done by identifying potential scenarios, without yet looking at likelihood or impact. It's usually a team effort with people from a given part of the organization, and apart from  risk owners may involve domain experts, subject experts, and a facilitator.

The two main approaches are Asset Based and Event Based risk identification.

In **event based risk identification** we talk about specific events in general. Let's take ransomware as an example. We can talk about a possible ransomware event and how that might play out in our organization.
In an **asset based** approach we focus on specific assets (like software systems), and examine their potential vulnerabilities and threats.

While the event based approach gives you a good organizational overview by clarifying the impact in different organizational environments, the asset based approach gives you more specific details. In general a combination of these two methods is best, especially for critical assets.

In the identification phase it's best to postpone arguments about the likeliness of specific scenario's happening, to the next phase: risk analysis and evaluation.

### Risk analysis and evaluation in ISO 27005
In risk analysis we look at the potential consequences of risk scenario's playing out, and the likelihood of them.

Likelihood can be established by looking at previous historical data, either in our own organization or in others. If that information is not available, you can look at vulnerabilities and how easy it is to exploit them. Do they require a lot of insider knowledge or technical expertise, and a determined and motivated threat actor to exploit them, or is exploitation trivial? How motivated and capable are our threat sources? For instance, may I be targeted by state actors or organized crime groups?

These are indicators of the likelihood of risks materializing. You can answer these questions if you've done a proper threat analysis (see [Control 5.7](../../../MoCs/ISO_27002_2022_5.7_MoC%20Threat%20intelligence.md)). 

As an auditor you will be looking at if the organization calculates likelihoods and consequences, does it have a proper system for doing so, is it evaluation risks by looking at a combination of likelihood and consequence (probability x impact), and making decisions about risk treatment and priorities based on that.

Apart from ISO 27005, other standards like the NIST SP 800-30 and the TRA (The Harmonized Threat and Risk Assessment from the Canadian Government) offer guidance for conduction information security risk assessments.

Risk treatment comes into play when risk owners decide that risks are unacceptable and action needs to be taken. We'll shortly see that the risk owner is the one who should be approving the risk treatment plan and validating that risk treatment is taking place.
