Risk Treatment Plan: Definition, Requirements & ISO 27001 Guide

What Is a Risk Treatment Plan?

A risk treatment plan is a documented record of how an organization will respond to each risk that exceeds its acceptance criteria. For every risk, it states the chosen treatment option, the controls or actions that carry it out, the owner, the timeline, and the residual risk the risk owner accepts.

ISO/IEC 27001:2022 requires the plan under clause 6.1.3 and its implementation under clause 8.3. ISO/IEC 27005:2022 defines four treatment options: modify, retain, avoid, and share.

Methodology Reference Block

• Governing body: None for the concept. The framework owner defines the requirements (ISO/IEC for ISO 27001 and ISO 27005, NIST for SP 800-37 and SP 800-39).
• Formal equivalents: ISO/IEC 27001:2022 clauses 6.1.3 and 8.3; NIST SP 800-37 Rev. 2 risk response and Plan of Action and Milestones (POA&M); HIPAA Security Rule risk management standard, 45 CFR 164.308(a)(1)(ii)(B).
• Typical outputs: The plan, the Statement of Applicability (SoA), an updated risk register, and risk owner approval of residual risk.

Why a Risk Treatment Plan Matters to Security & Compliance Leaders

Auditors test whether each material risk traces to a treatment decision, and each decision to an implemented control. A plan with this traceability is core audit readiness evidence for ISO 27001 and supports risk evidence under SOC 2 and HIPAA.

The same record answers outside scrutiny. Enterprise procurement teams, vendor risk assessments, customer due diligence, and cyber insurance applications ask how risk decisions are made and who approved them. A current plan lets a CISO or vCISO answer without assembling documents under deadline, and supports alignment with regulators that expect a risk-based program.

Risks & Business Impact

• Audit failure risk: Controls or SoA exclusions with no risk rationale can produce nonconformities.
• Contractual exposure: Customer contracts and cyber insurance applications ask for evidence of a formal risk process.
• Regulatory penalties: Under HIPAA, failing to implement measures that reduce risks to a reasonable and appropriate level (45 CFR 164.308(a)(1)(ii)(B)) can compound findings in an investigation.
• Operational burden: Static spreadsheets drift from deployed controls, so each audit starts with reconstruction.
• Reputation risk: A breach traced to a known, untreated risk is harder to defend than one traced to an approved residual risk.
• Security exposure: Risks rated but never given an owner and date stay open indefinitely.

Requirements & Control Expectations

ISO/IEC 27001:2022 clause 6.1.3 sets the most specific expectations.

• Treatment options: Select an appropriate option for each risk that exceeds acceptance criteria and record the rationale.
• Control determination: Determine the controls needed, then compare them with Annex A (93 controls in 2022) to confirm none was omitted.
• Statement of Applicability: List the necessary controls, whether each is implemented, and the justification for any Annex A exclusion.
• Plan content and approval: For each risk, record the option, controls, owner, resources, target date, status, and expected residual risk. Risk owners approve the plan and accept residual risks.
• Evidence: Retain documented information on the process (clause 6.1.3) and results (clause 8.3), including implementation and test records.
• Monitoring and audit: Reassess at planned intervals and on significant change (clause 8.2). Auditors sample risks and trace each to a control.

Process Overview (Implementation Lifecycle)

1. Readiness assessment: Confirm the ISMS scope, risk criteria, and risk acceptance criteria exist before treating anything.
2. Gap analysis: List evaluated risks that exceed acceptance criteria, ranked by rating.
3. Option selection: Choose modify, retain, avoid, or share and record why.
4. Remediation planning: Select controls, update the SoA, assign owners and dates, and estimate residual risk.
5. Approval: Obtain risk owner sign-off on the plan and on accepted residual risk.
6. Control testing and audit: Implement controls, test that they operate as documented, and give auditors the plan, SoA, and evidence.
7. Ongoing monitoring: Track progress, re-rate residual risk, and update the risk register as the environment changes.

Common Misconceptions

• "The plan is the risk register." The register records risks and ratings. The plan records the response. Storing both in one tool works if each risk stays traceable to a decision, owner, and control.
• "Treatment means mitigation." Retaining, avoiding, and sharing risk are valid options when the rationale is documented.
• "The Statement of Applicability replaces the plan." The SoA lists controls and justifications. The plan schedules and assigns the work. ISO 27001 requires both.
• "Accepting a risk needs no paperwork." The risk owner's acceptance must be documented.

Framework Relationships & Crosswalks

Equivalency is limited. A plan built for one framework supports alignment with others and rarely satisfies them alone.

• ISO 27001 and ISO 27002: ISO 27001 requires the plan. ISO 27005 supplies the methodology, and controls are usually drawn from ISO 27002.
• NIST: SP 800-39 defines risk response. NIST SP 800-37 Rev. 2 documents unresolved findings in a POA&M, and SP 800-53 supplies controls.
• HIPAA: 45 CFR 164.308(a)(1)(ii)(B) expects security measures that reduce risks to a reasonable and appropriate level.
• PCI DSS, SOC 2, GDPR: PCI DSS v4.0 Requirement 12.3 expects formal risk management, SOC 2 CC9.1 addresses risk mitigation activities, and GDPR Article 35(7)(d) calls for risk measures in a DPIA.
• CMMC: NIST SP 800-171 underpins the control set, and 32 CFR Part 170 permits limited POA&Ms for specified requirements.

How Compliance Automation Platforms Support This

Spreadsheets break the links between risk, decision, and control as environments change. In Apptega's 2025 State of Continuous Compliance Report, 66% of providers primarily use GRC or compliance automation platforms, while only 16% rely mainly on spreadsheets.

• Control mapping: Link each risk and treatment to the framework controls it satisfies.
• Evidence collection: Attach configurations, policies, and test results to each treatment.
• Cross-framework alignment: Reuse one treatment across mapped frameworks.
• Continuous monitoring: Track status, owners, and residual risk continuously.
• Reporting: Produce treatment status reports for auditors and executives.

Apptega's Risk Manager captures impact, likelihood, and response type in structured fields with linked controls.

Real-World Use Cases

• MSSPs: A provider standardizes one treatment template across client environments. Foresite Cybersecurity starts client engagements with risk and gap assessments. In Apptega's Foresite case study, it reported a nearly 110% increase in managed compliance customers and a 40% increase in profitability per engagement in its first year.
• SaaS providers: One plan supports ISO 27001 certification and a SOC 2 examination. Shared risks are treated once, and security questionnaires draw on the same record.
• Healthcare: Treatment records for ePHI risks document the safeguards chosen under the HIPAA Security Rule and who accepted residual risk.
• Financial services: Examiners and customers ask for proof that risk acceptance was approved at the right level, and the plan supplies it.
• Government contractors: Open NIST SP 800-171 findings are tracked as POA&M items with milestones and owners, so they stay reportable under CMMC.

‍