Hand placing risk treatment plan folder on desk

ISO 27001 risk treatment is the formal process defined in Clause 6.1.3 of the standard where your organization selects and implements controls to address each identified information security risk. Auditors at both Stage 1 and Stage 2 want to see a documented, traceable chain from every risk in your register through to a treatment decision, named controls, an owner, a target date, and evidence that the work happened.

Before you go further, confirm these five items for every risk above your acceptance threshold:

Treatment decision recorded: avoid, mitigate, transfer, or accept — stated explicitly, not implied.
Named risk owner: a specific person (not a team or department) who has formally accepted accountability.
Controls mapped to Annex A: each mitigating action references the relevant Annex A control number(s) or justifies a custom control.
Target completion dates: realistic, documented, and not already overdue.
Evidence identified: the artifact that will prove the control is implemented (ticket, test report, contract, training record).

If any of those five are missing for a risk above threshold, you have an audit finding waiting to happen.

Key Takeaways

Effective ISO 27001 risk treatment requires a documented, traceable chain from every risk through a treatment decision, named controls, an owner, evidence, and a residual score, all reconciled in a current SoA.

Point	Details
Clause 6.1.3 defines the requirement	Treatment must produce a documented RTP, an SoA, and formal residual risk acceptance from named owners.
Four options, each with evidence requirements	Avoid, mitigate, transfer, and accept each require specific documentation; acceptance without a signed owner record fails audit.
SoA and RTP must stay reconciled	Every included Annex A control needs a corresponding RTP action; every RTP action needs an Annex A reference or a justified custom control.
Residual scores are non-negotiable	A blank residual score column is one of the most common Stage 2 findings; re-score every risk after implementation.
Ismscalculator accelerates RTP setup	The free readiness check and full assessment generate structured RTP rows, Annex A mappings, and a Gantt export calibrated to your organization’s size and industry.

Why does ISO 27001 require risk treatment, and what does Clause 6.1.3 actually demand?
What are the four ISO 27001 risk treatment options?
How does the ISO 27001 risk treatment process work step by step?
How do you build an auditor-ready Risk Treatment Plan?
How do you map risk treatments to Annex A and build the SoA?
What evidence do auditors expect from your monitoring and review process?
What mistakes do teams make with risk treatment, and how do you fix them?
How does Ismscalculator help you size effort and produce an auditor-ready RTP?
What criteria should you use to select a treatment option beyond the four standard types?
How does risk treatment look different across industries and organization sizes?
Why communication and training are not optional in risk treatment
What auditors consistently praise and flag in Risk Treatment Plans
Ismscalculator gives you a structured starting point for your RTP
Sources

Why does ISO 27001 require risk treatment, and what does Clause 6.1.3 actually demand?

ISO/IEC 27001:2022 defines an information security management system (ISMS) and requires a risk-based approach tailored to the organization’s own context, size, and objectives. The standard is deliberately non-prescriptive: it tells you what to do, not exactly how to do it. That flexibility is a feature, not a gap, but it means auditors judge your process against your own documented rationale.

The clause sequence matters. Clause 6.1.2 requires a documented risk assessment process that produces a scored risk register. Clause 6.1.3 picks up from there and requires you to:

Select treatment options for each risk.
Determine the controls needed to implement those options.
Compare your chosen controls against Annex A to verify nothing necessary has been omitted.
Produce a Statement of Applicability (SoA) that lists every Annex A control, states whether it applies, and justifies the decision either way.
Formulate a Risk Treatment Plan (RTP) that documents the actions, owners, dates, and expected evidence.
Obtain formal acceptance of residual risk from the named risk owners.

Clause 8.2 requires you to perform the risk assessment at planned intervals or when significant changes occur. Clause 8.3 requires you to implement the risk treatment plan. Those two clauses are where auditors look for evidence that the plan was actually executed, not just written.

What auditors check in Stage 1 and Stage 2:

A risk register exists and every entry has a score, a treatment decision, and an owner.
The RTP references specific Annex A controls by number and maps to the SoA.
The SoA accounts for every Annex A control in the 2022 edition with an inclusion/exclusion justification.
Residual risk scores appear after treatment, not just before.
Risk owners have signed off on residual risk acceptance in writing.
Evidence artifacts are named, retrievable, and dated.

A missing residual score or an SoA that lists a control as “applicable” but the RTP has no corresponding action are the two most common Stage 2 findings.

What are the four ISO 27001 risk treatment options?

The standard recognizes four treatment options. Choosing the right one for each risk is a judgment call, but it should be a documented, defensible judgment call.

Avoid (eliminate the risk): Stop the activity that creates the risk. A company that decides not to store payment card data avoids the PCI-related risks entirely. Auditors want to see a documented decision and evidence the activity was discontinued. This option is often underused because it feels like giving up capability, but for risks with very high inherent scores and no proportionate business benefit, it is the cleanest answer.

Mitigate (reduce the risk): Apply controls to lower the likelihood or impact. This is the most common option and the one that generates the most RTP entries. Examples include deploying multi-factor authentication to reduce the likelihood of unauthorized access, or encrypting data at rest to reduce the impact of a breach. Every mitigating action needs a specific Annex A reference.

Transfer (share the risk): Shift financial or operational consequences to a third party, typically through cyber insurance or a contractual indemnity clause with a vendor. Transfer does not eliminate the risk; it changes who bears the cost. Auditors will ask for the insurance certificate or the contract clause as evidence. Transfer is appropriate when the cost of mitigation exceeds the expected loss and a willing counterparty exists.

Accept (retain the risk): Formally acknowledge that the risk falls within your organization’s risk appetite and no additional treatment is warranted. Acceptance requires a named owner’s written sign-off. Auditors flag acceptance entries that lack a signature or that accept risks scoring well above the stated acceptance threshold without explanation.

Decision factors and a quick comparison

Treatment option	Best fit	Auditor evidence needed	Main risk
Avoid	High inherent score, low business value of the activity	Documented decision, proof activity stopped	Loss of business capability
Mitigate	Most operational risks; cost of control is proportionate	Annex A mapping, implementation evidence, residual score	Incomplete implementation
Transfer	High-impact, low-frequency events; insurance market exists	Policy/contract with coverage scope confirmed	Residual gaps not covered by policy
Accept	Low-scoring risks within stated appetite	Named owner sign-off, dated acceptance record	Acceptance creep over time

Decision factors beyond the four options themselves include your organization’s documented risk appetite (set by management under Clause 5.2), legal or contractual obligations that may mandate specific controls regardless of risk score, cost-benefit analysis comparing control cost against expected loss reduction, and the operational feasibility of the control in your environment.

How does the ISO 27001 risk treatment process work step by step?

The process is sequential and each step produces documented output. Skipping a step does not save time; it creates a gap an auditor will find.

Complete the risk assessment (Clause 6.1.2). Score each risk for likelihood and impact using your documented methodology. Produce a risk register with inherent scores. This is the input to treatment.
Apply your risk acceptance criteria. Separate risks above the acceptance threshold from those below it. Risks below threshold may be accepted in the register without a full RTP entry. Risks above threshold need treatment.
Select a treatment option for each above-threshold risk (Clause 6.1.3). Document the rationale. “We chose mitigation because the cost of the control is less than the expected annual loss” is auditable. “We chose mitigation” is not.
Determine specific controls and map to Annex A. For each mitigating action, identify the Annex A control(s) it satisfies. Use the ISO 27001 Annex A controls reference to confirm you have not missed a relevant control. If you need a control not in Annex A, document it and justify why it is necessary.
Generate the Statement of Applicability. Every Annex A control appears in the SoA. For each: state whether it is included or excluded, link it to the risk(s) or legal requirement(s) that justify inclusion, and for exclusions, confirm no risk in the register would be left unaddressed.
Build the Risk Treatment Plan. Assign owners, set target dates, and name the evidence artifact for each action. Practitioner templates treat the RTP as a mini project plan with fields for action, owner, start/end dates, status, evidence, and residual score.
Implement the plan (Clause 8.3). Execute the actions. Collect and store evidence as you go, not retrospectively.
Score residual risk. After implementation, re-score each risk. The residual score must reflect the actual state of controls, not the hoped-for state.
Obtain formal risk acceptance. Risk owners sign off on residual risk. This can be a digital signature on the RTP document, a recorded management review decision, or a formal acceptance form.
Review at planned intervals (Clause 8.2). Reassess when significant changes occur and at least annually. Update the RTP and SoA accordingly.

Who does what: roles and responsibilities

Role	Responsibilities
ISMS Manager	Owns the process; maintains the risk register, RTP, and SoA; coordinates reviews
Risk Owner	Accountable for treatment of assigned risks; signs residual risk acceptance
IT Lead	Implements technical controls; provides evidence (tickets, test results)
Legal / Compliance	Reviews contractual and regulatory obligations that affect treatment choices
Senior Management / Board	Sets risk appetite; reviews and approves RTP at management review (Clause 9.3)

Escalate to management when a risk above threshold cannot be treated within budget, when a treatment decision requires accepting a risk that exceeds the stated appetite, or when a new risk emerges from a significant organizational change.

How do you build an auditor-ready Risk Treatment Plan?

The RTP is not a spreadsheet you fill in once and file. Auditors treat it as a living document and will check version history, sign-off dates, and whether evidence links are real and retrievable.

Required fields for every RTP entry

Every row in your RTP should contain:

Risk ID: matches the risk register entry exactly.
Risk statement: a one-sentence description of the threat, vulnerability, and potential impact.
Inherent risk score: likelihood × impact before controls.
Treatment decision: avoid, mitigate, transfer, or accept.
Specific actions: concrete, testable steps (not “improve security” — see the mistakes section below).
Annex A control reference(s): the control number(s) from the 2022 edition.
Risk owner: named individual.
Start and target completion dates.
Evidence artifact: the specific document, ticket, or record that proves completion.
Residual risk score: re-scored after implementation.
Acceptance sign-off: name, date, and method of sign-off.

Sample RTP entry

Field	Example value
Risk ID	R-014
Risk statement	A privileged administrator account with no MFA could be compromised, exposing all production data
Inherent score	16
Treatment decision	Mitigate
Specific actions	Deploy MFA for all admin accounts via Okta; review and remove stale privileged accounts quarterly
Annex A reference	A.8.2 (Privileged access rights), A.9.4 (Secure authentication)
Risk owner	Jane Smith, Head of IT
Target completion	March 31, 2026
Evidence artifact	Okta MFA deployment ticket; quarterly access review report
Residual score	6 (likelihood 2 × impact 3)
Acceptance sign-off	Jane Smith, signed March 31, 2026

Practitioner guides recommend a scoring threshold of roughly 10 or above to trigger a standalone RTP entry. Risks below that threshold can be noted in the risk register with a brief treatment rationale and accepted without a full RTP row.

Versioning and sign-off: date every version of the RTP, record who approved it, and store prior versions. Auditors sometimes ask to see the previous version to confirm the plan was updated after a review cycle, not just before the audit.

How do you map risk treatments to Annex A and build the SoA?

The SoA is the document that ties everything together. It is also the document auditors spend the most time on during Stage 2, because it is the single place where treatment decisions, control selections, and exclusion justifications must be consistent with the RTP and the risk register.

The 2022 edition of ISO 27001 reorganized Annex A into 93 controls across four themes: organizational, people, physical, and technological. Every one of those 93 controls must appear in your SoA with a clear inclusion or exclusion status.

Example SoA mapping rows

Justifying exclusions is where many organizations get into trouble. “Not applicable” is not a justification. The SoA must explain why the control does not apply: the organization has no relevant assets, the threat does not exist in the operational context, or a compensating control addresses the same risk. An auditor who finds a risk in the register that a supposedly excluded control would address will raise a finding immediately.

ISO guidance confirms that Annex A is not exhaustive. If your risk assessment identifies a threat that no Annex A control directly addresses, you may design a custom control. Document it in the SoA as an additional control with a clear rationale.

Reconciliation checklist auditors will test:

Every RTP action references at least one Annex A control number.
Every Annex A control marked “included” in the SoA has at least one corresponding RTP action or risk register entry.
No Annex A control is marked “excluded” if a risk in the register would require it.
Custom controls beyond Annex A are documented with a rationale.
The SoA version date matches or post-dates the most recent RTP update.

Pro Tip: Number your SoA rows to match the Annex A control numbers exactly (A.5.1 through A.8.34 in the 2022 edition). Auditors work from the standard; a SoA that uses the same numbering lets them cross-reference in minutes rather than hunting through a custom layout.

What evidence do auditors expect from your monitoring and review process?

A completed RTP is not the end of the process. Auditors want to see that the ISMS is operating, not just documented. The evidence library you build during implementation is what survives audit sampling.

Review cadence by risk severity

Critical and high risks (score above 15): review monthly until residual score drops below threshold; then quarterly.
Medium risks (score 8–15): quarterly review.
Low risks (score below 8): annual review, or at the next scheduled management review.
Ad-hoc triggers: significant organizational change (new system, acquisition, major process change), a security incident, a near-miss, or a change in the threat landscape.

Evidence checklist for each completed treatment

Change management ticket or project task showing the action was completed.
Technical test result or configuration report (for technical controls).
Training completion records (for people controls).
Contract or insurance certificate (for transfer decisions).
Backup test or restore report (for availability controls).
Management review minutes that reference the RTP status.
Signed residual risk acceptance form or equivalent record.

KPIs and logs auditors commonly check

KPI / Log	What auditors look for
Treatment completion rate	Percentage of RTP actions completed by target date; overdue items need explanation
Residual risk trend	Are scores decreasing over time, or are the same risks recurring at high scores?
Overdue actions log	Any action past its target date without a documented extension and owner approval
Incident log vs. risk register	Do incidents map back to known risks? Unregistered risks that caused incidents are a finding
Management review records	Evidence that senior management reviewed RTP status at planned intervals (Clause 9.3)

Red flags that create audit findings: a residual risk score that is identical to the inherent score (suggests controls were not actually implemented), RTP actions with no named owner, controls listed as “implemented” in the SoA with no supporting evidence, and a management review record that does not reference the RTP.

What mistakes do teams make with risk treatment, and how do you fix them?

The most damaging mistakes are not technical. They are documentation failures that make real work invisible to an auditor.

Vague treatment actions. “Improve access controls” is not an auditable action. “Deploy MFA for all accounts with admin privileges to production systems by March 31, 2026, evidenced by Okta configuration report” is. Every action should answer: what exactly, by whom, by when, and proven how.

Missing residual scores. Auditors see this constantly. The RTP has an inherent score column and a treatment column, but the residual score column is blank or says “TBD.” A blank residual score means you cannot demonstrate the control reduced the risk, which means the treatment is unverifiable.

SoA and RTP out of sync. The SoA says certain controls are included, but the RTP may have no action that implements them; or vice versa. Either way, the traceability chain breaks and auditors will flag it.

No formal risk acceptance. Acceptance is a treatment option, but it requires documented sign-off from a named owner. An entry that says “accepted” with no signature, no date, and no reference to the risk appetite criteria is not a valid acceptance.

Acceptance without an expiry. Risk acceptance should not be permanent by default. Set an expiry date (typically 12 months) so accepted risks are reviewed at the next cycle rather than silently rolling forward indefinitely.

Pro Tip: Create a naming convention for evidence artifacts that includes the risk ID, control reference, and date (e.g., R-014_A8.2_MFA_2026-03-31). When an auditor asks for evidence of a specific control, you can retrieve it in seconds rather than hunting through a shared drive.

Rewrite every treatment action to include a verb, a scope, a date, and an evidence artifact.
Run a monthly SoA-RTP reconciliation check before your audit window opens.
Set calendar reminders for acceptance expiry dates so no accepted risk rolls past its review date unnoticed.
Store all evidence in a folder structure organized by risk ID, not by control or date.

How does Ismscalculator help you size effort and produce an auditor-ready RTP?

Knowing what to document is half the problem. Knowing how much work it will take and having a structure to capture it is the other half. That is where Ismscalculator fits into the process.

The workflow is straightforward:

Run the free readiness assessment. The 2-minute self-check scores your current maturity across 14 ISO domains, including risk management. Risks above your threshold surface immediately with suggested treatment priorities.
Generate RTP rows from the assessment output. The platform produces structured RTP entries with pre-populated fields (risk statement, Annex A references, suggested actions) that you can edit to match your specific context.
Export the SoA mapping. The export includes Annex A control references aligned to your treatment decisions, ready to drop into your SoA document.
Use the Gantt export for timeline planning. Each RTP action maps to a project task with a suggested duration based on industry benchmarks for your organization size and sector.
Link exported items back to your evidence library. The PDF export includes artifact placeholders (ticket number, test report, sign-off date) that you populate as implementation progresses.

Pro Tip: Use Ismscalculator’s industry benchmarks to validate your treatment timeline against sector averages before presenting the RTP to management. A plan that is significantly longer or shorter than the benchmark for your industry size invites questions; having the benchmark data ready answers them before they are asked.

The platform also offers introduction requests to independent ISO 27001 consultants if your team needs external review of the RTP before the certification audit. For SaaS and tech companies in particular, the cloud-specific risk templates reduce the time needed to build the initial risk register from scratch.

What criteria should you use to select a treatment option beyond the four standard types?

The four options (avoid, mitigate, transfer, accept) cover most scenarios, but the decision between them is not always obvious. Several criteria should inform the choice systematically.

Risk appetite alignment. Your organization’s documented risk appetite (set at board or senior management level) defines the boundary between acceptable and unacceptable residual risk. A treatment option that leaves residual risk above appetite is not a valid choice regardless of cost.

Cost-benefit proportionality. The cost of a control should be proportionate to the risk it addresses. A $50,000 annual control cost for a risk with an expected annual loss of $5,000 is difficult to justify unless regulatory requirements mandate it. Document the analysis, not just the conclusion.

Legal and contractual obligations. Some controls are not optional. HIPAA, PCI-DSS, state data breach notification laws, and customer contracts may require specific controls regardless of your internal risk score. These obligations override the cost-benefit calculation and must be reflected in the SoA as legally required inclusions.

Operational feasibility. A control that cannot be implemented in your environment within a realistic timeframe is not a real treatment. If the technically correct control is not feasible, document why and select an interim compensating control while the long-term solution is planned.

Combination treatments. A single risk can have multiple treatment options applied simultaneously. A vendor data exposure risk might be partially mitigated (encryption, access controls), partially transferred (contract indemnity), and the residual accepted. Document each component separately in the RTP so the combined effect on the residual score is traceable.

Residual risk target. Work backward from the residual score you need to achieve to bring the risk within appetite. If mitigation alone cannot get you there at a proportionate cost, transfer or a combination approach may be necessary.

How does risk treatment look different across industries and organization sizes?

The process is the same; the controls, thresholds, and evidence look very different depending on context.

Healthcare organizations face HIPAA obligations that effectively mandate certain controls regardless of risk score. A hospital treating patient data exposure risks will typically mitigate with encryption (A.8.24), access controls (A.8.2), and audit logging (A.8.15), and will transfer residual risk through cyber liability insurance. The evidence library includes HIPAA-required documentation alongside ISO artifacts. For cloud risk management in healthcare finance, the SoA often runs to 80+ included controls.

Financial services firms operate under SEC, FINRA, and state-level requirements that create mandatory control inclusions. Risk acceptance thresholds tend to be lower than in other sectors because regulators expect active treatment of most identified risks. Treatment timelines are also shorter; a financial firm accepting a high-scoring risk for 12 months without a documented treatment plan is likely to face regulatory scrutiny before an ISO auditor arrives.

SaaS and technology companies often face a concentration of risks in the cloud infrastructure and software development lifecycle domains. Treatment actions frequently reference A.8.25 (secure development lifecycle), A.8.9 (configuration management), and A.8.23 (web filtering). The evidence is typically in ticketing systems like Jira or GitHub, which makes linking artifacts to RTP entries straightforward.

Small businesses with fewer than 50 employees can simplify the RTP structure without sacrificing auditability. A single spreadsheet with the required fields is sufficient; the standard does not require a specific tool or format. The ISO 27001 small business guide recommends prioritizing the top 10 risks by score and treating those fully before expanding the register. An auditor reviewing a small-business ISMS expects proportionality; a 200-row RTP for a 20-person company raises questions about whether the process is genuinely managed or just documented.

Manufacturing and operational technology (OT) environments introduce physical and process risks that Annex A’s technological controls do not fully address. Custom controls beyond Annex A are common here, particularly for physical access to control systems (A.7.1, A.7.2) and supplier risk (A.5.19, A.5.20). The SoA for an OT environment typically includes more physical controls and more custom additions than a pure IT environment.

How does risk treatment look different across industries and organization sizes? — overview diagram

Why communication and training are not optional in risk treatment

A Risk Treatment Plan that lives in a shared drive and is known only to the ISMS manager is not a functioning ISMS. The people responsible for implementing controls, collecting evidence, and escalating incidents need to understand what they are doing and why.

Hand placing security training folder on table

Awareness for risk owners. Risk owners who do not understand their accountability will not collect evidence, will not escalate when a treatment is delayed, and will not sign residual risk acceptance forms with any real understanding of what they are accepting. A 30-minute briefing at the start of each treatment cycle, covering the owner’s specific risks and the evidence they need to produce, is more effective than a company-wide security awareness email.

Training for control implementers. Technical staff implementing controls need to know the specific configuration or process required, not just a general directive. “Enable MFA” produces inconsistent results. A documented procedure with screenshots, a test protocol, and a named reviewer produces an auditable outcome.

Management communication. Senior management must receive RTP status updates at management review (Clause 9.3). The format matters: a traffic-light dashboard showing treatment completion rate, overdue actions, and residual risk trend communicates more in two minutes than a 40-page report. Auditors will ask to see management review minutes; those minutes should reference specific RTP metrics, not just confirm the meeting happened.

Change communication. When a significant organizational change occurs (a new cloud platform, a merger, a change in data processing activities), the risk assessment and RTP must be updated. The people who know about the change, typically IT project managers and business unit leads, need a clear channel to notify the ISMS manager. Without that channel, risks from new activities go unregistered until an incident or an auditor finds them.

Training records are evidence. Store completion records for security awareness training, role-specific control training, and any tabletop exercises in the same evidence library as your technical artifacts. Auditors check people controls as carefully as technical ones.

What auditors consistently praise and flag in Risk Treatment Plans

Three things auditors comment positively on: a risk register and RTP that use identical risk IDs throughout (no translation layer needed), residual scores that are visibly lower than inherent scores with a clear explanation of which controls drove the reduction, and management review minutes that reference specific RTP line items by ID rather than discussing “security risks” in the abstract.

Three patterns that generate findings almost every time: treatment actions written as intentions rather than completed work (“we plan to implement MFA” in a document dated six months before the audit), SoA inclusions with no corresponding RTP action or evidence link, and risk acceptance entries signed by someone who does not have the authority to accept risk on behalf of the organization.

The gap between a passing RTP and a failing one is rarely about the quality of the security controls. It is almost always about documentation discipline. An organization with genuinely good security but a poorly documented RTP will receive more findings than an organization with average controls and meticulous documentation. That is not a flaw in the audit process; it is the point. The standard requires you to demonstrate that you manage risk systematically, and documentation is the only way to demonstrate a process.

Three priorities for any team preparing an RTP for audit: close every open residual score before the audit window, reconcile the SoA and RTP in a single sitting using the checklist in the SoA mapping section above, and confirm that every risk owner can locate and describe their evidence artifact without help from the ISMS manager.

Ismscalculator gives you a structured starting point for your RTP

Producing an auditor-ready RTP from scratch takes time most compliance teams do not have. Ismscalculator cuts the setup time by giving you a pre-structured RTP framework calibrated to your organization’s size, industry, and current maturity level, so you spend your time on the substance rather than the format.

Ismscalculator

Run the free 2-minute readiness check to get an immediate snapshot of your risk treatment maturity across all 14 ISO domains. From there, the full readiness assessment generates RTP rows with Annex A mappings, a Gantt-based implementation timeline, and a PDF export you can share with auditors or management. Industry benchmarks let you validate your treatment timeline against sector averages before you present it. If you want an independent review before your certification audit, the platform can connect you with an ISO 27001 consultant directly. Your data stays private; the outputs are yours to own and edit.

Sources

The following sources were used to build this guide and are worth bookmarking for clause language, audit preparation, and template reference:

ISO 27001 Risk Treatment: An Auditor-Ready Guide