4.3 Risk Treatment Plan, Risk Owners, and the Path to Controls

Risk assessment identifies and measures risks. Risk treatment decides what to do about them. The Risk Treatment Plan (RTP) is the document that captures those decisions, and the risk owner is the person accountable for them. Together they produce the Statement of Applicability (SoA) — the single most scrutinised document in any ISO/IEC 27001 certification audit.

What Is the Risk Treatment Plan?

Clause 6.1.3 requires the organisation to produce a risk treatment plan. In practice, the RTP is a structured set of actions — typically one row per risk scenario in the risk register — that answers six questions:

The RTP is a living document. Each time the risk assessment is refreshed, the RTP is reviewed and updated.

The Risk Owner: Accountability, Not Just Responsibility

A risk owner is the person or entity that is accountable for a risk — the one who answer for the outcome and who has the authority to decide how the risk is treated. The Foundation exam draws a sharp line between accountability and operational responsibility.

A risk owner may delegate implementation — the CISO can ask the Network Engineering team to deploy a firewall — but cannot delegate accountability. If the firewall is misconfigured and a breach occurs, the CISO still answers for it. This is the same "assigns ownership and accountability" language used in Clause 5.3 for roles within the ISMS.

Who Can Be a Risk Owner?

Risk owners are typically managers with sufficient authority to commit resources and accept residual risk on behalf of the organisation. Top management approves the overall risk criteria and risk appetite, but individual risks are owned by the manager closest to the affected business process — for example:

• The CIO owns risks to internal IT infrastructure.
• The Head of HR owns risks to employee personal data.
• The Product Owner owns risks in their application.

From RTP to Statement of Applicability

The Statement of Applicability (SoA) is the bridge between risk treatment and the Annex A controls. Clause 6.1.3 d) requires the organisation to produce a SoA that:

1. Lists all Annex A controls (in the 2022 version, that is 93 controls across 4 themes — organisational, people, physical, and technological).
2. States whether each control is applicable or not applicable.
3. Justifies any exclusion.
4. Identifies the controls that have been implemented as part of risk treatment (and those planned for future implementation).
5. References the risk treatment that justifies each included control.

The SoA is produced from the RTP — not the other way around. The flow is:

Risk Assessment (6.1.2) → Risk Treatment Decision (6.1.3 a–c)
                              ↓
                       Risk Treatment Plan
                              ↓
                  Annex A Control Selection
                              ↓
                  Statement of Applicability

What the SoA Is Not

• It is not a copy of Annex A with every box ticked. Implementing all 93 controls without justification is an audit finding — the standard expects selection based on risk and context.
• It is not a policies manual. The SoA says which controls apply, not how they are implemented. The "how" lives in the policies, procedures, and ISO/IEC 27002 guidance.
• It is not static. It must be reviewed whenever the risk assessment or context changes.

Selecting Annex A Controls

Annex A of ISO/IEC 27001:2022 is organised into four control themes:

For each risk scenario in the RTP, the organisation asks: "Which Annex A controls would reduce this risk to an acceptable level?" Those controls are marked applicable in the SoA and linked back to the scenario. Controls that do not map to any scenario — and are not required by legal, regulatory, or contractual obligations — are marked not applicable, with a one-line justification.

Worked Example

Risk scenario: An insider exfiltrates customer data from the CRM.

• Chosen option: Modify.
• Selected Annex A controls: A.5.12 (classification of information), A.5.15 (access control), A.6.6 (confidentiality or non-disclosure agreements), A.8.3 (information access restriction), A.8.15 (logging).
• Risk owner: Head of Sales Operations.
• Residual risk: Medium, accepted by the risk owner.

The SoA row for each of those five controls would reference this scenario. An excluded control — say A.7.6 (working in secure areas) — might be justified with: "Not applicable: the organisation has no physical secure areas; all work is remote."

Residual Risk Acceptance

Clause 6.1.3 f) requires that residual risks be explicitly accepted by the risk owners. This is the final step before the RTP can be closed out for a given scenario.

Residual risk is what remains after the selected controls have been implemented. Even well-treated risks are rarely zero. The risk owner must compare the residual level against the risk criteria and either:

• Accept it (the residual falls within criteria) — record the decision and move on.
• Reject it (the residual still exceeds criteria) — return to risk treatment and select additional or stronger controls.

This acceptance is auditable evidence. An auditor will ask: "Show me where the risk owner signed off on the residual risk for this scenario." A missing signature is a nonconformity.

How RTP, SoA, and Controls Connect

Exam Traps

• "The SoA lists only the controls that have been implemented." Wrong. The SoA lists all Annex A controls and states whether each is applicable — including the ones excluded, with justification.
• "Risk owners can delegate accountability." Wrong. Operational responsibility yes; accountability no.
• "Residual risk acceptance is optional if the controls are strong." Wrong. Clause 6.1.3 f) requires it for every treated risk, regardless of how low the residual is.
• "Annex A controls are selected first, then risks are assessed to fit them." Wrong direction. Risk treatment results drive control selection.

Closing the Loop

The RTP and SoA feed directly into the ISMS implementation. The controls selected become the organisation's operational security work programme. Their effectiveness is monitored under Clause 9 (performance evaluation), and any change in context, threats, or technology triggers a new pass through 6.1.2 and 6.1.3. That continuous loop is what makes the ISMS a system rather than a one-off project.