GuideGlobalISO/IEC 27001

ISO/IEC 27001 Risk Treatment and Residual Risk

ISO/IEC 27001 risk treatment selects options and necessary controls for assessed risks, produces the SoA and treatment plan, and ends with risk-owner approval of the plan and acceptance of residual information security risks.

Separate the initial approval from later implementation evidence. Clause 8 requires the treatment plan to be implemented and its results retained; monitoring and reassessment then show whether the remaining risk still meets the organization's criteria.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Overview

Start with an assessment performed under the organization's maintained risk criteria. Clause 6.1.3 then requires appropriate treatment options, all necessary controls, an Annex A completeness check, the Statement of Applicability (SoA), a treatment plan, and risk-owner approval and . ISO/IEC 27001 does not prescribe a treatment taxonomy or acceptance form; the record must be sufficient to demonstrate the required decision and support later operation, monitoring, and reassessment.

Section 1

How should assessed risk become an approved treatment decision?

Start with an assessment process that maintains risk-acceptance and assessment criteria and produces consistent, valid, and comparable results. For each in-scope information-security risk, identify the risk owner, assess potential consequences and realistic likelihood, determine the risk level, compare it with the criteria, and prioritize treatment.

Select an appropriate treatment option based on the assessment and determine every control necessary to implement it. ISO/IEC 27001 leaves the option taxonomy to the organization. Guidance such as ISO/IEC 27005 can help define options and methods, but it does not replace the Clause 6.1.3 requirements.

Compare those necessary controls with Annex A to verify that none were overlooked. Annex A is a reference check, not the only source of controls and not an instruction to implement all 93 controls. The organization can design controls or select them from other sources when needed.

Record the necessary controls, inclusion justifications, implementation status, and Annex A exclusion justifications in the SoA. Formulate the treatment plan, then obtain the risk owners' approval of the plan and acceptance of the residual information security risks.

  • Confirm that the risk falls within the documented ISMS scope and was assessed under the maintained criteria.
  • Record the treatment option, necessary controls, SoA impact, treatment actions, responsible roles, resources, target dates, and evaluation method.
  • Obtain approval from each applicable risk owner; an ISMS coordinator can administer the workflow but cannot silently replace the named risk owner.
  • After implementation, retain treatment results and reassess at planned intervals or when significant changes are proposed or occur.
Section 2

What evidence connects treatment to residual-risk acceptance?

The required records are the risk-assessment and treatment processes, assessment results, SoA, treatment plan, risk-owner approval and acceptance, and treatment results. A practical decision record can link these items to the assessed scenario, criteria, necessary controls, implementation actions, monitoring results, and current residual-risk evaluation.

Keep planned treatment separate from implemented treatment. Clause 6.1.3 requires approval of the plan and acceptance of residual risks, while Clause 8.3 separately requires implementation and retained treatment results. If the initial acceptance assumes planned controls, state that assumption and require a post-implementation review instead of presenting the controls as already effective.

  • Assessment record: applicable criteria, scenario, risk owner, consequences, realistic likelihood, risk level, evaluation, and treatment priority.
  • Treatment record: selected option, necessary controls, actions, responsible roles, resources, target dates, dependencies, and retained implementation result.
  • SoA record: necessary controls, inclusion justification, implementation status, and justification for each excluded Annex A control.
  • Acceptance record: residual-risk result, criteria, material assumptions, approving risk owner, decision date, conditions, and reassessment trigger. The last four fields are practical traceability, not named ISO/IEC 27001 form fields.
Recommended next step

Keep assessment, treatment, the SoA, and acceptance connected

Track risk criteria, treatment decisions, necessary controls, plan approval, implementation results, residual-risk acceptance, monitoring, and reassessment without confusing planned controls with operating controls.

Section 3

How should teams operate risk treatment as a repeatable workflow?

Use a linked workflow: assess under maintained criteria, choose the treatment option, determine necessary controls, compare them with Annex A, produce or update the SoA, formulate and approve the plan, record , implement the plan, retain treatment results, monitor the controls and risk, and reassess when required.

Keep mandated and assigned roles clear. The risk owner approves the treatment plan and accepts residual risk. The organization assigns who implements controls, maintains ISMS records, monitors results, and escalates decisions. Top management remains responsible for ISMS leadership, resources, and management review.

  • Gate 1: assessment is complete and the risk owner is identified.
  • Gate 2: the treatment option, necessary controls, Annex A comparison, SoA, and treatment plan are complete.
  • Gate 3: the applicable risk owner approves the plan and accepts the stated residual risk, assumptions, and conditions.
  • Gate 4: implementation results and monitoring evidence support the current residual-risk evaluation; failures or significant changes reopen assessment and treatment.
Section 4

Which treatment and acceptance mistakes create traceability gaps?

A treatment decision is incomplete when a risk register names an option without the required treatment plan and SoA, or when an SoA reports a control as implemented without support from actual treatment results and operating evidence.

An organization can accept residual risk when approving the treatment plan, but it must not describe planned controls as already operating. Record assumptions and conditions, implement the plan under Clause 8.3, evaluate the result, and reopen the decision if the remaining risk does not meet the criteria.

Copying all Annex A controls into a checklist does not satisfy Clause 6.1.3. Determine necessary controls from the chosen treatment first, use Annex A to check completeness, and justify excluded Annex A controls. Exclusion from the SoA does not cancel a legal, regulatory, contractual, or other relevant interested-party requirement.

  • Do not let an ISMS administrator approve or accept risk on behalf of an unnamed risk owner unless that person is also the assigned risk owner.
  • Do not treat sharing or transfer as automatic elimination; assess the exposure and dependencies that remain under the organization's criteria.
  • Do not freeze the SoA while the treatment plan, control implementation, or residual-risk result changes.
Section 5

When should treatment and residual risk be reassessed?

Clause 8.2 requires information-security risk assessments at planned intervals and when significant changes are proposed or occur. Supplier changes, incidents, control failures, new threats, scope changes, or changed legal and contractual requirements are possible triggers when they are significant to the scoped ISMS.

If reassessment shows that the remaining risk no longer meets the maintained acceptance criteria, select or revise treatment, update necessary controls and the SoA as applicable, revise the treatment plan, obtain the required risk-owner approval and acceptance, and retain the new assessment and treatment results.

  • Set planned assessment intervals and define which proposed or actual changes trigger an earlier assessment.
  • Monitor the information-security processes and controls that affect the risk, using methods and timing that produce valid results.
  • Send risk-assessment results and treatment-plan status into management review, where top management considers them with the other required inputs.
  • Treat a control failure or nonconformity under the applicable processes; risk acceptance alone does not correct a conformity failure.
Primary sources

References and citations

iso.org6 citations
Referenced sections
  • Official listing for the requirements standard. Clauses 6.1.2, 6.1.3, 8.2, 8.3, 9.1, and 9.3 control the risk-treatment and residual-risk decisions covered here.
  • Clauses 6.1.2 and 6.1.3 establish risk criteria, assessment, necessary controls, Annex A comparison, SoA content, treatment planning, and risk-owner approval and acceptance.
  • Clauses 6.1.2, 6.1.3, 8.2, 8.3, and 9.1 establish the required decision records, implementation results, reassessment, and monitoring evidence.
Show 3 more
  • Clauses 6.1.3, 8.3, and 9.1 establish the treatment decision, plan approval and acceptance, implementation, retained results, and monitoring sequence.
  • Clause 6.1.3 establishes necessary controls, Annex A comparison, SoA content, treatment planning, and approval and acceptance by risk owners; Clause 8.3 requires implementation and retained results.
  • Clauses 8.2, 9.1, 9.3, and 10.2 establish reassessment timing, monitoring, management-review inputs, and nonconformity handling.
"Information security management systems — Requirements"
More quoted passages
"acceptance of the residual information security risks"
"implement the information security risk treatment plan"
"formulate an information security risk treatment plan"
"whether the necessary controls are implemented or not"
"when significant changes are proposed or occur"
iso.org4 citations
Referenced sections
  • Official listing for optional information-security risk-management guidance that can support treatment, monitoring, and review methods.
  • ISO/IEC 27005 provides optional guidance on information-security risk management and can help organizations design the additional traceability fields described here.
  • ISO/IEC 27005 provides optional guidance for organizing risk-management activities around the mandatory ISO/IEC 27001 process.
Show 1 more
  • ISO/IEC 27005 provides optional guidance for ongoing information-security risk monitoring and review.
"Guidance on managing information security risks"
iso.org3 citations
Referenced sections
  • Official listing for control guidance that can support selected controls; it does not replace ISO/IEC 27001 risk-treatment requirements.
  • ISO/IEC 27002 provides guidance for information-security controls where it is useful; Clause 6.1.3 permits controls designed by the organization or identified from any source.
  • ISO/IEC 27002 can inform how selected controls operate, but control guidance cannot replace the risk-treatment decisions and records required by ISO/IEC 27001.
"Information security controls"
Show all related guides (21)

ISO/IEC 27001 Internal Audit and Management Review Guide

Keep ISO/IEC 27001 internal audit and management review distinct and connected: independent audit evidence, top-management decisions, corrective actions, resources, and improvement records.

ISO/IEC 27001 Requirements Guide

Plain-language guide to ISO/IEC 27001:2022 Clauses 4-10: context, leadership, planning, support, operation, performance evaluation, improvement, and Annex A control selection.

ISO/IEC 27001 Risk Treatment Register Workflow

Build an ISO/IEC 27001 risk-treatment register that links assessed risks to treatment options, controls, SoA entries, actions, owners, residual-risk approval, evidence, and review triggers.

ISO/IEC 27001 SoA: workflow for gathering and documenting control evidence

Operate the ISO/IEC 27001 Statement of Applicability as a live evidence index linking necessary controls, Annex A inclusion and exclusion rationale, implementation status, owners, and proof.

ISO/IEC 27001 Statement of Applicability template: Annex A control selection and justification

Practical ISO/IEC 27001:2022 Statement of Applicability template fields for necessary controls, Annex A applicability, inclusion and exclusion rationale, status, owners, evidence, and review history.

ISO/IEC 27001 vs NIS2 Comparison

Compare voluntary ISO/IEC 27001 ISMS conformity and optional certification with NIS2 legal duties, entity scope, management accountability, incident reporting, supervision, and penalties.

ISO/IEC 27001 vs NIST CSF 2.0 Comparison

Compare ISO/IEC 27001:2022's certifiable ISMS requirements with NIST CSF 2.0's cybersecurity outcomes, Profiles, Tiers, Functions, evidence uses, and adoption choices.

ISO/IEC 27001 vs SOC 2 Comparison

Compare ISO/IEC 27001 certification with SOC 2 examination reports: criteria, scope, assurance period, auditor and certification-body roles, deliverables, evidence reuse, and claim limits.

ISO/IEC 27001 Annex A Control Ownership FAQ

How to assign practical owners for ISO/IEC 27001 Annex A controls without confusing control ownership with the standard's required risk-owner accountability.

ISO/IEC 27001 Certification Body Evidence FAQ

What ISO/IEC 27001 certification auditors may sample, how to connect requirements to operating evidence, and what the certification body does not own.

ISO/IEC 27001 Internal Audit FAQ

How should teams run ISO/IEC 27001 internal audits: who should own each step, what evidence is expected, and how findings are resolved.

ISO/IEC 27001 Management Review FAQ

What ISO/IEC 27001 management review must consider, what top management must decide, what evidence to retain, and how to set the cadence.

ISO/IEC 27001 Risk Acceptance FAQ

How ISO/IEC 27001 risk acceptance works: criteria, risk-owner approval, residual-risk evidence, external obligations, and reassessment triggers.

ISO/IEC 27001 SoA Exclusions FAQ

Justify ISO/IEC 27001 Annex A exclusions from scope and risk treatment, distinguish implementation gaps, and retain approval and review evidence.

ISO/IEC 27001 Surveillance Audits FAQ

What ISO/IEC 27001 surveillance audits check, how they differ from internal audit and recertification, and what evidence to maintain between audits.