What is the Risk Treatment Plan and why is it mandatory?
ISO 27001:2022 Clause 6.1.3 requires organisations to produce a Risk Treatment Plan (RTP) — the document that connects your risk assessment (Clause 6.1.2) to your controls implementation and your Statement of Applicability (SoA). Without a compliant RTP, you cannot achieve ISO 27001 certification. Full stop.
Many organisations treat the RTP as a formality — a spreadsheet that lists risks and says "mitigate" next to each one. Auditors see through this immediately. A compliant RTP is a living management document that shows:
- A treatment decision for each risk (Mitigate / Transfer / Avoid / Accept)
- Which specific Annex A controls are applied to each risk
- Who owns each risk treatment action
- Target dates and current implementation status
- Residual risk after treatment — and why it's acceptable
- Formal acceptance of any residual risk above the acceptance criteria
The RTP is also the primary source document for the SoA. Every Annex A control you mark as "applicable" in the SoA should trace back to at least one risk in the RTP. If it doesn't, the auditor will ask why it's applicable — and you need a documented answer.
The Clause 6.1.3 exact requirements
Clause 6.1.3 states that the organisation shall define and apply an information security risk treatment process that:
- Selects appropriate risk treatment options, taking into account the risk assessment results and risk criteria
- Determines all controls necessary to implement the chosen risk treatment option(s)
- Compares the controls determined above with those in Annex A and verifies that no necessary controls have been omitted
- Produces a Statement of Applicability
- Formulates a risk treatment plan
- Obtains risk owners' approval of the risk treatment plan and acceptance of the residual information security risks
Point 3 is commonly misunderstood. You're not required to implement all of Annex A — you're required to check it to make sure you haven't missed a necessary control. If you've determined a control isn't applicable, you must justify that exclusion in the SoA. If you've determined it is applicable but not selected it in the RTP, the auditor will flag this as a gap.
Point 6 is often skipped entirely: risk owners must formally approve the treatment plan and formally accept residual risk. This requires documented sign-off, not just an internal consensus.
The four treatment options
| Treatment | What it means | When to use it | Common SaaS example |
|---|---|---|---|
| Mitigate | Apply controls to reduce likelihood or impact | The risk is material and within your control to reduce | Enforce MFA to reduce credential compromise likelihood |
| Transfer | Transfer the risk to a third party | Financial impact exceeds what you can absorb; residual risk is insurable | Cyber insurance policy; contractual liability caps in vendor agreements |
| Avoid | Eliminate the activity that creates the risk | The risk outweighs the business value of the activity | Stop collecting a data category that creates disproportionate GDPR risk |
| Accept | Formally document acceptance of the risk | Residual risk is below acceptance criteria; treatment cost exceeds benefit | Accept low-likelihood physical theft risk in a cloud-native company |
What auditors look for in the RTP
Stage 1 and Stage 2 auditors approach the RTP the same way: they trace a chain from risk → treatment → controls → SoA → evidence. If any link in that chain is missing or broken, it becomes an audit finding.
Traceability (Clause 6.1.3 chain)
The critical chain is:
- Risk identified in risk assessment → inherent score calculated
- Treatment decision documented (Mitigate/Transfer/Avoid/Accept)
- Specific Annex A controls selected to implement the treatment
- Controls marked as Applicable in the SoA with justification and status
- Controls implemented and evidence collected (Stage 2)
- Residual risk calculated post-treatment and accepted by risk owner
If your RTP says "apply MFA" but your SoA doesn't include A.8.5 (Secure authentication), auditors will raise a nonconformity. If your SoA includes A.5.24 (Incident management planning) but no risk in your RTP links to it, they'll ask how you justified it as applicable.
The 5 most common RTP audit findings
| Finding | What it means | How to fix it |
|---|---|---|
| Residual risk not calculated | RTP shows inherent risk but no post-treatment residual score | Add residual L×I scores for every risk; justify why residual is acceptable |
| Risk owner sign-off missing | No formal approval of treatment plan or residual risk acceptance | Document formal sign-off from named risk owners before Stage 1 |
| Controls too generic | RTP says "implement access controls" without specific Annex A references | Reference specific Annex A controls (e.g. A.8.2, A.5.18) for each risk |
| RTP/SoA inconsistency | Controls in RTP don't match included controls in SoA | Run a reconciliation exercise: every RTP control must appear as Applicable in SoA |
| No acceptance of residual risk | Risks above acceptance criteria with no documented management approval | Create a formal risk acceptance register for any risk above threshold |
How the RTP connects to the SoA
The Statement of Applicability (SoA) is the master list of all 93 Annex A controls with a decision: Applicable or Not Applicable. For each Applicable control: why it's included, what its implementation status is, what evidence exists. For each Not Applicable control: the justification for exclusion.
The RTP is the source of truth for which controls are applicable. The correct process is:
- Complete the risk assessment (Clause 6.1.2) — identify risks, score them
- For each risk, select treatment and specific Annex A controls
- After completing the RTP, extract the unique list of selected controls
- Use this list to populate the "Applicable" section of the SoA
- Check whether any remaining Annex A controls are applicable for reasons beyond the RTP (legal obligation, contractual, industry practice) — if yes, add them to SoA with justification
- For controls not selected in RTP and not applicable for other reasons, mark as Not Applicable with justification in SoA
This is the traceability chain Clause 6.1.3(a)(b)(c)(d) requires. Many organisations build the SoA in isolation from the RTP, which creates inconsistencies that auditors invariably catch.
Risk acceptance: what formal approval actually means
When a risk is accepted — either because the treatment option is "Accept" or because the residual risk after mitigation is above the acceptance criteria — Clause 6.1.3 requires formal acceptance from the risk owner. This doesn't mean a casual verbal agreement. Auditors expect:
- A named risk acceptance register (or risk acceptance section within the RTP)
- Named risk owner with title (not just "management")
- Explicit statement of the residual risk score and why it's being accepted
- Conditions of acceptance (e.g. "accepted pending cyber insurance renewal in Q3")
- Review date — accepted risks must be revisited at each risk assessment cycle
- Sign-off: either a signature or a documented approval (email or system record)
For cloud-native SaaS companies: the most common formally accepted risk is physical security — the risk of physical theft or physical intrusion to servers. Since all infrastructure is in a cloud provider's data centre, the residual risk after relying on the cloud provider's physical controls is low, but you still need to document the acceptance rather than leaving it blank.
When to update the RTP
The RTP is not a one-time document. ISO 27001:2022 requires it to be reviewed whenever:
- A new significant risk is identified (new system, new data type, new threat)
- A risk materialises into an incident
- A control is implemented (update status from Planned to Completed)
- A control fails or is found ineffective
- A significant organisational change occurs (acquisition, new product, geographic expansion)
- A change in the regulatory environment (new law, EDPB guidance, enforcement action in sector)
- At least annually as part of the management review cycle
In practice: most fast-growing SaaS companies update their risk register and RTP on a rolling basis, with a formal annual review documented for the management review. Ad hoc updates are triggered by incidents, security alerts, and significant product changes.
The ISO 27001 Risk Treatment Plan Generator builds a Clause 6.1.3-compliant RTP pre-loaded with 10 common SaaS risks, Annex A control selection, risk scoring, and formal acceptance register. Pair it with the ISO 27001 Risk Assessment Generator (Clause 6.1.2) and the ISO 27001 SoA Generator for a complete set of mandatory ISMS documentation.