Information Security Risk Treatment for ISO 27001
ISO 27001 Clause 6.1.3
This sub-clause requires the organisation to define and apply an information security risk treatment process, selecting Annex A controls and producing a Statement of Applicability.
ISO 27001 Clause 6.1.3 - Information Security Risk Treatment
Clause 6.1.3 deals with what happens after the risks have been identified and evaluated. It is the clause that produces two of the most important documents in the entire ISMS: the Statement of Applicability and the risk treatment plan. Both are mandatory and both are looked at by every certification auditor.
What ISO 27001 Clause 6.1.3 Requires
The clause requires the organisation to define and apply a risk treatment process to: select appropriate risk treatment options taking account of the risk assessment results; determine all controls necessary to implement the chosen treatment options; compare the determined controls against the controls in Annex A to verify that no necessary controls have been omitted; produce a Statement of Applicability that lists the necessary controls, justifies their inclusion or exclusion, and states whether they have been implemented; create a risk treatment plan; and obtain risk owner approval of the plan and of the residual risks.
Documented information about the risk treatment process must be retained.
The Four Risk Treatment Options
For each risk above the acceptance threshold, the organisation chooses one or more treatment options. The four standard options are: modify the risk by applying controls that reduce the likelihood or consequence; retain the risk where the residual level is acceptable; avoid the risk by stopping the activity that creates it; and share the risk through insurance, contracts or partnerships. Modify is by far the most common choice for information security risks because it is what the Annex A controls are designed to support.
Once a treatment option is selected, the organisation determines what controls are needed to implement it. The controls might come from Annex A, from the organisation's existing arrangements, from regulatory requirements or from industry guidance like ISO 27002, NIST or sector-specific frameworks.
The Comparison with Annex A
The standard requires the organisation to compare the controls it has determined against those listed in Annex A. The purpose is not to use every Annex A control - it is to make sure no necessary control has been overlooked. Annex A functions as a reference catalogue. The 93 controls in the 2022 version cover the breadth of information security practice, so checking against them catches gaps in the organisation's own thinking.
The Statement of Applicability
The Statement of Applicability records the result. It lists each Annex A control. For each control it records whether the control is necessary, why, whether it is currently implemented and the justification for any exclusion. The Statement of Applicability is mandatory documented information. It is the document the certification auditor will spend most time on.
Excluding a control is allowed where there is a legitimate reason. A typical example is A.8.28 Secure coding, which is not necessary for organisations that do not develop software. The justification has to be documented and defensible.
The Risk Treatment Plan
The risk treatment plan records what is being done about each risk that is being modified or avoided. It identifies the controls being put in place, the actions needed to implement them, the owners and the timescales. The plan is approved by the risk owners, alongside the residual risk that will remain after treatment.
The treatment plan is a working document. As actions are completed, the plan is updated. As new risks emerge, new entries are added. The risks register, the treatment plan and the Statement of Applicability are kept in sync with each other.
The Statement of Applicability is one of the documents I find people most worried about. It is actually one of the most logical. Each Annex A control gets a yes or no for whether it is needed, plus a reason. Where it is needed, you note whether it is in place. That is the structure. The work is in being honest about which controls are genuinely needed and which are not.
I always cross-check the SoA against the risk register and the treatment plan. If the SoA says a control is implemented, the risk register should show the related risk being treated, and the treatment plan should show how. If those three documents do not line up, the risk treatment process is not running properly. That is one of the most common findings I raise.
Practical Compliance Guidance
The Statement of Applicability is the central document for Clause 6.1.3. Both the ISO 27001:2013 and ISO 27001:2022 versions of the SoA template are included in the toolkit, with all Annex A controls pre-listed.
The documents below support the risk treatment process and the production of the Statement of Applicability and risk treatment plan.
| alphaZ document | How to use it |
|---|---|
| ISO 27001 Toolkit | Complete documentation set for ISO 27001:2022 including the Statement of Applicability template and all Annex A control documents. |
| F-IMS26 Statement of Applicability | Pre-formatted Statement of Applicability with all 93 Annex A controls listed and ready for the organisation to complete the applicability decisions and justifications. |
| ER15 Information Security Risks Register | Information security risk register that includes columns for risk treatment options, related Annex A controls and residual risk acceptance. |
| ISO 27001:2022 Annex A Correlation | Maps each Annex A control to the relevant alphaZ documents, useful when populating the SoA and the risk treatment plan. |
Note - all the above files can be downloaded with an alphaZ subscription.
Frequently Asked Questions
UK Legislation
The following UK legislation typically influences the choice of risk treatments and the controls applied.
- UK General Data Protection Regulation (UK GDPR)
- Data Protection Act 2018
- Network and Information Systems Regulations 2018
