## Clause 6.1.3: Information security risk treatment

[Clause 6.1.3](../../../MoCs/ISO_27001_2022_6.1.3_MoC%20Information%20security%20risk%20treatment.md) describes the treatment of information security risks.
This is about choosing risk treatment options, and determining which controls we might implement to respond to a risk.

We can do that by selecting controls from Annex A, culminating in the Statement of Applicability[^2] (6.1.3d).
Another important output of the risk treatment process is the Risk Treatment Plan (6.1.3e).

It's important that the risk owner gives his approval for the risk treatment plan, accepts the residual risk – that's the risk that's going to be left after the treatment has took place (6.1.3f). The risk owner's approval is vitally important: as an auditor you need to see that the risk owner was involved, and ultimately made that final decision.

### Risk treatment options

These are the risk treatment options:

1. Risk modification
2. Risk avoidance
3. Risk sharing
4. Risk retention


**Risk modification** means changing the circumstances around a risk, by implementing controls to reduce the *vulnerability* to threats, reduce the *likelihood* of a risk materializing, or the *impact* of a risk *when* it materializes.

Examples are implementing network segregation and firewalls to reduce the vulnerability and the likelihood, and disk encryption on laptops to reduce the potential impact of a laptop being stolen.

The reason ISO speaks of modification instead of reduction is that in theory, we could choose to increase the risk. Suppose a security control is so effective that it has lowered the risk far below the risk tolerance level, but we need to spend a lot of time and money to implement it. The organization could then decide to remove or weaken the control, just as long as the risk is still managed.

**Risk avoidance** is where we take a decision to avoid the risk scenario partly or wholly.  Examples are to stop accepting card payments from a particular territory we see a lot of fraud, not using a particular type of technology, or not taking your devices across certain geographical borders.

**Risk sharing**  is when two organizations share the burden of a risk. Examples are outsourcing to a party with more expertise in a certain area, like a provider of network services or a payment services provider.
This was previously called risk transfer, but this term was dropped because you actually can't pass a risk to somebody else: as an organization you remain accountable to regulators and clients in case of a security breach, even if you outsourced the asset or the process (with due diligence) where the breach occurred.

**Risk retention** means accepting a risk *for now*. This may be needed when the other treatment options are impractical, not affordable, technically not feasible, or unavailable. Retention is allowed providing that it's done as part of a proper process in line with your risk management process, and it's not just the default go-to option.

### Risk modification by implementing controls

Clause 8.3 of [ISO 27005](../ISO%2027005.md), the guidance document on risk management[^1], says that we shall select controls in order to address risks. These can be preventative, detective or corrective in nature.

Which controls will be implemented by the organization, is specified in the Statement of Applicability (6.1.3d).

In the SoA the organization can't just say they've included a control because "you know we're just ticking a box".


For controls deemed not applicable by the organization, the auditor will want to know how you came to that conclusion. The simplest reasons for not including a control is because they don't have the business process it applies to (like software development or working from home), the proces is declared out of scope, or the control is at odds with a law or a regulation.

The controls in Annex A are often described in just one or two sentences. You must look at ISO 27002 for guidance on the implementation of a control.



---
## Footnotes

[^1]: There's also a [Clause 8.3](../../../MoCs/ISO_27001_2022_8.3_MoC%20Information%20security%20risk%20treatment.md) Information security risk treatment in ISO 27001. It's very short: The organization shall implement the information security risk treatment plan, and it shall retain documented information on the treatments' results.
[^2]: See also [About the Statement of Applicability](../../../💡Drafts%20and%20Ideas/ISMS/About%20the%20Statement%20of%20Applicability.md).