Dana Whitfield found out the hard way that a spreadsheet is not a plan.
She was CISO at Meridian Health Partners, a mid-sized regional healthcare network with eleven clinics and a 40-bed specialty hospital, when the Stage 2 surveillance audit landed eight months after certification. On paper, Meridian's ISMS looked mature. The risk register identified 61 risks. The Statement of Applicability justified all 93 Annex A controls. And there was a document called "Risk Treatment Plan v3.docx" — six pages, a table with risk names, a column of controls, a column that said "Owner: IT," and a status column where every single row read "In Progress."
It had read "In Progress" for fourteen months.
Three weeks before the audit, a contracted radiology partner's remote access account — flagged eleven months earlier in the risk register as "High: unmanaged third-party remote access to PACS imaging systems," treatment option "Modify," planned controls "MFA enforcement, network segregation, access review cadence" — was compromised through a credential-stuffing attack. The attacker sat inside the network for six days before a nurse noticed unusual login alerts at 3 a.m. and escalated it. No MFA had been enforced on the account. No segregation had been implemented. No review cadence existed. The "owner" listed was a departed IT manager whose account itself hadn't been deprovisioned in nine months — an irony not lost on the incident responders.
The direct cost: $1.9 million in forensic investigation, breach notification to 34,000 patients, credit monitoring, legal fees, and a corrective action plan imposed by the state health authority. The audit, which happened three weeks later, added a major nonconformity for Clause 6.1.3 because the "treatment plan" had no actions with dates, no evidence of implementation, and no record that any risk owner had ever approved it or accepted residual risk. Total remediation and recertification cost: another $310,000 and five months of delayed contract renewals with two hospital systems that required proof of certification to keep doing business with Meridian.
Dana's postmortem line, which she now uses in every internal training session, is blunt: "A risk treatment plan that nobody executes isn't a control. It's a liability with a table of contents."
This is the article Dana wishes she'd read eighteen months earlier. Clause 6.1.3 of ISO/IEC 27001:2022 is arguably the single most audited, most misunderstood, and most frequently faked requirement in the entire standard — because it's easy to produce a document that looks like a plan and genuinely hard to produce one that survives contact with a real incident and a real auditor. This guide walks through both.
Who This Is For
This guide is written for ISMS managers, CISOs, GRC leads, and risk owners who have already completed the risk assessment activities required under Clause 6 Planning — they have a populated risk register with identified risks, likelihood and impact ratings, and calculated risk levels — and now need to decide what to actually do about each one. If you haven't built your risk register yet, start with our guides on the ISO 27001 risk assessment methodology and how to build an ISO 27001 risk register first — this article picks up exactly where those leave off. By the end, you'll walk away with a defensible treatment-option decision for every risk, a control set verified against Annex A, a working RTP document with real owners and dates, and a repeatable process for getting risk owners to sign off on residual risk — the exact evidence an auditor will ask to see.
The Four Risk Treatment Options
ISO/IEC 27001:2022, Clause 6.1.3(b), requires you to "determine all risk treatment options" appropriate to the risk assessment results. ISO 27002 and the broader risk management literature (echoed in ISO 31000) group these into four categories. Every risk in your register needs one of these four assigned — and the assignment needs a reason, because an auditor will ask "why this option and not another?"
Treatment Option | What It Means | When to Use It | Typical Evidence |
|---|---|---|---|
Modify (reduce) | Apply one or more controls to lower likelihood, impact, or both | Risk is above appetite but the activity/asset is necessary to the business; cost of controls is proportionate to risk reduction | Control implementation records, configuration evidence, test results |
Retain (accept) | Consciously accept the risk as-is, with no new controls | Risk is already within appetite; cost of further treatment exceeds the benefit; risk is low-likelihood/low-impact | Signed risk acceptance record, rationale, review date |
Avoid | Eliminate the risk source entirely — stop the activity, retire the asset, exit the market/relationship | Risk is unacceptable and no proportionate control exists, or the activity's value doesn't justify its risk | Decision record, decommissioning evidence, revised scope/asset inventory |
Share (transfer) | Move part of the financial or operational consequence to a third party | Risk is real but better absorbed by a specialist (insurer, outsourced provider) than managed in-house | Insurance policy/certificate, outsourcing contract with security clauses, SLA |
A note on terminology before we go further — these four labels (Modify, Retain, Avoid, Share) are used inconsistently across consultancies and tooling, and it's worth aligning your team on a single vocabulary early; our ISO 27001 glossary of terms keeps a consistent reference definition for each. ISO 27001 does not require you to pick exactly one option per risk. In practice, most real treatments are blended — you modify a risk with new controls and share the residual exposure with a cyber insurance policy, or you avoid one component of an activity while retaining the rest. The register and the RTP should reflect that nuance rather than forcing every risk into a single bucket.
"The mistake I see in nine out of ten draft treatment plans is that 'Modify' is the only option anyone considers. Nobody asks whether the smarter move is to just stop doing the risky thing. Avoidance is the cheapest control that never gets proposed because it requires someone to say no to a business unit." — Marcus Oyelaran, Lead ISO 27001 Auditor, Certus Assurance Group
Step 1: Select the Treatment Option for Each Risk
Work from your completed risk register — every risk should already carry a calculated risk level (from your risk assessment methodology) and a designated risk owner. For each risk, the risk owner — not IT, not the ISMS manager alone — makes the treatment call, informed by four inputs: the organization's risk appetite/tolerance thresholds, the cost and feasibility of available controls, the business value of the underlying activity, and any legal, regulatory, or contractual obligations that constrain the choice (you can't "retain" a risk that a contract explicitly requires you to control).
Use a simple decision framework to keep this consistent across dozens or hundreds of risks. Note that the reliability of "risk level within appetite" as a decision input depends entirely on how consistently likelihood and impact were scored in the first place — if half your risk owners scored risks qualitatively ("High/Medium/Low" by gut feel) and the other half used a quantitative scale, treatment decisions across the register won't be comparable. Our companion piece on qualitative vs quantitative risk assessment approaches covers how to keep scoring consistent before it reaches this stage.
Question | If Yes → Lean Toward |
|---|---|
Is the risk level within our documented risk appetite already? | Retain |
Can proportionate, available controls bring the risk within appetite at reasonable cost? | Modify |
Does the activity generating this risk provide value disproportionate to the risk it creates? | Avoid |
Is a third party better positioned to absorb or manage this exposure (financially or operationally)? | Share |
Does a law, regulation, or contract mandate specific controls regardless of appetite? | Modify (mandated) |
Document the decision and the reasoning in the register or a linked treatment-decision log — not just the option name. "Modify — MFA is required under our cyber insurance policy renewal terms and reduces likelihood from Likely to Unlikely at a cost we've already budgeted" is auditable. "Modify" by itself is not.
Risk (abbreviated) | Inherent Risk Level | Owner | Decision Driver | Option Selected |
|---|---|---|---|---|
Unmanaged third-party remote access to clinical systems | High (20) | Head of Clinical IT | Regulatory (HIPAA-adjacent obligation), insurer requirement | Modify |
Legacy FTP server for batch file transfer, no encryption | High (16) | VP Engineering | Low business value, replacement already scoped | Avoid |
Single data center, no geographic redundancy | Medium (12) | COO | Cost of full redundancy exceeds risk reduction value this cycle | Retain (with compensating DR plan) + Share (insurance) |
Ransomware disruption to production line | High (20) | Plant Manager | Cannot eliminate; controls + insurance both needed | Modify + Share |
Departing employee retains SaaS access | Medium (10) | HR Director | Proportionate, low-cost fix (deprovisioning workflow) | Modify |
Step 2: Determine All Controls Necessary to Implement the Option
Once the option is chosen, Clause 6.1.3(c) requires you to "determine all the controls that are necessary to implement the risk treatment option(s) chosen." This is a deliberately open step — you are not limited to Annex A. If a risk needs a control that isn't in Annex A's 93-control reference set, you still list it. Annex A is a reference checklist to verify completeness against, not the exhaustive universe of permissible controls (we cover the comparison step next).
For each risk-option pair, ask: what has to be true, technically and organizationally, for this option to actually reduce or manage the risk? Break it into control statements specific enough that someone could implement and later audit them — not "improve access control" but "enforce MFA on all third-party remote access accounts within 30 days; review third-party access quarterly." A ransomware risk, for instance, typically pulls controls from several unrelated Annex A clusters at once — technical prevention, but also the incident response planning covered in incident management controls 5.24–5.28 and patch-level controls from technical vulnerability management, control 8.8 — which is exactly why determining controls risk-by-risk, rather than theme-by-theme, surfaces a more complete set than working straight down the Annex A list.
Risk | Option | Controls Determined (specific) |
|---|---|---|
Unmanaged third-party remote access | Modify | MFA enforced on all external accounts; network segregation isolating PACS from general network; quarterly access review; contractual security clause with radiology partner |
Legacy FTP for batch transfer | Avoid | Decommission FTP service; migrate to SFTP/managed file transfer platform; validate no dependent process remains before shutdown |
Ransomware disruption to production line | Modify + Share | Endpoint detection and response on OT-adjacent systems; offline immutable backups; incident response runbook specific to OT; cyber insurance policy covering business interruption |
Departing employee retains SaaS access | Modify | Automated deprovisioning workflow triggered by HR offboarding event; access certification every 90 days |
Most organizations find that controls cluster naturally around the themes already defined in Annex A — access management, supplier security, incident handling, backup — which is exactly why the comparison step (next) tends to confirm coverage rather than surface gaps, provided the determination step was done thoroughly. If you need concrete examples of what a specific control looks like in practice, our breakdowns of access control controls 5.15–5.18 and the technological controls overview covering 8.1–8.34 walk through implementation detail for individual controls referenced above.
"Teams jump straight to Annex A and start ticking boxes. That's backwards. Determine what you actually need first, from the risk itself, then go check Annex A to see if you missed anything obvious. If you start with the checklist, you end up implementing controls that don't map to any real risk, and skipping ones that do because they're not phrased the way your risk needs them." — James Okafor, independent ISMS consultant, 40+ Annex SoA reviews completed
Step 3: Compare Determined Controls Against Annex A
This is the step Clause 6.1.3(d) actually specifies and the one most teams either skip or perform backwards: "compare the controls determined... with those in Annex A and verify that no necessary controls have been omitted." Annex A of ISO/IEC 27001:2022 is a reference set of 93 controls across four themes — Organizational (5.1–5.37, 37 controls), People (6.1–6.8, 8 controls), Physical (7.1–7.14, 14 controls), and Technological (8.1–8.34, 34 controls). Its purpose here is narrow and specific: it is a completeness check, not a design tool. You are not implementing Annex A. You are verifying that your risk-driven control set didn't miss something Annex A would have reminded you to consider.
Walk every control you determined in Step 2 against the full Annex A list and mark the closest matching control number(s). Then walk the rest of Annex A — the controls you didn't naturally land on — and ask, deliberately, for each one: is this relevant to any risk we've assessed? If yes and it's missing from your control set, that's a gap — either your control determination missed something or your risk assessment missed a risk. If no, that's your justification for excluding it from the SoA, and that justification needs to be written down, not implied.
Determined Control (from Step 2) | Matching Annex A Control(s) | Comparison Outcome |
|---|---|---|
MFA on external remote access | 8.5 Secure authentication; 5.16 Identity management | Matched — confirms coverage |
Network segregation for PACS | 8.22 Segregation of networks | Matched — confirms coverage |
Quarterly third-party access review | 5.18 Access rights; 5.22 Monitoring, review and change management of supplier services | Matched — confirms coverage |
Contractual security clause with radiology partner | 5.20 Addressing information security within supplier agreements | Matched — confirms coverage |
— (nothing determined for supplier onboarding due diligence) | 5.19 Information security in supplier relationships | Gap identified — added to control set and risk register (see supplier relationship security controls 5.19–5.23) |
Automated HR deprovisioning workflow | 8.1 User endpoint devices (partial); no clean 1:1 Annex A match for the automation itself | Determined control retained beyond Annex A wording — permitted and expected |
Immutable offline backups | 8.13 Information backup | Matched — confirms coverage |
— (nothing determined for logging of the affected systems) | 8.15 Logging; 8.16 Monitoring activities | Gap identified — added; ties directly to detecting exactly the kind of compromise Meridian missed |
This is precisely where Meridian's original process broke down — nobody ever ran this backward pass. If Dana's team had walked control 8.16 (Monitoring activities) against the third-party remote access risk during the original comparison step, someone would have asked why there was no alerting on off-hours logins from that account, months before the actual attacker used exactly that gap. The comparison step is not a formality; it is a second, differently-shaped pass at the same risk that catches what a single brainstorm misses. For a broader refresher on the full Organizational control theme referenced repeatedly in this kind of gap analysis, see our Annex A organizational controls overview (5.1–5.37).
Step 4: Build the Statement of Applicability
The comparison step in Clause 6.1.3(d) and (e) feeds directly into the requirement to "produce a Statement of Applicability." The SoA is the master control ledger for your entire ISMS: for all 93 Annex A controls, it records whether each is applicable, the justification for inclusion or exclusion, and its implementation status. It is easy to confuse the SoA with the RTP because they're built from the same comparison work and they reference the same controls — but they answer different questions, and an auditor will test both separately.
Dimension | Statement of Applicability (SoA) | Risk Treatment Plan (RTP) |
|---|---|---|
Core question it answers | Which controls apply, and why (or why not)? | What are we doing, who's doing it, and by when? |
Scope | All 93 Annex A controls, universally | Only the controls/actions tied to assessed risks and chosen options |
Primary content | Applicability (yes/no), justification, implementation status, cross-reference to risk(s) | Risk, treatment option, controls, specific actions, owner, resources, timeline, status |
Owned by | ISMS Manager (document owner); content driven by risk assessment + comparison | Risk owners (accountable for execution); ISMS Manager coordinates |
Updated when | Any control's applicability, justification, or status changes | Any action's owner, timeline, resource, or status changes |
Clause reference | 6.1.3(d)–(e) | 6.1.3(e)–(f) |
If you're building your SoA for the first time or refreshing an outdated one, our dedicated walkthrough on creating an ISO 27001 Statement of Applicability covers the document structure, justification language auditors expect, and how to handle controls marked "not applicable" defensibly. For this article, the operative point is sequencing: you cannot credibly write a Statement of Applicability before you've done Steps 1–3. Teams that draft the SoA first and backfill risk justifications afterward almost always produce the generic, copy-pasted justification language ("standard practice," "best practice control") that auditors flag as evidence the SoA wasn't actually risk-driven. If you want a starting structure rather than building the SoA table from scratch, PentesterWorld's Statement of Applicability (SoA) Template has the column structure and justification-language examples already laid out.
Step 5: Write the Risk Treatment Plan
This is the document Clause 6.1.3(f) actually requires: "formulate an information security risk treatment plan." Where the SoA is a control ledger, the RTP is a project plan — and it needs to read like one. Every mature RTP I've reviewed across audits, regardless of the template used, converges on the same eight fields. Miss any one of them and the plan degrades back into the kind of wish list that sank Meridian.
Field | What Goes Here | Why Auditors Check It |
|---|---|---|
Risk reference | Link to the specific risk register entry (ID, description) | Traceability — every treatment action must trace back to an assessed risk |
Treatment option | Modify / Retain / Avoid / Share (or combination) | Confirms Step 1 decision was made and recorded |
Controls | Specific control(s), with Annex A cross-reference where applicable | Confirms Steps 2–3 were completed and linked to the SoA |
Action(s) | Concrete, verifiable task(s) — not a restated control name | Distinguishes a real plan from a copy of the control catalogue |
Owner | Named individual (not a department or "IT") | Accountability — auditors will ask this person direct questions |
Resources | Budget, headcount, tooling, vendor dependency | Confirms feasibility was considered, not just intention |
Timeline | Start date, target completion date, and any interim milestones | Enables tracking and flags stalled items (see Meridian's 14-month "In Progress") |
Status | Not started / In progress / Implemented / Verified — with a last-updated date | The single most-checked field in any audit; must reflect reality, not aspiration |
Here is a worked excerpt — the same risks used in Steps 1–3, carried through to a complete RTP entry:
Risk | Option | Controls | Action | Owner | Resources | Timeline | Status (as of review date) |
|---|---|---|---|---|---|---|---|
Unmanaged third-party remote access to clinical systems | Modify | 8.5, 5.16, 8.22, 5.18, 5.22, 5.20 | Enforce MFA on radiology partner account; deploy network segregation rule isolating PACS VLAN; add quarterly access review to GRC calendar; amend supplier contract with security clause | Head of Clinical IT (R. Delacroix) | $18K firewall rule change + existing MFA licensing; 20 hrs network engineering | MFA: 2 weeks; segregation: 6 weeks; contract amendment: 8 weeks | In Progress — MFA implemented and verified; segregation 60% complete; contract in legal review |
Legacy FTP for batch transfer | Avoid | 8.20, 8.9 | Decommission FTP service; migrate three dependent jobs to managed SFTP platform; confirm zero residual dependency before shutdown | VP Engineering (S. Tran) | $6K/yr SFTP platform license; 40 hrs migration engineering | 10 weeks to full decommission | Implemented — FTP service decommissioned, verified via network scan |
Ransomware disruption to production line | Modify + Share | 8.7, 8.13, 5.29, 5.30 | Deploy EDR to OT-adjacent endpoints; implement immutable offline backup tier; draft OT-specific IR runbook; bind cyber insurance rider covering business interruption | Plant Manager (K. Adeyemi) + CISO (co-owner for insurance) | $85K EDR + backup infrastructure; $22K annual insurance premium | EDR: 12 weeks; backup tier: 8 weeks; insurance bound: 4 weeks | In Progress — insurance bound and verified; EDR deployment 30% (phase 1 of 3 sites) |
Departing employee retains SaaS access | Modify | 8.1, 5.18 | Build automated deprovisioning trigger from HR offboarding workflow into IAM platform; run access certification quarterly | HR Director (M. Whitcombe) + IT Ops | Existing IAM platform capacity; 30 hrs integration engineering | 6 weeks | Verified — automation live, first certification cycle completed |
Notice the "Action" column never simply restates the control name. "Enforce MFA" is a control category; "Enforce MFA on the radiology partner account within two weeks, verified via login logs" is an action. If your RTP's action column and control column say the same thing in different words, you haven't actually planned the work — you've relabeled the gap analysis.
If you'd rather work from a pre-built structure than assemble this table from scratch, PentesterWorld's ISO 27001 Risk Register Template includes a linked treatment-plan tab with these exact eight fields, and our hands-on Build a Sample Risk Treatment Plan lab walks through populating one end-to-end using a realistic scenario, including the risk owner sign-off step covered next.
Illustrative Cost Ranges by Treatment Option
One question that comes up in almost every budget conversation I've sat in on: which treatment option is actually cheapest? The honest answer is "it depends entirely on the risk," but the cost shape of each option is predictable enough to plan around, and it's worth setting expectations with finance and leadership before line items start showing up in the RTP. These figures are illustrative, drawn from the pattern across mid-market organizational engagements, not a published benchmark — treat them as a planning heuristic, not a quote.
Treatment Option | Typical Cost Shape | Illustrative Range (mid-market org) | Ongoing Cost Burden |
|---|---|---|---|
Modify | Upfront tooling/engineering cost, then maintenance | $5,000–$350,000+ depending on scope (a config change vs. a multi-site EDR rollout) | Moderate — licensing, monitoring, periodic review |
Retain | Near-zero direct cost, but requires governance overhead | $0–$2,000 (documentation and review time only) | Low — but never zero; someone must keep reviewing it |
Avoid | Migration or decommissioning cost, often front-loaded | $10,000–$250,000 depending on system complexity and dependencies | Low after transition — the risk source is gone |
Share | Recurring premium or contractual pass-through cost | $15,000–$150,000+ annual premium, scaled to coverage limits | Ongoing — renews annually, subject to market pricing |
A pattern worth internalizing from this table: Avoid frequently looks expensive on a whiteboard and cheap in the actual invoice, because the "cost" being compared is migration effort now versus perpetual control maintenance forever — Vantage Payments' case study below is a direct illustration of that math working out in Avoid's favor. Retain is only free at the point of decision; the ongoing governance cost of remembering to keep re-checking a retained risk is where organizations most often quietly lose track of it, exactly as happened at Meridian.
Step 6: Risk Owner Approval and Residual Risk Acceptance
Clause 6.1.3(f) closes with a requirement that's easy to read past: "obtain risk owners' approval of the risk treatment plan and acceptance of the residual information security risks." This is two distinct approvals, not one, and both need to be documented with a name, a date, and a decision — not implied by the plan simply existing. This is also where the Clause 5 leadership and management commitment requirements become concrete rather than aspirational: top management is responsible for ensuring risk owners actually have the authority and time to make this call, not just a title that implies they should.
Approval of the RTP means the risk owner has reviewed the specific actions, owner, resources, and timeline assigned to their risk and agrees the plan is adequate and resourced. This is a project-management sign-off: "yes, this plan, as written, is what we're doing."
Acceptance of residual risk is a separate and more consequential decision: after the planned controls are implemented, some risk will remain — residual risk is almost never zero. The risk owner must explicitly accept that remaining level, in writing, understanding what it is. This is the decision an auditor and, more importantly, a board or regulator will scrutinize hardest after any incident: did the person accountable for this risk actually know what they were accepting, or did the plan just quietly assume "in progress" was good enough forever, as it did at Meridian.
Field | Purpose |
|---|---|
Risk reference | Ties acceptance to the specific register entry |
Treatment summary | One-line description of what was implemented |
Residual risk level (post-treatment) | Recalculated likelihood × impact after controls, not the inherent level |
Rationale for acceptance | Why this residual level is tolerable given appetite, cost of further treatment, and business context |
Risk owner name and title | Individual accountability — never a department |
Date of acceptance | Establishes the record's currency |
Review/expiry date | Forces re-acceptance rather than indefinite, silent carry-forward |
A residual risk acceptance record with no review or expiry date is how organizations end up "accepting" a risk in 2021 that nobody has looked at since — functionally identical to Meridian's fourteen-month "In Progress" problem, just relabeled as accepted instead of pending. Set a review cadence (annually at minimum, or triggered by material change) and put the next date on the record itself.
"I never sign a risk treatment plan again without asking myself who, specifically, is going to be angry with me in a year if this line item is still blank. If I can't name that person, the plan doesn't have an owner — it has a hope." — Dana Whitfield, CISO, Meridian Health Partners
Step 7: Implementation Tracking and Reporting
A signed-off RTP is a snapshot; the work happens after it. Implementation tracking is what separates an RTP that gets executed from the one Dana inherited. The mechanics are simple but need to be scheduled, not left to memory:
Cadence | Activity | Who's Involved |
|---|---|---|
Weekly/bi-weekly | Action-owner check-in on in-progress items; blockers surfaced | ISMS Manager + individual action owners |
Monthly | RTP status review across all open risks; status field updated with evidence, not assumption | ISMS Manager + risk owners |
Quarterly | Residual risk re-check for treated risks; new risks from updated assessments folded in | Risk owners + management |
At management review (per Clause 9 performance evaluation, 9.3) | RTP progress reported to top management as ISMS performance input | ISMS Manager reports to leadership |
Ad hoc | Any missed timeline triggers an explicit re-plan or escalation, not a silent status change to a later date | Risk owner + ISMS Manager |
The single highest-value habit here: never let a status field change from "In Progress" to a later date without a reason attached. Track why something slipped — resource constraint, scope change, vendor delay — because auditors (and your own leadership) will ask, and "it just did" is not an answer that survives a second audit cycle. A tracking spreadsheet or GRC platform that timestamps every status change automatically solves most of this; a static document that gets manually edited, as Meridian's did, does not.
RACI: Who Does What in the Risk Treatment Plan
Tracking breaks down almost as often from unclear roles as from missing timelines — a status review meeting where everyone assumes someone else is watching a given risk is functionally identical to no one watching it. A simple RACI (Responsible, Accountable, Consulted, Informed) applied consistently across the RTP process removes that ambiguity, and it's worth documenting once at the ISMS level rather than re-deciding it for every individual risk.
Activity | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
Selecting the treatment option | Risk owner | Risk owner | ISMS Manager, subject-matter experts | Top management |
Determining controls | ISMS Manager / security engineering | Risk owner | Control implementers, legal/compliance | Risk owner's manager |
Comparing against Annex A | ISMS Manager | ISMS Manager | Internal auditor, control owners | Risk owner |
Building/updating the SoA | ISMS Manager | Top management (ultimate ownership) | Risk owners, control owners | All ISMS stakeholders |
Writing the RTP action/owner/timeline | ISMS Manager (facilitates) | Risk owner (commits to it) | Resourcing managers, action owners | Top management |
Implementing controls | Named action owner | Risk owner | ISMS Manager | ISMS Manager, internal audit |
Approving RTP and accepting residual risk | Risk owner | Risk owner | Top management, legal (if material) | ISMS Manager |
Tracking and reporting status | ISMS Manager | ISMS Manager | Action owners | Top management, risk owners |
The recurring theme in this table is worth saying plainly: the ISMS Manager coordinates almost every step, but is accountable for almost none of the risk decisions themselves. That distinction is precisely what Clause 6.1.3 is protecting — a well-run ISMS function can produce a beautifully organized RTP that still fails audit if the actual risk owners were never in the accountable seat for the decisions that matter.
Typical Implementation Timelines by Risk Severity
Risk owners and finance stakeholders inevitably ask "how long is this going to take" before they ask anything about methodology, so it's worth having a defensible planning heuristic ready rather than negotiating timelines risk-by-risk from scratch. These bands reflect the pattern across mid-market implementations and should be adjusted to your own organization's change-management speed and resourcing reality — they're a starting anchor for negotiation, not a commitment to cite in a contract.
Risk Severity | Typical Time to First Control Live | Typical Time to Full Treatment Complete | Review Frequency Once Treated |
|---|---|---|---|
Critical/High | 2–6 weeks for the fastest-acting control (e.g., MFA, a firewall rule) | 3–6 months for the full control set, longer for infrastructure-heavy Modify plans | Quarterly, minimum |
Medium | 4–12 weeks | 6–9 months, often bundled with a broader project | Semi-annually |
Low | No fixed deadline required, but a documented decision is still mandatory | N/A if Retained; otherwise folded into routine operational backlog | Annually, at risk reassessment |
Notice that "Critical/High" doesn't mean the entire treatment lands in six weeks — it means the highest-leverage single control (often the one that would have prevented the worst-case scenario, like MFA in Meridian's case) goes live fast, while the fuller control set catches up behind it. Sequencing this way — fastest risk reduction first, full completeness second — is a legitimate and auditor-recognized planning approach, provided the RTP's timeline column actually reflects that phasing rather than implying everything lands simultaneously.
flowchart TD
A[Risk identified & rated in Risk Register] --> B{Select treatment option}
B -->|Modify| C[Determine controls necessary]
B -->|Retain| C
B -->|Avoid| C
B -->|Share| C
C --> D[Compare determined controls against Annex A]
D --> E[Produce / update Statement of Applicability]
D --> F[Formulate Risk Treatment Plan: actions, owners, timeline, resources]
E --> G[Risk owner approves RTP]
F --> G
G --> H[Implement controls — Clause 8 Operation]
H --> I[Recalculate residual risk]
I --> J[Risk owner accepts residual risk, with review date]
J --> K[Retain documented information as audit evidence]
K -->|Ongoing monitoring / new risks| AIntegrating the RTP with Clause 8 Operation
Clause 6.1.3 produces the plan; Clause 8, Operation is where the plan actually gets executed and where the standard requires you to retain evidence that it was. Clause 8.3 specifically requires implementing the risk treatment plan — which means your RTP is not a planning-phase artifact you file away after the SoA is approved; it is a living operational document that Clause 8 activities feed and consume continuously.
In practice, this means the RTP should be the input to sprint planning for security engineering work, the source list for change management tickets, and the reference document in vendor onboarding for any "Share" option involving outsourcing. When a control listed in the RTP goes live — MFA enforced, a supplier contract clause executed, a backup tier deployed — that's the evidence Clause 8 asks you to retain: configuration exports, signed contracts, test results, ticket closure records. The RTP's status column should never be the only evidence of implementation; it should point to where the real evidence lives.
This is also where new risks surface that didn't exist when the register was first built — a new vendor, a new system, a new regulatory obligation — and Clause 8.2 requires you to re-run risk assessment at planned intervals or upon significant change, feeding new entries back into the same treatment cycle shown in the diagram above. An RTP that's treated as a one-time deliverable for the certification audit, rather than a continuously updated operational document, is the single most common reason organizations pass Stage 2 cleanly and then collect a major nonconformity at the first surveillance audit — exactly what happened at Meridian.
Practically, this argues for owning the RTP inside whatever system already runs your operational work rather than a separate, easily-forgotten compliance file. Organizations that fold RTP actions directly into their existing ticketing system, project tracker, or GRC platform — with a tag or custom field linking each ticket back to a risk ID — tend to keep their plans current almost by accident, because the work was going to be tracked somewhere regardless. Organizations that maintain the RTP as a standalone document, disconnected from wherever the actual engineering or vendor-management work is tracked, are the ones who rediscover their own plan eighteen months later and find it frozen exactly where they left it.
Common Mistakes in Risk Treatment Plans
After reviewing treatment plans across roughly 200 organizations, the failure patterns repeat with remarkable consistency. Most of them are visible in a five-minute read of the document, before you even interview anyone — a seasoned auditor can often predict which nonconformities are coming just from how the RTP's status column is formatted, long before they sit down with a risk owner. The table below is deliberately ordered from the mistakes that are cheapest to fix (a wording change) to the ones that require a genuine process change (a tracking cadence that has to actually run), because the fix effort matters as much as the diagnosis when you're prioritizing what to correct first.
Mistake | Why It Happens | What Auditors See | Fix |
|---|---|---|---|
Actions restate control names instead of describing real tasks | Faster to write, feels complete | A control catalogue wearing an RTP's clothes | Every action must be independently verifiable — a person could check whether it happened without re-reading the control text |
Owner listed as a department or role, never a name | Avoids naming individual accountability | No one to interview; no accountability trail | Always name a specific person, updated when they change roles |
No resources or budget documented | Plan written before feasibility was checked | Auditor asks "was this ever actually funded?" and the answer is no | Cost and headcount estimate required before a plan is "approved," not after |
Status frozen at "In Progress" indefinitely | No tracking cadence; status is aspirational, not evidenced | Exactly Meridian's failure — the single most common major nonconformity trigger | Timestamp every status change; require a reason for any date slip |
SoA and RTP built as two disconnected documents with no cross-references | Different owners, different timing, no shared control ID scheme | Inconsistent control status between the two documents | Use the same control reference numbering in both; reconcile at every review |
Residual risk never explicitly re-calculated or accepted | Treatment is assumed to eliminate the risk entirely | No sign-off record; risk owner can't say what they accepted | Recalculate likelihood/impact post-control and get a dated signature |
Treatment options never revisited after initial selection | Register treated as write-once | Controls chosen 2 years ago no longer match current risk landscape | Review treatment option at every risk reassessment cycle, not just controls |
Annex A comparison skipped or done superficially | Feels redundant after determining controls directly | Gaps like missing supplier due diligence or logging controls, discovered only after an incident | Walk the full 93-control list deliberately, including controls you're excluding, and justify each exclusion |
"The plans that fail audits almost never fail because the wrong controls were chosen. They fail because nobody can prove the controls were actually put in place, by whom, or that the person accountable for the risk ever looked at it again after the day they signed it." — Elena Sorokin, VP Engineering and Risk Owner, Cascade Retail
Case Study: Vantage Payments — When "Avoid" Was the Right Call
Priya Raghunathan runs GRC at Vantage Payments, a payments processor handling roughly $1.4 billion in annual transaction volume for mid-market merchants. During their first ISO 27001 risk assessment, the register surfaced a high-severity risk tied to a decade-old batch reconciliation process that moved settlement files between Vantage and two legacy banking partners over an unencrypted FTP connection — a control gap that had existed since before Priya joined the company, quietly excluded from prior security reviews because "it's always been that way."
The instinctive treatment option was Modify: encrypt the connection, add monitoring, call it done. Priya's team ran the numbers instead. Migrating the FTP link to an encrypted channel would have required coordinated changes on both banking partners' legacy systems — a nine-month project with external dependencies Vantage didn't control, at an estimated $240,000 in integration cost, to protect a reconciliation process that a newer, already-built API-based settlement pipeline had made functionally redundant for 90% of transaction volume.
Vantage chose Avoid. Over four months, they migrated the remaining reconciliation volume onto the existing encrypted API pipeline and formally decommissioned the FTP service, removing the risk source entirely rather than controlling around it. Total cost: $34,000 in migration engineering, versus the $240,000 the Modify path would have required — and the risk didn't just get smaller, it disappeared from the register. Their Stage 2 auditor specifically cited the decision as a strong example of appropriate treatment-option selection, noting in the audit report that the team could clearly articulate why Avoid was chosen over the more commonly-selected Modify.
"We almost defaulted to encrypting a connection nobody actually needed anymore. Asking 'do we even need this activity' before asking 'how do we secure this activity' saved us $200,000 and gave us one fewer thing to ever worry about again." — Priya Raghunathan, Head of GRC, Vantage Payments
Metric | Modify Path (rejected) | Avoid Path (chosen) |
|---|---|---|
Estimated cost | $240,000 | $34,000 |
Timeline | 9 months (dependent on two external banking partners) | 4 months (internal migration only) |
Risk after treatment | Reduced but present (encrypted channel still exists) | Eliminated (risk source decommissioned) |
Ongoing maintenance burden | Annual key rotation, monitoring, partner coordination | None — service no longer exists |
Case Study: Brightline Manufacturing — Sharing What Can't Be Fully Modified
Tom Baccarelli, Director of Information Security at Brightline Manufacturing (three plants, roughly 900 employees, legacy OT environment integrated with corporate IT over the past six years), inherited a risk register with a glaring, high-severity entry: ransomware disruption to production-line control systems, rated High on both likelihood and impact, largely because full OT network segmentation and endpoint protection across three plants running equipment from four different eras was a multi-year, multi-million-dollar undertaking that could not be completed before the next audit cycle — or arguably ever fully "complete" given the equipment refresh cycle.
Rather than let this become another Meridian-style perpetual "In Progress," Brightline's RTP explicitly combined Modify and Share. The Modify component funded a phased three-year segmentation and EDR rollout, prioritized by plant criticality, with year-one funding of $340,000 covering the highest-risk plant first. The Share component bound a cyber insurance policy with a specific business-interruption rider sized to Brightline's calculated maximum single-plant downtime cost ($1.8 million per week of production stoppage), at an annual premium of $95,000 — explicitly documented in the RTP and residual risk acceptance record as the mechanism covering the risk that remained during the multi-year Modify rollout.
Eighteen months in, a ransomware attempt hit Brightline's second plant, the one not yet reached in the segmentation rollout. EDR deployed under phase one at the first plant meant the attack didn't cross plant boundaries, but the second plant's line was down for four days. The insurance rider covered $1.1 million of the resulting business interruption loss. Brightline's auditor, reviewing the incident afterward as part of the next surveillance audit, found the RTP's phasing, the insurance binding, and the residual risk acceptance record all lined up with what actually happened — no nonconformity, and a specific auditor note that the documented residual risk acceptance made the incident "a materialized, accepted risk handled as planned" rather than a control failure.
"The board wanted zero risk. That was never on the table for a three-plant OT environment on our timeline and budget. What we could give them was a documented, honest number for what remained, and a policy sized to actually cover it. When the incident happened, nobody was surprised, and nobody had to explain why we hadn't done something we'd never claimed we would." — Tom Baccarelli, Director of Information Security, Brightline Manufacturing
Metric | Value |
|---|---|
Year-one Modify investment (Plant 1 segmentation + EDR) | $340,000 |
Annual cyber insurance premium (Share) | $95,000 |
Business interruption loss, Plant 2 incident | ~$1.6 million (estimated, 4 days at $1.8M/week run rate less partial mitigation) |
Amount covered by insurance rider | $1.1 million |
Audit outcome | No nonconformity — incident treated as documented, accepted residual risk materializing as planned |
Case Study: Cascade Retail — Fixing a Register That Looked Fine and Wasn't
Cascade Retail, a 60-location specialty retailer, passed its initial ISO 27001 certification with a risk register and RTP that read well on paper — until Elena Sorokin, brought in as VP Engineering and made risk owner for infrastructure risks post-certification, actually sat down with the plan six months later and started asking her own team to demonstrate each control. Of fourteen "Implemented" controls attributed to her risk domain, four turned out to be partially configured, and one — data leakage prevention rules tied to a retained customer-payment risk — had been implemented in a test environment during a proof-of-concept and never promoted to production, with the RTP status updated to "Implemented" based on the POC result.
Elena's fix wasn't a new template; it was a verification pass. She required every "Implemented" or "Verified" status to carry a link to concrete evidence — a config export, a screenshot with a timestamp, a closed change ticket — reviewable by anyone, not just the person who wrote the status. Of the fourteen controls reviewed, ten were corrected within six weeks at minimal cost (mostly configuration completion, not new spend); the DLP gap required $28,000 in additional tooling to properly productionize. Cascade's next internal audit, run before the external surveillance visit, found and closed all of it internally — meaning the external auditor found a clean, evidenced RTP rather than the gap Elena's team had actually inherited.
The broader lesson Elena took from it, and the one she now trains every new risk owner on: a status field is a claim, not a fact, until someone who didn't write it can verify it independently.
Metric | Before Verification Pass | After Verification Pass |
|---|---|---|
Controls marked "Implemented" without evidence | 14 of 14 (100%) | 0 — all now link to config export, ticket, or contract |
Controls found only partially configured | 4 | 0 (corrected within 6 weeks) |
Controls found not actually in production | 1 (DLP, stuck in POC) | 0 (productionized at $28,000 additional spend) |
External audit result | Not yet tested at time of discovery | Clean — no nonconformities on Elena's risk domain |
Audit Evidence Checklist for the Risk Treatment Plan
Every mistake catalogued above eventually shows up as a specific document request during an audit. It's worth working backward from that request list before the audit, not during it. This is the checklist I hand teams preparing for Stage 2 or a surveillance visit — if any row is blank, that's a finding waiting to happen, not a hypothetical one.
Evidence Item | Where It Should Live | What a Missing Item Signals to an Auditor |
|---|---|---|
Current risk register with calculated risk levels | Risk register (linked from RTP) | Treatment decisions can't be traced to an assessed risk |
Treatment option and rationale per risk | RTP or treatment-decision log | Options were chosen without justification — a Clause 6.1.3(b) gap |
Determined controls with Annex A cross-reference | RTP + SoA | Comparison step (6.1.3(d)) wasn't performed or documented |
Statement of Applicability, current version | SoA document | 6.1.3(e) requirement not met; likely a major nonconformity |
RTP with all eight fields populated per active risk | RTP document | Treatment plan exists in name only — Meridian's failure mode |
Dated risk owner approval of the RTP | Sign-off record (signature, email approval, or GRC platform log) | No evidence risk owners — not just the ISMS Manager — approved the plan |
Dated residual risk acceptance, with review date | Residual risk acceptance record | Cannot demonstrate 6.1.3(f)'s second approval requirement |
Implementation evidence for "Implemented"/"Verified" controls | Config exports, tickets, contracts, test results | Status fields are unverifiable claims, as at Cascade Retail before its fix |
Status change history / audit trail | GRC platform log or version-controlled document | No way to distinguish an actively tracked plan from a static file |
Record of RTP review at management review meetings | Management review minutes | Top management oversight of risk treatment can't be demonstrated |
Keep this list next to your RTP template and populate it continuously rather than reconstructing it in the two weeks before an audit — reconstruction after the fact is exactly how organizations end up backfilling evidence, which experienced auditors can usually spot from inconsistent timestamps alone.
The Strategic Close: A Plan Is a Competitive Asset, Not a Compliance Chore
It's tempting to treat everything in this article as audit theater — fields to fill in so a certification body signs off once a year. That framing gets the value backwards. A risk treatment plan that's actually executed is one of the few ISMS artifacts that pays for itself outside of the audit entirely: it's a prioritized, funded, owned engineering and operations roadmap for the risks that could genuinely hurt the business, cross-referenced to a defensible rationale for every dollar spent and every dollar deliberately not spent. Boards increasingly ask for exactly this document, in exactly this shape, independent of certification — a named owner, a cost, a date, and a residual number they can understand — because it's the clearest artifact in the entire security program for answering "what are we actually doing about the things that could hurt us, and how do we know."
Dana Whitfield's Meridian didn't fail because the risks were unknown or the controls were exotic. Every control that would have prevented the incident — MFA, segregation, access review, supplier contract terms — was already correctly identified in the risk register eleven months before the breach. It failed because the plan was never treated as a commitment with a name and a date attached, and nobody built the habit of checking. That's a solvable, unglamorous, entirely operational problem — which is good news, because it means fixing it doesn't require a bigger budget or a different framework. It requires the eight fields in Step 5, a review cadence that actually runs, and risk owners who understand that "In Progress" is a temporary state, not a permanent address.
If you're building or repairing your own risk treatment process, start by pulling your current register and running every open risk through the four-option framework in this article rather than defaulting everything to Modify. Cross-check your resulting control set against the full Annex A list deliberately, including the controls you plan to exclude. Then build the RTP with all eight fields, get it in front of the actual risk owners for a dated signature, and put a recurring review on the calendar before you close the document, not after. For a structured starting point, PentesterWorld's ISO 27001 Risk Register Template and linked treatment-plan tab, our Risk Scoring Calculator for consistent likelihood/impact math across every risk owner, and the hands-on Build a Sample Risk Treatment Plan lab will get a working draft in front of your risk owners in an afternoon rather than a quarter. And if you're mapping the full certification journey around this one clause, our Complete ISO 27001 Implementation Guide eBook walks the RTP into the surrounding Clause 4–10 lifecycle end to end. Cross-framework teams managing parallel obligations will find the same treatment-and-acceptance logic echoed in SOC 2's risk mitigation criteria under the common criteria and in NIST CSF's Respond and Recover functions — the vocabulary differs, but auditors across all three are ultimately asking the same question this article answers: who decided what to do, and can you prove they did it.