Risk Treatment and the Statement of Applicability: Clause 6.1.3 Demystified

Why Clause 6.1.3 Trips Up So Many Organisations

If there is one clause in ISO 27001 that generates more confusion than any other, it is Clause 6.1.3. Most organisations can describe their risks. They can produce a risk assessment. But when an auditor asks to see the Statement of Applicability and trace it back to the risk treatment plan, that is where things often unravel.

The problem is not complexity. The clause is actually quite logical once you understand what it is asking. The problem is that many organisations treat the Statement of Applicability as a compliance checklist to tick off rather than as a living document that reflects genuine decisions about how information security risks will be treated. This article explains what Clause 6.1.3 actually requires, why the Statement of Applicability matters so much, and how to build a risk treatment process that will hold up under scrutiny.

What Clause 6.1.3 Actually Requires

Clause 6.1.3 sits within the planning section of ISO 27001. It follows on directly from Clause 6.1.2, which requires you to conduct an information security risk assessment. Once you have identified and evaluated your risks, Clause 6.1.3 requires you to decide what to do about them.

Specifically, the clause requires your organisation to do the following:

• Select appropriate risk treatment options, taking account of the risk assessment results.
• Determine all the controls necessary to implement the chosen risk treatment options.
• Compare those controls against the controls listed in Annex A of ISO 27001 to verify that no necessary controls have been overlooked.
• Produce a Statement of Applicability that contains all Annex A controls, states whether each control is applicable or not applicable, and provides justification for both inclusion and exclusion.
• Formulate a risk treatment plan.
• Obtain risk owner approval of the risk treatment plan and acceptance of residual risks.

That is the full scope of the requirement. Each element connects to the others, and an auditor will follow that chain from the risk assessment through to the approved treatment plan and the Statement of Applicability.

The Four Risk Treatment Options

Before you can produce a risk treatment plan, you need to understand the options available to you. ISO 27001 does not prescribe a fixed list, but in practice there are four standard approaches.

Modify the Risk

This means applying controls to reduce the likelihood or consequence of a risk event. It is the most common treatment option and is what most people think of when they talk about information security controls. Encrypting data in transit, implementing access controls, or conducting security awareness training are all examples of risk modification.

Retain the Risk

Sometimes the cost of treating a risk outweighs the benefit. If the residual risk after treatment would be minimal, or if the organisation simply accepts that a low likelihood risk is within its risk appetite, it can choose to retain the risk without further action. This must be a deliberate, documented decision, not an oversight.

Avoid the Risk

This means deciding not to undertake the activity that creates the risk in the first place. If a proposed new cloud service introduces unacceptable data sovereignty risks, the organisation might decide not to use that service. Risk avoidance is often underused because it requires willingness to say no to a business activity.

Transfer the Risk

Risk transfer typically involves shifting some or all of the financial consequence of a risk to another party, most commonly through insurance or contractual arrangements with third party providers. It is worth noting that transferring risk does not remove the need to manage it. An auditor will want to see that transferred risks are still monitored.

Annex A and Why You Cannot Ignore It

One of the distinctive features of Clause 6.1.3 is the requirement to compare your selected controls against Annex A. This step exists to serve as a safety net. It forces you to consider whether there are controls in Annex A that your risk treatment process has not identified but that are nonetheless necessary.

In the 2022 edition of ISO 27001, Annex A contains 93 controls organised across four themes: organisational controls, people controls, physical controls, and technological controls. You are not required to implement every control. But you are required to consciously consider each one and document your reasoning for including or excluding it.

This is where many organisations go wrong. They produce a Statement of Applicability that lists all 93 controls with a simple yes or no against each one, without any genuine justification. An auditor reviewing that document will look for the connection between the risk assessment results and the control decisions. If a significant risk has been identified but the relevant Annex A control is marked as not applicable without a credible reason, that is a nonconformity waiting to happen.

A useful way to think about the Annex A review is as a cross check rather than a starting point. Your controls should emerge from your risk assessment first. The Annex A review then confirms you have not missed anything important. If you find controls in Annex A that are relevant to risks you have already identified, you should either include them in your treatment plan or document a clear reason why they are not applicable to your context.

Building the Statement of Applicability

The Statement of Applicability is one of the few documents explicitly required by ISO 27001. It is also one of the most examined documents during a certification audit. Getting it right matters.

What the Statement of Applicability Must Contain

The standard requires the Statement of Applicability to include all Annex A controls, together with justification for their inclusion or exclusion. In practice, most organisations also include the implementation status of each applicable control, which gives auditors and management a clear picture of where the organisation is in its implementation journey.

A well structured Statement of Applicability typically includes the following columns for each control:

• The control reference and title from Annex A.
• Whether the control is applicable or not applicable.
• The justification for inclusion or exclusion.
• The implementation status for applicable controls.
• A reference to the relevant policy, procedure, or documented information that implements the control.

Justifying Exclusions

Excluding a control is entirely permissible, but the justification needs to be credible. Common valid reasons for exclusion include the following: the risk the control addresses does not exist in your context, the business activity that would give rise to the risk is not within scope, or the risk has been treated through another control that provides equivalent protection.

What is not acceptable as a justification is that the control is too difficult to implement, too expensive, or that the organisation has not got around to it yet. An auditor will probe exclusion justifications carefully, particularly for controls that relate to common and well understood risks.

The Connection Between the SoA and the Risk Treatment Plan

The Statement of Applicability and the risk treatment plan are two separate documents, but they must be consistent with each other. The risk treatment plan describes what actions will be taken, who is responsible, what resources are required, and when implementation will be completed. The Statement of Applicability records which controls have been selected and why.

An auditor will trace the connection between the two. If a control is marked as applicable in the Statement of Applicability, there should be a corresponding entry in the risk treatment plan that shows how and when it will be or has been implemented. If those two documents tell different stories, that is a gap the auditor will flag.

Risk Owner Approval and Residual Risk Acceptance

Clause 6.1.3 requires the risk treatment plan to be approved by the risk owners and for residual risks to be accepted. This is not a formality. It is one of the most important governance elements in the entire ISMS.

Risk owners are the people with accountability for the assets, processes, or information that the risks relate to. They are not necessarily the IT manager or the information security manager. A risk owner might be a department head, a business unit manager, or a senior executive, depending on what the risk concerns.

When an auditor asks about risk owner approval, they are testing whether the organisation has genuinely engaged its leadership in the risk treatment process or whether the ISMS is being run as a paper exercise by a small team with no real organisational buy in. Evidence of approval might include signed documentation, meeting minutes, email approvals, or entries in a risk management system. The key is that the approval is documented and traceable.

Residual risk acceptance is the acknowledgement that after treatment has been applied, some risk remains, and the organisation has made a conscious decision that this residual level is acceptable. This decision should be made by someone with appropriate authority, not simply assumed. If the residual risk exceeds the organisation's stated risk appetite, that needs to be escalated and resolved before the treatment plan is finalised.

Common Audit Findings Against Clause 6.1.3

Having reviewed many information security management systems, certain patterns of nonconformity appear repeatedly against this clause. Being aware of them helps you avoid the same mistakes.

The SoA Is Not Linked to the Risk Assessment

This is the most common finding. The Statement of Applicability exists as a standalone document with no visible connection to the risk assessment results. Controls are included or excluded based on a generic template rather than on the actual risks the organisation faces. An auditor will ask you to walk them from a specific risk through to the control decision in the SoA, and if you cannot do that, the finding is straightforward.

Exclusion Justifications Are Generic or Missing

Statements like

not applicable to our business

not relevant

The Risk Treatment Plan Has Not Been Approved

The plan exists but there is no evidence of risk owner review or approval. In some cases, the risk owners are not even aware that a risk treatment plan exists. This points to a systemic issue with how the ISMS is governed.

Residual Risks Have Not Been Formally Accepted

Treatment has been applied but there is no documented acceptance of the residual risk. This often happens when organisations complete their risk assessment and then move straight to implementation without closing the loop on residual risk acceptance.

The SoA Is Out of Date

The Statement of Applicability reflects the state of the organisation at certification time but has not been updated as the business has changed, new risks have emerged, or controls have been added or removed. The SoA is a living document and must be maintained.

How Auditors Assess Clause 6.1.3 in Practice

When an auditor sits down to review Clause 6.1.3, they will typically follow a structured line of enquiry. Understanding that line of enquiry helps you prepare effectively.

The auditor will start with the risk assessment output, usually a risk register, and select a sample of risks to trace through the process. For each sampled risk, they will look for the treatment option that was selected, the controls that were identified, the corresponding entry in the Statement of Applicability, and the risk treatment plan action that shows how the control is being implemented.

They will then look at the Statement of Applicability itself and select a sample of controls marked as not applicable to test whether the exclusion justifications are credible. They will also look at a sample of controls marked as applicable to verify that implementation has occurred or is planned.

Finally, they will look for evidence of risk owner approval and residual risk acceptance. This is often done through document review, but the auditor may also ask interview questions of the risk owners themselves to confirm that they understand their responsibilities and have genuinely engaged with the process.

If you want to understand more about how auditors gather and evaluate evidence during this kind of review, the article on auditing the risk assessment: is it repeatable, owned and documented? covers the practical approach in detail.

Practical Steps to Get Clause 6.1.3 Right

Getting this clause right is not about producing perfect documentation. It is about building a genuine, traceable process that connects your risk assessment to your control decisions and your control decisions to your implementation activity. Here are the practical steps that make the difference.

1. Start with your risk assessment results. Do not start with Annex A. Identify your risks first, then determine what treatment is appropriate for each one. Let the risks drive the control selection.
2. Document your treatment decisions explicitly. For each risk, record which treatment option you have chosen and why. If you are modifying the risk, list the controls you are applying.
3. Use Annex A as a cross check. Once you have identified your controls from the risk assessment, go through Annex A systematically and confirm that you have not missed anything. Add any controls that are relevant but were not identified in the initial assessment.
4. Build your Statement of Applicability from your risk assessment and Annex A review. Every inclusion and exclusion decision should have a traceable reason. Write justifications that are specific to your organisation, not generic statements.
5. Develop a risk treatment plan with clear ownership, timelines, and resources. The plan should be actionable, not aspirational. Each action needs an owner who understands their responsibility.
6. Get formal approval from risk owners. Document that approval in a way that can be shown to an auditor. An email thread, signed document, or meeting minutes all work. The key is that the approval is recorded.
7. Document residual risk acceptance. After treatment, record what residual risk remains and confirm that it has been formally accepted by someone with the appropriate authority.
8. Review and update the SoA regularly. Set a schedule for reviewing the Statement of Applicability, at minimum annually and whenever significant changes occur in the organisation or its risk environment.

For those preparing for a certification audit, the article on checking the Statement of Applicability against the risk treatment plan provides a detailed walkthrough of what auditors examine and how to prepare your documentation.

The SoA in the Context of Broader ISMS Planning

It is worth stepping back and seeing Clause 6.1.3 in its broader context. It does not sit in isolation. It is the output of the risk assessment process under Clause 6.1.2 and feeds directly into the operational planning requirements of Clause 8. The Statement of Applicability and risk treatment plan are the bridge between your assessment of risks and your actual implementation of controls.

Understanding this connection helps you explain the ISMS to senior leaders and risk owners. The question you are answering through Clause 6.1.3 is straightforward: given what we know about our information security risks, what are we going to do about them, and how do we know we have not missed anything important? The Statement of Applicability is your documented answer to that question.

If you are working across multiple standards, it is also worth noting that risk treatment concepts appear in ISO 9001, ISO 14001, and ISO 45001, though those standards do not require a Statement of Applicability. The disciplined approach of identifying risks, selecting treatments, and documenting decisions is a transferable skill. The article on risk based thinking with practical examples explores how this thinking applies across different management system standards.

Building the Skills to Audit Clause 6.1.3

Whether you are an internal auditor preparing to review your organisation's ISMS or a practitioner working towards lead auditor credentials, understanding how to audit Clause 6.1.3 requires more than reading the standard. It requires knowing what good looks like, how to follow an audit trail from risk to control to implementation, and how to ask the right questions of risk owners and system administrators.

At Audit Workshop, our ISO 27001 auditor training covers the full planning and risk treatment requirements in practical detail, including how to evaluate the Statement of Applicability, how to test exclusion justifications, and how to verify that risk owner approval is genuine rather than nominal. The training is built around real audit scenarios so that when you sit across from a risk owner or review an SoA for the first time, you know exactly what you are looking for.

If you are building your auditing credentials and want to understand not just what the standard requires but how experienced auditors actually assess it, our courses provide that practical foundation. You can explore the available training options at auditworkshop.com.