The Risk Treatment Plan is a core component of the ISO 27001 ISMS, required by Clause 6.1.3. After completing your information security risk assessment (Clause 6.1.2), you must formulate a risk treatment plan that defines how each identified risk will be addressed. The treatment plan links risks to specific controls from Annex A (or other control sets), assigns ownership, sets timelines, and tracks implementation progress.
The Four Treatment Options
ISO/IEC 27005 defines four options for treating information security risks. Each risk in your register must be assigned one of these treatment decisions:
| Option | Description | Example | Key Consideration |
|---|---|---|---|
| Mitigate (Reduce) | Apply controls to reduce likelihood or impact to an acceptable level. The most common option, directly linking to Annex A controls. | Unauthorised access risk: implement MFA (A.8.5), access control policy (A.5.15), database monitoring (A.8.16) | Residual risk after controls must fall within risk acceptance criteria |
| Transfer (Share) | Transfer risk to a third party via insurance, outsourcing, or contractual arrangements. | Data breach liability: purchase cyber insurance while still implementing preventive controls | Transfers financial consequence only. Reputational damage and regulatory penalties cannot be transferred |
| Accept (Retain) | Formally accept the risk without additional treatment. Appropriate when risk is within appetite or treatment cost exceeds impact. | Minor service interruption to dev environment: accept as impact is low and HA cost disproportionate | Must be a documented decision approved by the risk owner. Auditors verify acceptance criteria are met |
| Avoid | Eliminate the risk by removing the activity or system that creates it. Most decisive but also most disruptive. | USB exfiltration risk: disable USB ports and block removable media via endpoint management | May impact business operations. Ensure the avoided activity is not required for compliance |
Risk Treatment Page in Venvera
The Risk Treatment Plan page (ISO 27001 > Risk Treatment) provides a dedicated interface for documenting and managing risk treatment decisions. The page displays the heading Risk Treatment Plan with the subtitle "Clause 6.1.3 — Link risks to Annex A controls with treatment decisions".
Status Summary Cards
At the top of the page, four summary cards display counts of risk treatments grouped by status:
| Status | Colour | Description |
|---|---|---|
| Open | Red | Risk identified and treatment planned but not yet started |
| In Progress | Yellow/Amber | Treatment actions are currently being implemented |
| Completed | Green | All treatment actions have been implemented and verified |
| Accepted | Grey | Risk has been formally accepted by the risk owner |
Risk Treatment List
Each risk treatment entry is displayed as a card showing the risk level badge (colour-coded: Critical = red, High = amber, Medium = orange, Low = green), the treatment option (Mitigate, Transfer, Accept, Avoid), the current status, the risk description, treatment description, linked Annex A control references, and the owner and due date. You can change the status of any treatment directly from the list using the status dropdown. The trash icon allows deletion of a treatment entry.
Adding a New Risk Treatment
Click the Add Risk button to open the treatment form. The form contains the following fields:
| Field | Type | Required | Description |
|---|---|---|---|
| Risk Description | Text area (2 rows) | Required | A clear description of the identified risk, including the threat, vulnerability, and potential impact |
| Likelihood | Dropdown | Optional | The assessed likelihood of the risk occurring. Options: Very Low, Low, Medium (default), High, Very High |
| Impact | Dropdown | Optional | The assessed impact if the risk materialises. Options: Very Low, Low, Medium (default), High, Very High |
| Risk Level | Dropdown | Optional | The overall risk level derived from likelihood and impact. Options: Low, Medium (default), High, Critical |
| Treatment | Dropdown | Required | The treatment decision. Options: Mitigate (default), Transfer, Accept, Avoid |
| Treatment Description | Text area (2 rows) | Optional | Detailed description of how the risk will be treated, including specific actions and controls to be implemented |
| Annex A Control Refs | Text input (comma-separated) | Optional | Comma-separated list of Annex A control references that address this risk (e.g., A.5.1, A.8.7). Links the treatment to the SoA |
| Owner | Text input | Optional | The person responsible for implementing and monitoring the treatment |
| Due Date | Date picker | Optional | Target date for completing the treatment actions |
Step-by-Step: Creating a Risk Treatment Plan
Before creating treatment entries, ensure you have completed your information security risk assessment (Clause 6.1.2). Each treatment should correspond to a risk identified during the assessment. Use the risk assessment results to populate the likelihood, impact, and risk level fields.
For each risk from your assessment, click Add Risk and enter the risk description. Write a clear, specific description that identifies the threat source, the vulnerability exploited, and the potential impact. For example: "Phishing attacks exploiting lack of email filtering could lead to credential compromise and unauthorised access to customer data."
Set the likelihood and impact ratings for each risk. These should align with your risk assessment methodology. The risk level field allows you to set the overall rating, which may be calculated from a risk matrix or set manually based on qualitative assessment.
Choose the appropriate treatment for each risk: Mitigate, Transfer, Accept, or Avoid. The treatment decision should be based on the risk level, the organisation's risk appetite, available resources, and the feasibility of implementing controls.
For each treatment, describe the specific actions that will be taken. For mitigated risks, list the controls to be implemented. For transferred risks, identify the transfer mechanism (insurance policy, outsourcing contract). For accepted risks, document the rationale. For avoided risks, describe how the activity will be eliminated.
For mitigated risks, enter the relevant Annex A control references in the Annex A Control Refs field as a comma-separated list (e.g., A.5.15, A.8.5, A.8.16). These references create a traceable link between the risk treatment plan and the Statement of Applicability, which auditors will verify during certification.
Every risk treatment must have a designated owner who is responsible for implementation and monitoring. Set realistic due dates based on implementation complexity and resource availability. The risk owner must have the authority and resources to implement the treatment.
Use the status dropdown on each treatment card to update progress as implementation proceeds: Open to In Progress to Completed (or Accepted for accepted risks). Regularly review the status summary cards to monitor overall treatment plan progress.
Linking to the Statement of Applicability
The risk treatment plan and the Statement of Applicability (SoA) are closely linked — Clause 6.1.3(d) explicitly requires the SoA. When you enter Annex A control references on a risk treatment, you are establishing the traceability chain that auditors expect:
- Risk identified in the risk assessment (Clause 6.1.2)
- Treatment decision documented in the risk treatment plan (Clause 6.1.3)
- Controls selected from Annex A (or other sources) to implement the treatment
- Applicability recorded in the SoA with justification for inclusion
- Implementation verified through internal audits and management reviews
This traceability chain is one of the most scrutinised elements during a certification audit. Ensure that every applicable control in the SoA can be traced back to at least one risk in the treatment plan, and that every mitigated risk references the controls that address it.
Risk Owner Approval
ISO 27001 requires that risk owners formally approve the risk treatment plan and accept the residual risks (Clause 6.1.3(f)). This means:
- The risk owner must understand the treatment proposed for each risk they own
- The risk owner must agree that the residual risk (after treatment) is acceptable
- This approval must be documented — record the risk owner in the Owner field
- For accepted risks, the approval is especially critical as no additional controls will be applied
Monitoring Treatment Effectiveness
The treatment plan is not a one-time activity. Continuously monitor effectiveness:
- Track status transitions: Monitor progress from Open to In Progress to Completed. Stalled treatments indicate resource issues.
- Review due dates: Escalate overdue treatments. Document reasons for any extensions.
- Reassess residual risk: After implementing controls, verify the residual risk is acceptable.
- Report in management reviews: Risk treatment status is a required input to Clause 9.3 management reviews.
- Internal audit coverage: Include the treatment plan in your audit programme to verify controls operate effectively.
Common Treatment Examples by Risk Category
| Risk Category | Example Risk | Treatment | Typical Controls |
|---|---|---|---|
| Access Control | Unauthorised access to sensitive systems due to weak authentication | Mitigate | A.5.15 Access control, A.5.16 Identity management, A.8.5 Secure authentication |
| Data Breach | Exfiltration of customer data through unencrypted channels | Mitigate | A.5.14 Information transfer, A.8.24 Use of cryptography |
| Ransomware | Ransomware attack causing loss of availability of critical systems | Mitigate + Transfer | A.8.7 Protection against malware, A.8.13 Information backup, plus cyber insurance |
| Supplier Failure | Critical supplier suffers data breach affecting shared data | Mitigate | A.5.19–A.5.22 Supplier security controls |
| Physical Security | Unauthorised physical access to server room | Mitigate | A.7.1 Physical security perimeters, A.7.2 Physical entry, A.7.4 Physical security monitoring |
| Legacy Systems | Unsupported operating systems with known vulnerabilities | Avoid | Decommission and migrate to supported platforms |
| Natural Disaster | Data centre outage due to flood or fire | Transfer + Mitigate | A.5.29 Information security during disruption, A.5.30 ICT readiness for business continuity, plus property insurance |