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
Sections
5

Structured answer sets in this page tree.

Primary sources
4

Cited legal and guidance references.

Publication metadata
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.org
Referenced sections
  • Clauses 8.2, 9.1, 9.3, and 10.2 establish reassessment timing, monitoring, management-review inputs, and nonconformity handling.
"when significant changes are proposed or occur"
iso.org
Referenced sections
  • 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"
iso.org
Referenced sections
  • ISO/IEC 27005 provides optional guidance for ongoing information-security risk monitoring and review.
"Guidance on managing information security risks"
Related guides

Explore more topics

ISO/IEC 27001 Annex A Control Evidence Guide
Build useful ISO/IEC 27001:2022 Annex A control evidence: selected controls, SoA rationale, owners, implementation proof, effectiveness checks, audit records, and improvement actions.
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 Audit Readiness Guide
Prepare ISO/IEC 27001 audit evidence across ISMS scope, risk assessment, risk treatment, Statement of Applicability, Annex A controls, internal audit, management review, and corrective actions.
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 Certification Stage Workflow
Plan optional ISO/IEC 27001 certification from scope readiness through Stage 1, Stage 2, findings, certification decision, surveillance, and recertification.
ISO/IEC 27001 Compliance Guide: ISMS Evidence
Build ISO/IEC 27001:2022 conformity evidence for ISMS scope, leadership, risk assessment and treatment, the Statement of Applicability, operations, audits, management review, and corrective action.
ISO/IEC 27001 FAQ: ISMS Scope, Risk and SoA
Practical ISO/IEC 27001 FAQ covering ISMS scope, risk assessment, risk treatment, Statement of Applicability, Annex A controls, certification evidence, audits, management review, and surveillance readiness.
ISO/IEC 27001 Implementation Roadmap Guide
A practical ISO/IEC 27001:2022 roadmap from context and scope through risk treatment, the SoA, control operation, internal audit, management review, corrective action, and optional certification.
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 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 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 Acceptance FAQ
How ISO/IEC 27001 risk acceptance works: criteria, risk-owner approval, residual-risk evidence, external obligations, and reassessment triggers.
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 Exclusions FAQ
How should teams justify Statement of Applicability exclusions under ISO/IEC 27001? Practical answer with owners, evidence, review triggers, and external source references.
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 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.
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.