ISO 27001 Risk Treatment Plan: Templates & SMB Guide
An ISO 27001 risk treatment plan is the operational backbone of your entire information security management system — without it, your risk assessment is just a document that collects dust. For SMBs navigating ISO 27001 certification for the first time, building a risk treatment plan that satisfies auditors while remaining practical for a lean team is one of the most challenging steps in the process. This guide breaks down exactly what belongs in your plan, provides a working template structure, and shows you how to move from risk identification to documented, auditable treatment decisions without hiring a room full of consultants.
What Is an ISO 27001 Risk Treatment Plan?
Under ISO/IEC 27001:2022, Clause 6.1.3 requires organizations to define and apply an information security risk treatment process. The risk treatment plan (RTP) is the formal output of that process — a structured document that records every identified risk, the treatment option selected, the controls applied, the control owner, implementation status, and residual risk acceptance.
Think of it this way: your risk assessment tells you what could go wrong. Your risk treatment plan tells you what you're doing about it and proves to an auditor that you've made deliberate, documented decisions rather than guessing.
The four treatment options defined by the standard are:
- Modify (Mitigate): Implement controls to reduce the likelihood or impact of the risk.
- Avoid: Eliminate the activity or condition that gives rise to the risk entirely.
- Share (Transfer): Transfer the risk to a third party, such as through cyber insurance or a managed security provider.
- Retain (Accept): Consciously accept the risk when the cost of treatment exceeds the potential impact, documented with formal sign-off.
Every risk in your register must be assigned one of these options. Leaving a risk without a documented treatment decision is a nonconformity waiting to happen.
Core Components of an ISO 27001 Risk Treatment Plan Template
A compliant RTP doesn't need to be a 200-page behemoth. For most SMBs, a well-structured spreadsheet or purpose-built platform entry covers everything an auditor needs to see. Here are the essential columns and fields your template must include:
1. Risk ID and Description
Each risk needs a unique identifier that ties back to your risk register. The description should be specific enough to be actionable — "unauthorized access to customer database via compromised credentials" is far more useful than "access control risk."
2. Risk Owner
Assign a named individual (not a team or department) who is accountable for ensuring the treatment is implemented and monitored. This is a common gap in SMB implementations — without a named owner, nothing gets done and auditors notice immediately.
3. Inherent Risk Score
Record the risk score before any controls are applied, typically expressed as a combination of likelihood and impact on your chosen scale (e.g., 1–5 × 1–5 = 1–25). This establishes the baseline that justifies your treatment decisions.
4. Treatment Option Selected
Document whether you are modifying, avoiding, sharing, or retaining the risk. If you're retaining a high-scoring risk, you'll need explicit sign-off from senior management — auditors will look for this.
5. Applicable Annex A Controls
ISO 27001:2022 Annex A contains 93 controls across four themes: Organizational, People, Physical, and Technological. For each risk you're mitigating, map the specific controls you're implementing. This linkage is critical — it's how you demonstrate that your Statement of Applicability (SoA) and your RTP are consistent with each other.
6. Implementation Details and Evidence
Describe how the control is being implemented, not just that it will be. "MFA enforced via Azure AD Conditional Access Policy, applied to all users with access to production systems" is auditable. "We will implement MFA" is not.
7. Target Completion Date and Status
Track whether each treatment action is planned, in progress, or complete. Auditors conducting surveillance audits will compare your current status against previous versions of the plan to verify continuous improvement.
8. Residual Risk Score
After controls are applied, re-score the risk. The residual score must fall within your organization's defined risk acceptance criteria. If it doesn't, you need additional controls or formal acceptance by the risk owner and management.
9. Risk Acceptance Sign-Off
For any risk being retained, or where residual risk remains above your acceptance threshold, document who approved the acceptance and when. This is a Clause 6.1.3(e) requirement and a frequent audit finding when missing.
Sample ISO 27001 Risk Treatment Plan Table Structure
Below is a simplified example of how a few rows in a working RTP might look for an SMB in a SaaS environment:
| Risk ID | Risk Description | Inherent Score | Treatment Option | Controls (Annex A) | Residual Score | Status |
|---|---|---|---|---|---|---|
| R-001 | Phishing attack leading to credential compromise | 20 (4×5) | Modify | A.8.5 (MFA), A.6.3 (Security Awareness Training) | 8 (2×4) | Complete |
| R-002 | Data breach via misconfigured cloud storage bucket | 25 (5×5) | Modify | A.8.9 (Configuration Management), A.8.20 (Network Security) | 6 (2×3) | In Progress |
| R-003 | Loss of availability due to single-region cloud dependency | 12 (3×4) | Share | A.8.14 (Redundancy) — partially via cloud SLA + cyber insurance | 9 (3×3) | Complete |
| R-004 | Insider threat — unauthorized data exfiltration by employee | 15 (3×5) | Modify | A.5.18 (Access Rights), A.8.12 (Data Leakage Prevention) | 10 (2×5) | Planned |
Common SMB Mistakes When Building a Risk Treatment Plan
Having reviewed hundreds of SMB compliance programs, the same failure patterns appear repeatedly. Avoiding these will save you significant rework before your Stage 2 audit:
- Treating the RTP as a one-time exercise: ISO 27001 requires your risk treatment plan to be reviewed at planned intervals and whenever significant changes occur. A plan last updated 18 months ago will raise immediate red flags.
- Disconnecting the RTP from the Statement of Applicability: Every control in your SoA that is marked "applicable" should trace back to at least one risk in your RTP. Gaps between these two documents are a classic nonconformity.
- Accepting high risks without documented justification: Retaining a risk scored 20 out of 25 without a written business justification and management sign-off is not acceptable. Auditors will probe this directly.
- Generic control descriptions: Listing "A.8.5 – Privileged Access Management" without describing how it's implemented in your specific environment provides no audit evidence. Be specific about tools, configurations, and scope.
- No linkage to asset or threat inventory: Your risks should be traceable to specific information assets and threat scenarios. If your RTP exists in isolation from your asset register, the logical chain of evidence breaks down.
Integrating Your Risk Treatment Plan with the Statement of Applicability
The Statement of Applicability (SoA) and the risk treatment plan are two sides of the same coin, and ISO 27001 auditors will review them together. The SoA lists all 93 Annex A controls, states whether each is applicable or excluded, and provides justification. Your RTP provides the risk-based justification for why applicable controls were selected.
A practical workflow for keeping these aligned:
- Complete your risk assessment and populate your risk register with scored risks.
- For each risk you're mitigating, select the relevant Annex A controls and document them in the RTP.
- Use the control selections from your RTP to populate the "included" column of your SoA, with the risk ID as the justification reference.
- For any Annex A controls you're excluding, document the business justification in the SoA — and verify that no unmitigated risk in your RTP actually requires that control.
- Review both documents together at every management review cycle.
Platforms like ComplyGuard automate this linkage, ensuring that when you update a risk treatment decision, the corresponding SoA entry is flagged for review — eliminating the manual reconciliation that causes most SMB compliance teams to fall out of sync.
How to Prioritize Risk Treatment for Resource-Constrained SMBs
Most SMBs cannot implement every control simultaneously. A risk-based prioritization approach keeps your program defensible while working within real-world constraints:
- Address critical risks first: Any risk with an inherent score above your acceptance threshold that involves customer data, regulatory obligations, or business continuity should be treated before lower-priority items.
- Leverage quick wins: Controls like MFA, patch management automation, and security awareness training deliver significant risk reduction at low cost and should be implemented early to demonstrate progress.
- Use risk sharing strategically: Cyber insurance and managed detection and response (MDR) services can transfer residual risk for threats that are expensive to fully mitigate internally — a legitimate and auditor-accepted approach.
- Document your rationale: When you defer a treatment action due to resource constraints, document the business reason, the interim compensating controls in place, and the planned remediation timeline. This demonstrates mature risk management rather than negligence.
The NIST Cybersecurity Framework offers complementary prioritization guidance that maps well to ISO 27001 risk treatment decisions, particularly for SMBs building their programs from the ground up.
Maintaining and Reviewing Your ISO 27001 Risk Treatment Plan
ISO 27001 Clause 10.2 requires continual improvement, and your RTP is a living document that must evolve with your threat landscape, business changes, and control effectiveness data. Build these review triggers into your ISMS calendar:
- Annual scheduled review as part of your management review process
- After any significant security incident or near-miss
- When onboarding new critical suppliers or changing cloud infrastructure
- Following changes to applicable legal or regulatory requirements
- When new threat intelligence indicates emerging risks relevant to your sector
Version control your RTP — auditors conducting surveillance audits will want to see how your plan has evolved and that you're acting on identified improvements. If you're managing this in a spreadsheet, maintain a changelog tab. If you're using a compliance platform, ensure audit trail functionality is enabled.
For SMBs comparing compliance automation options, our platform comparison page shows how ComplyGuard's continuous monitoring and automated evidence collection reduces the manual burden of keeping your RTP current between audit cycles.
Conclusion
A well-constructed ISO 27001 risk treatment plan is not just an audit requirement — it's a practical management tool that tells your team exactly what risks exist, what's being done about them, and who is accountable. For SMBs, the key is building a plan that is specific enough to satisfy a rigorous Stage 2 audit while remaining maintainable by a lean team without dedicated compliance staff. Use the template structure and prioritization approach outlined above, keep your RTP tightly linked to your SoA, and treat it as a living document rather than a certification checkbox.
ComplyGuard was built specifically to make this process faster and less painful for growing businesses. Our platform automates risk scoring, maps treatments to Annex A controls, generates your SoA in sync with your RTP, and maintains the audit trail you need for certification and surveillance audits — all without the six-figure consultant fees. Explore our pricing plans to see how ComplyGuard fits your budget, or talk to our compliance team to get a personalized walkthrough of how we can accelerate your ISO 27001 journey.
