Putting together a risk treatment plan is where your ISO 27001 Controls meet your real-world risks. It shows auditors and everyone on your team that you have a systematic way to handle the threats you’ve identified. Below, we’ll walk through each step in plain language, share tips drawn from real-world practice, and flag common pitfalls so you can avoid them.
1. Ground Your Plan in a Solid Risk Register
Before you can treat risks, you need a reliable risk register. If yours is missing details, rebuild it now:
Describe each risk in one sentence. Avoid vague labels like “data issue.” Instead, write “customer database exposed via unsecured backup.”
Score likelihood and impact on a 1 – 5 scale. Pick scales that make sense for your business. Document what “5” means for impact.
Assign a single owner. If two people are named, it often means no one feels accountable.
Tip: Review your register in a cross-functional meeting (IT, ops, finance) so you capture risk perspectives from every team.
2. Choose Your Treatment Strategy. Don’t Overthink It
ISO 27001 lets you avoid, reduce, transfer, or accept each risk. Use these guidelines:
Avoid when the risk stems from a non-critical activity. If you can stop doing something risky without harm, just stop.
Reduce for most business-critical risks. Select controls that directly address likelihood or impact.
Transfer by shifting risk to a third party or insurance. Be sure your contracts actually cover the exposures you transfer.
Accept only low-level risks that won’t hurt your operations or reputation.
Pitfall to avoid: blanket “accept” for everything because it feels easier. Auditors will ask why high-impact threats were never addressed.
3. Map Every Risk to One or More Annex A Controls
Once you’ve chosen “reduce” for a risk, link it to specific controls from Annex A. For a deeper overview of these controls, see our post on ISO 27001 Controls Explained.
Review Annex A and pick the smallest controls that fully mitigate the risk.
Document your selection in the SoA: list control codes, names, and a one-line rationale.
If a control covers multiple risks, note that, you’ll save time on evidence gathering.
Tip: Use a spreadsheet or our ISO 27001 Audit Checklist template with columns for Risk ID, Control ID, Rationale, Owner, Deadline. This becomes your living treatment tracker.
4. Flesh Out the Treatment Plan Document
Your treatment plan is not a high-level memo. It’s a working project plan with:
Column | What to Include |
---|---|
Risk ID & Name | Directly from your register |
Treatment Option | Avoid / Reduce / Transfer / Accept |
Control Reference | Annex A code(s) and short title |
Action Steps | What exactly needs to happen (e.g., “Configure MFA for all admins”) |
Owner | One person who drives the action |
Deadline | Date or sprint cycle (e.g., “By end of Q2” or “Sprint 12”) |
Status | Not started / In progress / Complete |
Evidence | Link to policies, screenshots, ticket IDs, or test results |
Tip: Treat the plan like any other roadmap. Review it weekly in your security stand-up so nothing slips through the cracks.
5. Implement Controls with Real-World Steps
When you roll out a control:
Communicate the change clearly: send an email or post in Slack explaining why and how it affects day-to-day work.
Document the new process in your policy repository, including screenshots if it’s a tool configuration.
Train affected teams with a 15-minute demo or video. Track attendance or completion.
Test the control yourself. For example, attempt to bypass a new firewall rule or request an unauthorized permission.
Pro tip: Pair each control implementation with a simple checklist that an auditor could follow to verify it works.
6. Monitor Progress and Adapt
A static plan is a dead plan. Build in recurring reviews:
Monthly health checks: Quick scan of tasks due, tasks completed, and new risks added.
Quarterly deep dives: Re-run risk assessments, confirm controls still make sense, and update your SoA.
After any incident: If something goes wrong, revisit your treatment choices immediately.
Note: Changes in technology, business model, or personnel often introduce new risks. Treat your plan as a living document.
7. Common Pitfalls and How to Avoid Them
Pitfall: Writing vague action steps like “Improve security.” Fix: Specify “Enable MFA for all user accounts and enforce 90-day password rotation.”
Pitfall: Letting controls languish after sign-off. Fix: Use calendar reminders or a lightweight ticketing system to nudge owners.
Pitfall: Excluding a control without rationale. Fix: In your SoA, explain why “Physical access logs” aren’t needed if you’re fully remote.
Pitfall: Overloading a single owner with too many actions. Fix: Distribute ownership where possible to keep accountability clear.
Examples by Control Category
To make risk treatment more tangible, here are a few examples organized by the four ISO 27001 control domains:
Organizational Controls (A.5)
Risk: Vendor contract terms missing security clauses.
Treatment Option: Reduce
Control: A.5.30 – Supplier relationships, information security in supplier agreements
Action Steps:
Update the supplier contract template to include security requirements within 30 days
Owner: Legal Counsel
Evidence: Signed templates and contract change logs
People Controls (A.6)
Risk: Employees are unaware of data handling policies.
Treatment Option: Reduce
Control: A.6.3 – Information security awareness, education, and training
Action Steps:
Launch mandatory online training for all staff by the end of the quarter
Owner: HR Manager
Evidence: Training completions in LMS and acknowledgment receipts
Physical Controls (A.7)
Risk: Unauthorized access to shared office space.
Treatment Option: Reduce
Control: A.7.2 – Physical entry controls
Action Steps:
Install badge readers on all main entrances within two weeks
Owner: Office Manager
Evidence: Badge reader installation report and access logs
Technological Controls (A.8)
Risk: Unencrypted data in backups
Treatment Option: Reduce
Control: A.8.22 – Encryption of information at rest
Action Steps:
Configure the backup server to encrypt all backups by default
Owner: Systems Administrator
Evidence: Backup server configuration screenshots and verification logs
Final Thoughts
An ISO 27001 risk treatment plan is your blueprint for action. It moves you from knowing the risks to taking concrete steps to reduce them. Keep it clear, keep it current, and make sure every entry has a living owner. That’s how you turn compliance requirements into genuine security improvements and breeze through the audit with confidence.
For a full step-by-step guide, visit our ISO 27001 Audit Checklist and see how these treatment concepts fit into the overall process. And if you’re expanding into broader compliance programs, check out How Compliance Risk Management Works.