ISO 27001 Clause 8.3 Information Security Risk Treatment is an operational control that requires organisations to implement the risk treatment plan defined in Clause 6.1.3. It requires formal evidence that chosen security controls effectively mitigate identified risks to an acceptable level through consistent execution and management oversight.
Attributes Table
| Attribute | Value |
|---|---|
| Control Type | Operational / Corrective |
| Information Security Properties | Confidentiality, Integrity, Availability |
| Cybersecurity Concepts | Protect, Respond |
| Operational Capabilities | Risk Management, Governance |
Implementation Difficulty & Cost
| Metric | Rating | Details |
|---|---|---|
| Difficulty | 4/5 | Requires cross-departmental coordination. |
| Implementation Cost | Medium-High | Costs depend on the selected security controls. |
| Primary Owner | CISO | Accountable for overall execution. |
| Secondary Owner | Risk Owners | Responsible for specific treatment actions. |
ISO 27002 Control Guidance
Implementing risk treatment involves more than just selecting controls. In my experience, physical security treatment must address tangible gaps found during site surveys. I look for upgraded locks, CCTV coverage, or secure areas that directly map back to a specific risk entry in your register.
Technical implementation focuses on the deployment of security tools. You should configure firewalls, encryption, and access management to meet the requirements of your Risk Treatment Plan (RTP). I often find that technical teams implement tools without checking if they actually lower the risk score.
Behavioral change is the hardest part of Clause 8.3. You must ensure staff follow new procedures. I look for evidence of targeted training or changes in workflow. If your treatment for “phishing” is just a policy update, you will likely fail your audit.
The Auditor’s Eye: Expert Insight
In my experience, Clause 8.3 is where many organisations stumble. I frequently see Risk Treatment Plans that are “ghost documents.” They list actions that nobody ever started. I look for Project Logs and Jira tickets as evidence of work. If you claim to have treated a risk by “implementing MFA,” I will conduct a System Walkthrough to verify that MFA is active for all users. Do not claim a risk is treated until the control is fully operational.
10 Steps to Implement Information Security Risk Treatment
-
Review the Planning Outputs
Start with the results from Clause 6.1.3. You must understand which risks need treatment and which controls you chose. I verify that this transition from planning to operation is documented clearly.
-
Assign Action Owners
Every risk treatment action needs a single name against it. Use Microsoft Planner or Jira to track these assignments. In my experience, shared responsibility usually means nobody does the work.
-
Define Specific Timelines
Set hard deadlines for each treatment action. I look for realistic dates that reflect the risk’s urgency. Avoid vague terms like “ongoing” for initial control implementation.
-
Allocate Necessary Resources
Ensure you have the budget and staff time. I check meeting minutes to see if the Board approved the resources for the RTP. Without resources, the plan is just a wish list.
-
Implement Annex A Controls
Deploy the technical and organisational controls you selected. I verify these against your Statement of Applicability (SoA). Ensure the configuration matches the risk mitigation requirement.
-
Update the Risk Register
Record the progress of each treatment action. I look for a “Status” column in your risk register. This provides a real-time view of your security posture.
-
Verify Control Effectiveness
Test the controls once they are in place. Use vulnerability scanners or internal audits. I want to see proof that the control actually works as intended.
-
Calculate Residual Risk
Re-score the risk after implementing the control. The new score should fall within your risk appetite. I often find that firms forget to update their scores after treatment.
-
Obtain Risk Owner Sign-off
The risk owner must formally accept the residual risk. I look for email approvals or signed documents. This ensures management understands the remaining exposure.
-
Maintain an Audit Trail
Keep all evidence of the treatment process. I look for historical records of how a risk moved from “Critical” to “Low.” This is vital for your external audit.
Requirements by Environment
- Office: Physical implementation of controls like badge readers or shredding bins.
- Home: Rollout of VPNs and endpoint protection on remote hardware.
- Cloud: Configuration of Security Groups, IAM roles, and logging in AWS or Azure.
The “Checkbox Compliance” Trap
| Requirement | SaaS Tool Trap | Auditor Reality |
|---|---|---|
| Risk Treatment | Clicking “Done” in a compliance dashboard. | I need to see the actual system configuration or policy in use. |
| Owner Assignment | Automated “AI” owner suggestions. | The owner must actually know they are responsible and have authority. |
| Residual Risk | Auto-calculating scores based on templates. | Scores must reflect your unique business impact and threat level. |
10 Steps to Audit Clause 8.3 (Internal Audit Guide)
- Verify the Link: Ensure every item in the RTP matches a risk identified in Clause 8.2.
- Sample Completed Actions: Pick three “completed” treatments and ask for physical proof.
- Check Timelines: Look for overdue items in the RTP and ask why they stalled.
- Interview Owners: Ask a risk owner to explain how their specific control reduces risk.
- Review Residual Scores: Ensure the scoring logic remains consistent after treatment.
- Check Board Reporting: Verify that treatment progress is reported to senior management.
- Examine the SoA: Ensure the SoA reflects the current operational status of controls.
- Look for Workarounds: Check if staff are bypassing new controls because they are too restrictive.
- Validate Sign-offs: Ensure residual risk acceptance is signed by someone with the right authority.
- Review Resource Use: Check if the budget allocated was actually spent on security.
8.3 Audit Evidence Checklist
| Evidence Item | Pass/Fail Criteria | Owner |
|---|---|---|
| Risk Treatment Plan | Must be documented and show progress status. | CISO |
| Control Implementation Records | Tickets or logs showing a control was deployed. | IT Manager |
| Residual Risk Acceptance | Formal sign-off for risks above the “Low” threshold. | Risk Owner |
Required Policy Content: A Lead Auditor’s Checklist
- Treatment Methodology: Define the four options (Treat, Tolerate, Transfer, Terminate).
- Escalation Path: State what happens when a risk treatment deadline is missed.
- Authority Matrix: Define who has the power to accept residual risks at different levels.
- Review Cycle: Establish how often the RTP must be formally reviewed by management.
- Documentation Standards: Define the minimum evidence required to close a treatment action.
What to Teach Employees
- The Why: Explain how specific controls protect their daily work.
- Control Operation: Training on how to use new security tools properly.
- Feedback Loop: How to report if a control is hindering business operations.
Enforcement and Consequences
Failure to execute the Risk Treatment Plan is a Major Non-Conformity. I follow a strict path for non-compliance: Verbal Warning for minor documentation delays, Written NC for missed treatment actions, and Certification Suspension if the RTP is ignored. Risk owners who fail to implement agreed controls should face disciplinary action per your HR policy.
Common Implementation Challenges
| Challenge | Root Cause | Solution |
|---|---|---|
| Budget Constraints | Lack of management buy-in. | Link risk treatment to business continuity and revenue. |
| Shadow IT | Staff implementing tools outside the ISMS. | Centralise procurement and conduct regular discovery scans. |
| Risk Fatigue | Too many “High” risks at once. | Prioritise treatment based on the highest impact first. |
Sample Statement of Applicability (SoA) Entry
“Clause 8.3 is applicable as we must operationalise our risk treatment strategy. We maintain a live Risk Treatment Plan within our GRC tool, assigning owners and deadlines to all identified risks. Management reviews treatment progress monthly to ensure our residual risk remains within acceptable limits.”
Changes from ISO 27001:2013
| 2013 Version | 2022 Version |
|---|---|
| Clause 8.3 (Implementation of RTP) | Clause 8.3 (Direct alignment with 6.1.3 updated requirements) |
| Focus on generic controls. | Increased focus on the effectiveness of specific chosen controls. |
How to Measure Effectiveness (KPIs)
- RTP Completion Rate: Percentage of treatment actions finished by the target deadline.
- Residual Risk Trend: The total count of risks above appetite over a 12-month period.
- Control Failure Rate: Frequency of incidents occurring where a “treated” risk was the cause.
Related ISO 27001 Controls
- ISO 27001 Clause 6.1.3: This planning clause provides the framework that Clause 8.3 executes.
- ISO 27001 Annex A 5.1: Risk treatment often results in the creation of new security policies.
- ISO 27001 Annex A 8.8: Vulnerability management is a core technical treatment for most IT risks.
ISO 27001 Clause 8.3 FAQ
Can we choose to do nothing about a risk?
Yes, this is called “Risk Acceptance” or “Tolerating.” However, you must document the justification and get formal sign-off from the Risk Owner.
Is Clause 8.3 just about Annex A controls?
No. While Annex A is the standard set, you can implement any control you deem necessary to mitigate the risk effectively.
How often should the Risk Treatment Plan be updated?
It should be a living document. In my experience, you should review it at least quarterly or whenever a major business change occurs.
What is the difference between Clause 8.2 and 8.3?
Clause 8.2 is about finding and scoring risks (Assessment). Clause 8.3 is about doing something about them (Treatment).
What happens if a risk treatment is too expensive?
You can seek alternative controls, transfer the risk via insurance, or accept the risk if the Board agrees. You cannot simply ignore it.