Audit Ready ISO 27001 Risk Treatment Plan Template for ISMS Teams

A risk treatment plan under ISO/IEC 27001 clause 6.1.3 is the documented set of decisions that connects each identified risk to a chosen control, a named owner, a deadline, and proof the control works. Auditors check three things first: whether your controls map to Annex A or an equivalent framework, whether residual risk carries a signed acceptance, and whether you can show evidence of verification. Your next move is simple: pull your top 10 risks from the register and flag which ones still lack a documented treatment decision.

TL;DR:

• Clearly link each risk to a specific control, an owner, and verification evidence, as auditors require proof of implementation and ongoing effectiveness.
• Prioritize risks based on impact and likelihood, while considering asset criticality and compliance deadlines, to focus treatment efforts effectively.
• Document residual risk acceptance with signed approval from a designated owner, applying predefined thresholds for escalation to higher management levels.
• Regularly verify controls through documented tests, automated scans, or third-party assessments, and update the risk register and statement of applicability accordingly.
• Use a structured template with specific fields for each treatment entry, ensuring traceability, evidence storage, and consistent, auditable decisions.

Table of Contents

• What a risk treatment plan is and where it fits in ISO 27001
• Step-by-step process to build an ISO 27001 risk treatment plan
• Mapping treatment choices to Annex A and producing the Statement of Applicability
• Residual risk, acceptance rules, and decision authority
• Monitoring, review, and closure of treatment actions
• Practical RTP template: required fields and a worked example entry
• What practitioners underestimate about risk treatment plans
• Plan your risk treatment work with real numbers, not guesswork
• FAQ
• Sources

What a risk treatment plan is and where it fits in ISO 27001

A risk treatment plan is not another name for your risk register, and conflating the two is one of the most common gaps auditors flag during certification audits. The risk register is an inventory: it lists risks, their likelihood, their impact, and a score. The risk treatment plan is a decision record: it says what you are doing about each risk that crossed your acceptance threshold, who owns the action, and what evidence proves it happened.

ISO/IEC 27001 clause 6.1.2 requires a documented risk assessment process with consistent, comparable results. Clause 6.1.3 picks up from there: once risks are assessed, you select treatment options, choose controls, compare those controls against Annex A to confirm nothing necessary was missed, and produce a Statement of Applicability justifying every inclusion and exclusion. The auditing practices note on Annex A frames this clearly: Annex A functions as a comparison baseline under subclause 6.1.3©, not as a checklist you work through top to bottom.

This distinction matters because auditors read the risk treatment plan, not the register, when they want to know whether your management system is doing anything. A long risk register with no corresponding treatment decisions reads as an unmanaged backlog. A deeper breakdown of how risk assessment methodology feeds into this stage is covered in our risk assessment methodology guide.

At minimum, auditors expect to see:

• A mapping between each treated risk and the specific Annex A control, or alternative control set, addressing it
• A documented acceptance decision for residual risk, signed by a named risk owner
• Verifiable evidence that selected controls were actually implemented, not just planned

Skip any of these three and the finding is almost guaranteed. The SC27 guidance on documented criteria reinforces that acceptance criteria need to be defined in advance and applied consistently, not improvised risk by risk.

Step-by-step process to build an ISO 27001 risk treatment plan

Building a defensible risk treatment plan follows a sequence. Skipping steps to save time almost always costs more time later, when an auditor asks a question your documentation cannot answer.

1. Define risk acceptance criteria and decision authority. Before treating anything, agree on what “acceptable” means in numerical or categorical terms, and decide who has the authority to accept residual risk at each severity level. Without this, every treatment decision downstream is arbitrary.
2. Prioritize which risks to treat now. Not every risk above your threshold needs immediate attention. Rank by impact multiplied by likelihood, then adjust for asset criticality and compliance pressure, since a low-score risk tied to a regulatory deadline often outranks a higher-score risk on a system nobody depends on.
3. Choose a treatment option and select controls. For each prioritized risk, pick one of the four classic options: avoid, mitigate, transfer, or accept. For mitigation, use Annex A as your first reference point and bring in supplementary sets like ISO/IEC 27017 or NIST SP 800-53 where Annex A does not go deep enough for a specific technical risk.
4. Document the RTP entry in full. Capture the control reference, the owner’s name, the resources required, a deadline, the verification method, and the expected residual score. An entry missing any of these fields is incomplete, not just thin.
5. Implement the controls and collect verification evidence. This is where plans turn into audit trails: configuration snapshots, change tickets, test reports, or screenshots of settings that prove a control is live, not just approved.
6. Update the risk register and the Statement of Applicability, then record acceptance or closure. The loop only closes when the register reflects the new residual score and the SoA reflects the final control decision.

Pro Tip: Batch similar risks by control family before starting step 3. Treating five access-control risks together usually surfaces one control change that resolves all five, instead of five separate half-measures.

The sequence above deliberately separates decision-making (steps 1 through 3) from documentation and execution (steps 4 through 6), because teams that blend them tend to implement controls before confirming they are the right ones. For risks specific to project phases rather than steady-state operations, our guide to ISO 27001 project risks walks through examples that commonly surface during implementation rather than in daily operations.

Organizations running continuous monitoring programs alongside ISO 27001 often borrow structure from the NIST Risk Management Framework, whose seven steps (Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor) parallel the ISO sequence closely enough that teams managing both frameworks can reuse much of the same evidence base. RMF’s emphasis on identifying common controls available for inheritance is worth borrowing even if you never adopt RMF formally: if one control satisfies multiple risks or multiple systems, document that once and reference it everywhere, rather than duplicating the justification in every RTP entry.

For teams weighing whether to keep verification entirely in-house, managed services covering continuous monitoring and incident response can absorb some of the evidence-collection burden for critical controls, particularly where 24/7 coverage is hard to staff internally.

Mapping treatment choices to Annex A and producing the Statement of Applicability

The Statement of Applicability is where your treatment decisions become auditable. Every control you selected, and every Annex A control you did not select, needs a justification recorded against it. The Annex A auditing practices note is explicit that Annex A exists to be compared against your risk assessment results, not treated as an exhaustive master list you must exhaust before you are done.

That means two things in practice. First, Annex A is a baseline: if your assessment surfaces a risk that no Annex A control addresses well, pulling in a supplementary framework such as ISO/IEC 27017 for cloud-specific controls, PCI-DSS for payment data, or NIST SP 800-53 for a more granular technical control is acceptable, provided you document why. Second, excluding an Annex A control is equally acceptable when the risk it addresses genuinely does not apply to your organization, but “not applicable” needs its own justification line, not a blank cell.

A deeper walkthrough of how to interpret individual Annex A groupings is in our Annex A controls explainer, which pairs well with the mapping work described here.

For each RTP entry, record the Annex A reference (or the external standard clause) alongside:

• The specific risk it addresses, by risk ID
• The justification for inclusion or exclusion, in plain language an outside auditor can follow without context
• The implementation status and a pointer to verification evidence, not a narrative description of intent
• The SoA line number it corresponds to, so the two documents stay traceable to each other

An auditor-ready SoA entry answers four questions without follow-up: which control, why selected or excluded, what state it is in, and where the proof lives. If any of those requires the auditor to ask, the entry needs more work before the audit, not during it.

Residual risk, acceptance rules, and decision authority

Residual risk is what remains after a control is applied: inherent risk, minus the risk reduction the control delivers, equals residual risk. The arithmetic is simple; the governance around it is where organizations stumble.

Acceptance of residual risk is not a documentation formality. It needs a named owner, typically the risk owner identified during assessment, though escalation to a designated executive is appropriate once residual severity crosses a predefined threshold. The SC27 journal guidance ties this back to clause 6.1.2’s requirement for documented, consistently applied acceptance criteria, set in advance rather than negotiated after the fact.

Practical, non-prescriptive thresholds look something like this: residual risks scoring low can be accepted by the risk owner directly, medium residual risks need sign-off from a department head or security lead, and high residual risks escalate to an executive or risk committee regardless of how strong the mitigating controls already in place appear. Your own thresholds should reflect your risk appetite statement, not a generic scale borrowed from a template.

To keep acceptance decisions audit-ready:

• Record the accepting individual’s name, role, and the date of acceptance directly in the RTP entry
• Link the acceptance record to the specific residual score it applies to, not to the inherent score
• Note the review date, since acceptance is not permanent and should expire or renew on a schedule
• Store the sign-off artifact (an email approval, a signed form, a workflow ticket) somewhere retrievable during an audit, not buried in a chat history

Monitoring, review, and closure of treatment actions

A treatment plan that is accurate on the day it is written and stale six months later is still a finding waiting to happen. Verification needs to be routine, not a one-time event tied to the audit calendar.

Reasonable verification methods include internal testing, automated configuration monitoring, and periodic third-party assessment for higher-risk controls. Record each verification instance against the RTP entry it supports, with a date and a result, not just a status flag.

A workable reporting cadence tracks the percentage of treatment actions closed on time and samples a subset of implemented controls each quarter to confirm they still function as documented, rather than attempting to re-verify everything at once.

• Re-run the risk assessment, or at least the affected entries, after major changes: new systems, incidents, significant staff turnover in risk-owning roles, or regulatory shifts
• Treat periodic review (commonly annual, more often for high-risk entries) as the floor, not the ceiling, for revisiting treatment decisions
• Use a tracked plan of action and milestones structure for anything not yet closed, so partial progress is visible rather than invisible until the deadline passes
• Close entries only once verification evidence, not just implementation, is on file

Pro Tip: Keep a running log of trigger events (incidents, major changes, new vendors) separate from your calendar-based review schedule. Trigger-based reviews catch the risks that a fixed annual cycle misses entirely.

The NIST RMF’s continuous monitoring step mirrors this logic closely: RMF guidance treats monitoring as ongoing rather than periodic, which is a useful mental model even for organizations running ISO 27001 without adopting RMF formally.

Practical RTP template: required fields and a worked example entry

A usable risk treatment plan entry needs a consistent set of fields, regardless of the tool or spreadsheet holding it. At minimum: risk ID, description, inherent risk score, treatment option, chosen controls with Annex A (or equivalent) reference, owner, required resources, deadline, verification method, residual risk score, acceptance evidence, and current status.

Below is a worked example for a common IT risk: unpatched internet-facing servers.

This single entry demonstrates the pattern you want across your whole plan: specific controls, not vague mitigation language, a verification method that produces a dated artifact, and a residual score that reflects what the controls actually reduced risk to, not an assumption that treatment equals elimination.

• Common evidence types: scan reports, change tickets, signed approval forms, configuration exports, and third-party assessment letters
• Store evidence where it is retrievable by risk ID, whether that is a shared drive folder, a GRC tool, or ticketing system links embedded directly in the RTP row
• Avoid narrative-only evidence (“patching is handled by the team”) since auditors look for artifacts with dates, not descriptions of process

Teams gathering evidence for backup and recovery controls specifically may find structured review prompts, like the backup and ransomware resilience review, useful for standardizing what “verified” looks like before it goes into the RTP.

What practitioners underestimate about risk treatment plans

The gap I see most often is not a missing control, it is a missing owner or missing evidence. Teams pick the right Annex A reference and still fail audits because nobody can show who approved the residual risk or produce proof a control actually runs. Generic, templated controls applied without tailoring to the actual asset are the second most common weakness.

Automated readiness checks and maturity assessments earn their place at the triage stage, helping you decide where to spend forensic-level evidence effort versus where a lighter touch is defensible. Full documentation rigor belongs on your highest-severity risks; everything else needs enough evidence to satisfy an auditor’s question, not a legal deposition.

— Martin

Plan your risk treatment work with real numbers, not guesswork

Estimating how much time and budget an ISO 27001 risk treatment program actually needs is harder than writing the plan itself, which is why we built a real-time cost and effort calculator that adjusts for your company size, industry, and current security maturity. Instead of guessing at engineer-days per control family, you get tailored estimates benchmarked against organizations in your sector.

Toolkits may include a maturity assessment spanning ISO domains, helping identify which areas need the heaviest treatment investment before committing resources, plus customizable Gantt charts for sequencing implementation phases once RTP priorities are set. If you want a fast gut check before building out a full plan, our free 2-minute readiness check flags gaps without requiring a signup, and you can save and compare multiple estimates as your scope evolves. For a more structured scoping exercise, our readiness assessment goes deeper than the quick check.

• Run the instant cost calculator to size the resourcing your RTP will need
• Use the maturity assessment to identify which of the four Annex A control themes need treatment priority
• Export Gantt timelines to sequence implementation against your deadlines

FAQ

What is a risk treatment plan?

A risk treatment plan is the documented set of decisions, controls, owners, and evidence that addresses each risk identified during an ISO/IEC 27001 risk assessment. It connects directly to clause 6.1.3 and feeds the Statement of Applicability, distinguishing it from the risk register, which only inventories and scores risks.

What are the 5 components of ERM?

Enterprise risk management frameworks vary by model, but most describe components covering governance and culture, strategy and objective-setting, risk identification and assessment, risk response (including treatment), and monitoring and review. ISO 27001’s risk treatment process maps most directly to the response and monitoring components of broader ERM models.

What are the 5 steps to a risk management plan?

A practical risk management plan generally follows identification, assessment, treatment selection, implementation with documentation, and ongoing monitoring and review. Within ISO 27001 specifically, this sequence runs from the clause 6.1.2 risk assessment through the clause 6.1.3 treatment decisions and into continual improvement under clause 10.

What are the 7 steps of RMF?

The NIST Risk Management Framework defines seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor. These steps emphasize continuous monitoring and integration with the system development lifecycle, and organizations running both NIST and ISO frameworks often align RMF’s monitoring step with their ISO treatment review cycle.

How do you calculate residual risk in ISO 27001?

Residual risk is the risk remaining after a chosen control reduces the inherent risk, and it should be recorded as a distinct score in the risk treatment plan rather than assumed to be zero. Each residual score needs a named owner’s acceptance before the risk can be considered closed.

Sources

• Auditing practices note — Annex A (ISO/IEC JTC 1/SC 27 WG1 N 3297)
• Risk Management Framework for Information Systems and Organizations (NIST SP 800-37r2)
• NIST Risk Management Framework | CSRC

Recommended

• ISO 27001 Risk Treatment: An Auditor-Ready Guide
• Audit Ready ISO 27001 Risk Register for ISMS Teams, One Downloadable Template
• 4 Audit Ready Templates for ISO 27001 Project Reporting
• ISO 27001 Risk Matrix: 5×5 Template for Audit-Ready InfoSec