You've attended the compliance briefing. You know what ISO/IEC 27001 Clause 6.1.3 requires. You understand SOC 2's CC3.1 risk assessment obligations. But when it's time to document how your team actually treats identified risks, many organizations default to a spreadsheet that mirrors their compliance checklist.
This is the compliance mentality at work: treating risk management as a documentation exercise rather than a decision-making framework.
This template provides a Risk Treatment Plan structure that separates genuine risk decisions from checkbox compliance. Use it to document how leadership chooses to address security risks based on business context, not just framework requirements.
Purpose of the Template
A Risk Treatment Plan documents the decisions your organization makes about identified information security risks. ISO/IEC 27001 Clause 6.1.3(e) requires you to define a risk treatment process and apply it. SOC 2 Trust Services Criteria expect you to respond to identified risks in a way that aligns with your risk appetite.
This template structures those decisions in a format that:
- Separates risk treatment decisions from control implementation details
- Forces explicit ownership and timeline commitments
- Links treatment choices to business justification, not just compliance requirements
- Creates an audit trail that shows leadership involvement in security decisions
Use this when you've completed your risk assessment and need to document what you're doing about the risks you found.
Prerequisites
Before you customize this template, ensure you have:
A completed risk assessment. You can't treat risks you haven't identified and evaluated. Your assessment should include threat scenarios, likelihood/impact ratings, and inherent risk scores.
Defined risk appetite statements. Your leadership team needs to document what levels of risk are acceptable in different contexts. Without this, every treatment decision becomes arbitrary.
Control baseline documentation. Know what controls you already have in place. ISO/IEC 27001 Annex A or SOC 2 Trust Services Criteria provide starting frameworks, but you need to know your current state.
Clear ownership structure. Each risk needs an owner with authority to make treatment decisions and allocate resources. This can't be the compliance team alone.
The Template
RISK TREATMENT PLAN
Organization: [Your Organization Name]
Plan Period: [Start Date] to [Review Date]
Prepared by: [Name, Role]
Approved by: [Name, Role, Date]
---
RISK ID: [Unique identifier from your risk register]
RISK DESCRIPTION: [Concise statement of the risk scenario]
INHERENT RISK RATING: [Your scale: e.g., High, Medium, Low or numerical]
RISK OWNER: [Name and role of the person accountable for this risk]
TREATMENT DECISION: [Select one]
□ Modify (implement or improve controls to reduce likelihood or impact)
□ Retain (accept the risk as-is based on current risk appetite)
□ Avoid (eliminate the activity that creates the risk)
□ Share (transfer risk through insurance, contracts, or third parties)
BUSINESS JUSTIFICATION:
[Why this treatment option makes sense for your organization. Reference risk appetite, business constraints, regulatory obligations, or resource availability. This section should show leadership thinking, not compliance checking.]
---
IF MODIFY IS SELECTED:
PLANNED CONTROLS:
Control ID | Control Description | Implementation Owner | Target Date | Residual Risk Rating
[C-001] | [Specific control activity] | [Name, Role] | [MM/DD/YYYY] | [Expected rating after control]
RESOURCE REQUIREMENTS:
- Budget: [Amount or "existing budget"]
- Personnel: [FTE, contractors, or "existing staff"]
- Technology: [Tools, licenses, infrastructure]
DEPENDENCIES:
[What needs to happen first? Vendor selection, budget approval, hiring, other projects?]
VALIDATION METHOD:
[How will you verify the control works? Testing approach, metrics, audit procedures.]
---
IF RETAIN IS SELECTED:
ACCEPTANCE CRITERIA:
[Why is this risk within appetite? Cite specific risk tolerance thresholds or business decisions.]
MONITORING PLAN:
[How will you track this risk over time? Frequency, metrics, trigger points for reassessment.]
ACCEPTED BY: [Name, Role, Date]
[This must be someone with authority to accept risk on behalf of the organization]
---
IF AVOID IS SELECTED:
PLANNED ACTIONS:
[What activities will you stop or change to eliminate this risk?]
BUSINESS IMPACT:
[What capabilities or services does this affect?]
IMPLEMENTATION OWNER: [Name, Role]
COMPLETION DATE: [MM/DD/YYYY]
---
IF SHARE IS SELECTED:
SHARING MECHANISM:
□ Cyber insurance policy: [Policy details, coverage limits]
□ Contractual transfer: [Contract type, counterparty]
□ Third-party service: [Provider, service scope]
RESIDUAL RISK:
[What risk remains after sharing? Insurance doesn't eliminate risk, it transfers financial impact.]
MONITORING REQUIREMENTS:
[How will you verify the sharing arrangement remains effective? Policy renewals, contract reviews, vendor assessments.]
---
REVIEW SCHEDULE:
Next scheduled review: [MM/DD/YYYY]
Review frequency: [Quarterly, semi-annually, annually, or event-triggered]
Review owner: [Name, Role]
CHANGE LOG:
Date | Changed By | Change Description
[MM/DD/YYYY] | [Name] | [What changed and why]
Customizing the Template
Start with risk ID and description. Pull these directly from your risk register. Don't rewrite the risk scenario; keep the link explicit so auditors can trace treatment decisions back to identified risks.
Choose treatment based on business context, not ease. The compliance mentality defaults to "Modify" because it feels productive. Sometimes the right answer is "Retain" because the cost of additional controls exceeds the risk. Make leadership sign off on retention decisions; that's where the culture shift happens.
Write business justification in plain language. This section separates teams that think about risk from teams that copy framework language. If you can't explain why this treatment makes sense for your organization specifically, you're still in compliance mode.
Make resource requirements explicit. Vague commitments like "implement MFA" don't become real controls. Specify the tool, the budget, the person configuring it, and the deadline. ISO/IEC 27001 Clause 6.2 requires you to determine resources needed for the ISMS; this is where you document them for risk treatment.
Assign ownership to people who can act. Risk owners need authority to allocate resources and make decisions. If every risk is owned by the CISO, you haven't distributed accountability. If every risk is owned by compliance staff who can't approve budget, you've created a documentation exercise.
Set realistic timelines. Auditors look for evidence that you're implementing your own plan. If you document a 30-day implementation timeline and you're still working on it six months later, you've created an audit finding. Better to document a six-month timeline with quarterly milestones.
Validation Steps
Before you finalize the plan:
Check ownership assignments. Every risk must have a named owner. Every planned control must have a named implementation owner. No "TBD" or "Security Team" placeholders.
Verify leadership approval on retention decisions. ISO/IEC 27001 Clause 6.1.3(d) requires risk owners to accept residual risks. SOC 2 expects entity-level oversight of risk decisions. If you're retaining a High-rated risk, someone above the risk owner should sign off.
Confirm resource commitments are realistic. Cross-reference your planned controls against your approved budget and staffing plan. If the resources aren't allocated, the plan isn't implementable.
Test the audit trail. Can you trace from a risk in your register, through this treatment plan, to a specific control in your Statement of Applicability (for ISO/IEC 27001) or your system description (for SOC 2)? If the links are broken, you'll spend audit time reconstructing your logic.
During implementation:
Update the change log when treatment decisions change. Your risk landscape shifts. New threats emerge. Budget gets reallocated. Document why you changed course; that's evidence of active risk management, not compliance failure.
Review the plan at the frequency you documented. If you committed to quarterly reviews, put them on the calendar and document what you reviewed. ISO/IEC 27001 Clause 9.3 management review expects you to consider risk treatment progress.
Track completion against your own deadlines. Your auditor will compare planned dates to actual implementation. Variance isn't automatically a finding, but unexplained variance is.
At audit time:
Walk your auditor through one complete example: risk identified in assessment, treatment decision documented in this plan, control implemented and operating, evidence of effectiveness. That narrative demonstrates that your risk treatment process is functional, not theoretical.
Show evidence of leadership involvement in treatment decisions. Meeting minutes where risk retention was discussed, budget approvals for control implementation, executive sign-off on the plan itself. Leadership tone matters more than documentation completeness.
Be ready to explain treatment decisions that don't match framework defaults. If you retained a risk that most organizations would modify, or if you avoided an activity that's common in your industry, auditors will ask why. Your business justification section should give you the answer.
This template won't fix a compliance mentality by itself. But it gives you a structure that makes genuine risk thinking visible and makes checkbox compliance harder to hide behind.
