An ISO 27001 risk treatment plan connects information security risk assessment findings to the specific, accountable actions an organization takes within its Information Security Management System (ISMS). ISO/IEC 27001:2022 Clause 6.1.3 identifies the risk treatment plan as a documented result of the information security risk treatment process. Clause 8.3 then requires the organization to implement that plan and retain documented information of the treatment results.

This creates a common audit issue. An organization may maintain a detailed risk treatment plan but struggle to demonstrate that the plan reflects actual treatment activities. A spreadsheet can show an owner, target date, selected control, and implementation status. The certification audit still needs objective evidence that the treatment occurred and produced the documented result.

The ISO 27001 risk treatment plan therefore connects the risk assessment, treatment decision, Statement of Applicability (SoA), implementation activity, and residual risk decision.

This guide explains what an ISO 27001 risk treatment plan should demonstrate, which records support its traceability, and how certification auditors evaluate it during an ISO 27001 certification audit.

Distinguishing the Risk Treatment Plan From the Risk Assessment

Risk assessment and risk treatment perform different functions within ISO 27001 risk management.

Clause 6.1.2 requires the organization to define and apply an information security risk assessment process. That process includes risk identification, risk analysis, and risk evaluation. It also requires defined criteria for assessing and accepting information security risks.

The assessment establishes the organization's understanding of its information security risks. Treatment follows that assessment.

The ISO 27001 risk treatment plan records how the organization intends to address risks that require treatment. It connects the treatment decision to the controls and actions selected through the risk treatment process.

This distinction matters during an ISO 27001 certification audit.

What an ISO 27001 Risk Treatment Plan Must Contain

Every risk entry in the RTP should carry these fields:

• A unique Risk ID that traces back to the risk register
• A plain-language risk description including asset, threat, and vulnerability
• The inherent risk score (likelihood × impact before treatment)
• The chosen treatment option
• The specific Annex A control or custom control applied
• A named risk owner with authority to act
• A target completion date
• The implementation status
• The residual risk score with formal acceptance sign-off

A treatment rationale is a brief explanation of why a specific option was chosen over alternatives. Auditors and AI-assisted review tools increasingly flag missing rationale as a governance weakness because acceptance decisions without documented justification cannot demonstrate that risk appetite was deliberately applied.

ISO 27001:2022 reorganized Annex A from 114 controls across 14 domains to 93 controls across four themes: Organizational, People, Physical, and Technological (Source: ISO/IEC 27001:2022, Annex A). Any ISO 27001 risk treatment plan template built against the 2013 version must be updated to reference the revised control identifiers before a 2022-standard audit.

Core Fields of an ISO 27001 Risk Treatment Plan

• Risk ID

  Purpose: Links the RTP entry to the risk register. Audit evidence required: a consistent ID used across all documents.

• Treatment Option

  Purpose: Records the Mitigate / Transfer / Avoid / Accept decision. Audit evidence required: a decision record with rationale.

• Annex A Control Reference

  Purpose: Maps the treatment to a standard control. Audit evidence required: a Statement of Applicability entry cross-reference.

• Risk Owner

  Purpose: Assigns accountability for execution. Audit evidence required: a named individual, not a team label.

• Target / Completion Date

  Purpose: Tracks implementation progress. Audit evidence required: a status log or project record.

• Residual Risk Score

  Purpose: Confirms the risk has been reduced to appetite. Audit evidence required: a post-treatment reassessment record.

• Acceptance Sign-off

  Purpose: Records formal management approval. Audit evidence required: a signed form or meeting minutes.

Clause 8.3: Where Auditors Test for Execution

Clause 8.3 requires the organization to implement the information security risk treatment plan and retain documented information of the results.

The auditor can then trace a selected risk into the treatment plan and examine records supporting implementation. Depending on the treatment, those records may include approved changes, system configurations, completed activities, risk decisions, contracts, technical records, or other documented information relevant to the treatment.

The evidence should support the result that the organization records.

Applying Risk Treatment Options Consistently

ISO/IEC 27001 gives organizations flexibility in selecting appropriate treatment options. The treatment approach can involve changing the risk, avoiding the activity giving rise to the risk, sharing the risk with another party, or retaining the risk through an informed decision. The specific approach should follow the organization's defined risk treatment process and risk acceptance criteria.

Mitigate means applying one or more controls to reduce either the likelihood or impact of the risk to an acceptable residual level.

Avoid means eliminating the activity that creates the risk. This is appropriate when a process or system carries inherent risk that no realistic control set can reduce to an acceptable level.

Transfer moves relevant exposure to a third party, typically through cyber liability insurance or a contractual indemnity clause with a vendor. Note that ISO 27001 is explicit that accountability cannot be transferred — only the treatment can.

Accept is valid when the risk falls within appetite and the cost of treatment exceeds the expected loss. It requires a formal sign-off by a risk owner who has authority at the appropriate organizational level. If an accepted risk subsequently rises above appetite due to a threat-landscape change, the RTP must be updated and the acceptance decision revisited.

A practical ISO 27001 risk treatment plan example: a SaaS company identifies that its web application relies on an unpatched third-party library (inherent score: High). It chooses Mitigate, maps to Annex A control 8.8 (Management of technical vulnerabilities), assigns the DevSecOps lead as owner, sets a 30-day deadline, and documents a residual score of Low after a verified patch deployment.

Linking the RTP to Your Statement of Applicability and Risk Register

The Statement of Applicability (SoA) and the ISO 27001 risk treatment plan must remain bidirectionally consistent. A gap between them is one of the most common major nonconformities raised during ISO 27001 certification audits (Source: ISO/IEC 27001:2022, Clause 6.1.3d). Every control included in the SoA should be traceable to at least one risk treatment decision in the RTP, and every control selected in the RTP should appear in the SoA with its inclusion justified.

Risk register entries feed into the RTP, not the other way around. When a risk reassessment changes an inherent score — because a new threat emerges or a previously accepted vulnerability is exploited elsewhere in your sector — the corresponding RTP entry must be reviewed and potentially escalated. Build a documented review trigger into your ISO 27001 risk management process: at minimum, annual review, plus event-triggered review when a significant change or incident occurs.

Treatment dependencies are a gap most ISO 27001 risk treatment plan examples in the market ignore. Some controls cannot be activated until a prerequisite is in place — for instance, log monitoring (Annex A 8.15) depends on centralized log collection infrastructure. Document these dependencies as sequenced milestones within the RTP so that delays in foundational work are visible and can be escalated before they cascade into audit findings.

When a risk owner refuses to accept a residual risk that management has approved, or when a treatment cost exceeds the owner's budget authority, the RTP should specify an escalation path — typically to the Information Security Steering Committee or CISO.

What an Independent Certification Auditor Reviews in Your RTP

When an organization pursues ISO 27001 certification, an independent certification auditor examines the ISO 27001 risk treatment plan during both Stage 1 (documentation review) and Stage 2 (implementation audit).

At Stage 1, the auditor assesses whether the RTP exists as formal documented information, whether it covers all risks above the acceptance threshold, whether Annex A controls are correctly referenced and cross-linked to the SoA, and whether residual risk acceptance has management sign-off.

At Stage 2, the auditor shifts to execution evidence under Clause 8.3. For each sampled risk, they trace the "golden thread": risk register entry → treatment decision in Clause 6.1.3 → documented implementation evidence → residual risk reassessment. Common evidence types include configuration screenshots, patch deployment reports, signed insurance certificates, vendor contracts with security obligations, and management meeting minutes recording formal acceptance decisions.

Surveillance activities provide opportunities for the certification auditor to evaluate whether the ISMS continues to meet applicable requirements. Changes to the organization's context, information assets, technology, processes, suppliers, or other relevant conditions can affect information security risks and their treatment.

Common Nonconformities Linked to the RTP

• Missing or unnamed risk owners
• Treatment decisions not reflected in the Statement of Applicability
• Risk acceptance without documented management approval
• Residual risk not reassessed after treatment
• Evidence with no traceable record of review

Conclusion

An ISO 27001 risk treatment plan is not a compliance checkbox. It is the operational core of your Information Security Management System. It translates risk assessment findings into accountable actions, links every treatment decision to a specific Annex A control, and provides the evidence trail that an independent auditor needs to confirm that identified risks are genuinely managed rather than documented and forgotten.

For management, the practical test is traceability. A selected risk should lead to a treatment decision. That decision should lead to relevant controls or another documented treatment action. The treatment should lead to evidence of results. The resulting risk position should follow the organization's defined assessment and acceptance criteria. Organizations pursuing ISO 27001 certification should ensure their risk treatment plan satisfies both the planning requirements of Clause 6.1.3 and the execution evidence requirements of Clause 8.3 before engaging an independent certification auditor.

CertPro approaches ISO 27001 certification as an independent conformity assessment activity. Its certification auditors evaluate the ISMS against applicable ISO/IEC 27001 requirements through objective evidence and appropriate audit methods. CertPro's role remains independent from implementation activities. It evaluates conformity rather than designing or operating the service organization's ISMS.