The risk assessment is done and a scored list sits in front of you. What happens next decides whether the ISMS becomes a stack of documents or a management mechanism. Risk treatment is as much about deciding what you will not do as what you will. You cannot treat everything. Someone with authority has to decide what gets reduced and what gets accepted — and record it. The presence or absence of that record separates a good audit from a bad one.
In practice, the leading causes of findings in this area are not weak controls. They are that the decision to accept was never recorded, and that actions have no owner or deadline. Both are matters of record format, independent of the substance of the controls — which means knowing the right format in advance avoids them entirely.
This article covers the four treatment options, how to write the plan, and the practice of accepting and approving residual risk. For the input see How to Run a Risk Assessment; for the requirement, Clause 6: Planning; for the standard overall, What Is an ISMS (ISO/IEC 27001)?.
Disclaimer: This article is general information. The authoritative texts are ISO/IEC 27001 (JIS Q 27001) itself and the publications of the accreditation and certification bodies. Base actual decisions on those.
Why This Is Where People Get Stuck
1. Reading "accept" as "do nothing"
Acceptance is an affirmative decision to take no further action on a risk you have recognised. "We didn't treat it" and "we decided to accept it" are entirely different on the record: the first is an omission, the second is a management decision. Yet treatment tables routinely carry blank cells, and the auditor asks: is this acceptance, or has it simply not started?
2. Making everything "reduce"
Use only one of the four options and the action count balloons until the plan is unexecutable. Avoiding the activity, transferring through insurance or contract, and accepting are all legitimate. Not using them reflects unfamiliarity, not caution.
3. A plan that is a list of intentions
"Strengthen access control," "deliver training" — written at that granularity, progress cannot be tracked. Nothing feeds Clause 9 monitoring, and internal audit cannot judge whether it happened.
4. Vague approval
The standard requires risk owners' approval of the treatment plan and of residual risk acceptance. In practice a table drafted by the ISMS manager goes into use with nobody explicitly approving it — and then nothing answers "who took on this risk?"
What You Are Actually Deciding
The four options
| Option | What it is | When it fits | What to record |
|---|---|---|---|
| Reduce | Add or strengthen controls to lower the level | The default; risks inherent in necessary activity | Controls, owner, deadline, residual level after completion |
| Avoid | Stop or do not begin the activity causing the risk | The risk outweighs the business value | Scope of what stops, the alternative, who decided |
| Transfer (share) | Share with others via insurance, outsourcing, contract terms | More rational than handling it yourself | Counterparty, contract terms, the part that cannot be transferred |
| Accept | Take no further action at the current level | Below the acceptance criteria, or treatment costs exceed the loss | Reason, who accepted, date, when it will be reassessed |
Transfer is the most misunderstood. Insurance and outsourcing do not make a risk disappear. Accountability and reputational damage after a breach cannot be transferred. Choosing transfer means recording the transferred part and the part that stays with you, and then reducing or accepting the remainder separately. Where medical information is outsourced, responsibility toward the hospital customer stays with you. See Supplier Security Management.
Avoidance is a stronger option than it looks. If developers copy live patient data onto workstations to investigate defects, stopping that practice and investigating in a masked environment is avoidance. It is more fundamental than reducing (encrypt the workstation better) and often cheaper.
What the plan must contain
The standard asks for what will be done, the resources required, who is responsible, when it completes, and how results are evaluated. As columns:
| Column | Point |
|---|---|
| Risk ID | Ties back to the assessment; without it, treatments have no provenance |
| Treatment option | Reduce / avoid / transfer / accept. Never blank |
| Action | Written so completion is decidable, not "strengthen X" |
| Controls adopted | The Annex A references — this is where SoA consistency is secured |
| Owner | A role, never a person's name |
| Resources | Budget, people, external support. Even "budget approval required" is worth writing |
| Deadline | A date. "In due course" and "ongoing" are not deadlines |
| Completion test | Named deliverable or record |
| Residual level | The score expected after treatment |
| Accepted by / date | A blank here is a guaranteed finding |
How you write "action" determines whether the plan is executable.
| Untrackable | Trackable |
|---|---|
| Strengthen access control | Inventory admin privileges on production and remove unnecessary ones; repeat quarterly thereafter |
| Deliver training | Deliver security training to all workers and reach 100% completion, escalating non-completers to department heads |
| Manage suppliers | Send and collect check sheets from 12 suppliers; revise contract terms for the 3 highest-risk |
| Review backups | Write a restore procedure for production backups and run an annual restore test with a record |
How to Do It
Step 1 — Accept everything below the acceptance line in one decision
Risks below the acceptance criteria are processed in bulk, not individually: record one decision ("risks at or below level X are accepted per the acceptance criteria in the risk assessment procedure") and get it approved by the risk owners or top management. That clears the bulk of the register. Examining these individually is where workload explodes — and it is where the value of having set the criteria in advance is realised.
Step 2 — Prioritise what remains
Order the rest by risk value. If the count exceeds what you can treat, either revisit the validity of the criteria or split into a multi-year plan.
Step 3 — Assign an option to each
Reduce is the default path, but ask whether avoidance works first, then transfer, then reduce. Taken in that order, the action count settles at a realistic level.
Step 4 — Determine controls, then cross-check against Annex A
Once controls are chosen, compare them with the 93 Annex A controls to verify nothing necessary was omitted. The order matters: you are not picking from Annex A, you are checking your choices against it. That verification record becomes the SoA's justification. See Annex A 2022 and Writing the Statement of Applicability.
Step 5 — Add owners and deadlines
Setting deadlines backwards from the internal audit date works well: arriving at internal audit with items verifiably complete sets up the certification audit.
| Band | Deadline | Typical contents |
|---|---|---|
| Immediate | Within 1 month | Risks currently materialising; anything fixed by a configuration change |
| Short | Within 3 months | Procedures, policies, privilege inventories |
| Medium | Before certification | Training delivery, supplier check sheets, technical controls |
| Long | Next year onward | Major system rework, organisational change |
Anything placed in "long" needs a separate decision to accept the residual risk during the interval. "We plan to do it next year" does not count as treated.
Step 6 — Evaluate residual risk and obtain approval
Treatment does not reduce risk to zero. Assess what remains and obtain the risk owner's approval to accept it. This approval comes before implementation, because the judgement is "given this control, the remaining risk will be at this level, and we accept that."
Any of these record formats suffices:
- An approval block on the treatment plan, signed by the risk owner
- Columns for residual level, accepted by, and date on the risk assessment table
- A management review minute recording residual risk acceptance as an agenda item and decision
The third is the most efficient — it avoids per-risk sign-off while demonstrating top management involvement. The minute must identify which risks were accepted (a list of risk IDs, or a reference such as "the residual risks recorded in treatment plan v1.2"). See Running a Management Review.
Step 7 — Put it under progress monitoring
A plan is only a plan when written. Monthly or quarterly progress review, identifying what has slipped, is what connects this to Clause 9.
Where It Goes Wrong
No record of residual risk acceptance. The single most reliably raised finding, because the standard requires it explicitly. Three added columns satisfy it.
No deadline, or "ongoing." Untrackable at internal audit. Put a date on every row.
Owners named as individuals. Transfers and resignations leave the plan orphaned. Use roles.
Examining sub-threshold risks individually. Workload explodes and the high risks get less attention. Handle them in bulk at step 1.
"We transferred it, so it's handled." Insurance and outsourcing move part of the financial loss; accountability and trust stay. State the untransferable remainder and reduce or accept it separately.
Avoidance never considered. A plan containing only reductions tends to be too large. Asking "could we simply stop doing this?" first cuts the count and solves problems at the root.
No completion test. "Done" is reported but nothing defines what done meant. Define completion by a named deliverable or record.
Plan and SoA inconsistent. A control the plan adopts appears as excluded in the SoA, or vice versa. Step 4's cross-check, reflected straight into the SoA, prevents it. This is one form of the most common finding of all — SoA diverging from reality. See Common Nonconformities.
Healthcare Examples
A SaaS provider for healthcare institutions
| Risk | Option | Action | Residual handling |
|---|---|---|---|
| Multi-tenant separation failure | Reduce | Tenant-boundary tests in CI as a mandatory release gate; inventory and block cross-tenant paths in the admin console | Engineering lead accepts what remains |
| Production data access during support | Avoid + reduce | Prohibit production access by default and provide a masked investigation environment; exceptions require request, approval, time limit and logging | Support lead accepts the residual from exception handling |
| Leakage via a development subcontractor | Transfer + reduce | Confidentiality, no sub-contracting, and audit rights in contract; annual check sheet | Records explicitly that accountability cannot be transferred and accepts it |
| Major outage halting customer clinical work | Reduce + transfer | Redundancy plus an annual restore test; SLA defining responsibility | Management accepts exposure beyond the SLA cap |
| Recovery procedure held by one person | Reduce | Write the procedure and run a restore test performed by someone else | Low residual, accepted by the ISMS manager |
Row two is the pattern that matters most: avoidance combined with reduction. Few companies can prohibit production access outright, but "prohibited by default, exceptions controlled" lowers the level dramatically. See Shared Responsibility in AI EMR Security Design.
A PHR operator
Consent management failure leaves reduction as effectively the only option — there is little room to accept or transfer. Treatment means technically guaranteeing that grant, withdrawal and scope changes are recorded and that actual use stays inside that scope. See ISMS for PHR Operators.
A clinical trial systems company
Audit trail integrity is an area with almost no room for acceptance. "Treatment costs exceed the loss" does not hold up, so plan on reduction. A plan that accepts here is hard to defend both at certification audit and in a customer's vendor review.
A SaMD developer
ISMS treatment coexists with product safety risk control under ISO 14971, and the acceptance criteria differ. Information security acceptance reflects organisational tolerance; product safety acceptance is judged against harm to patients on an entirely separate basis. See SaMD, ISMS and QMS.
Common ground: the three-ministry guidelines
The safeguards hospital customers require mostly enter the plan as reductions. Managing guideline compliance as part of the risk treatment plan rather than as a separate project unifies progress tracking and lets internal audit check both in one framework. See Three-Ministry Guidelines and Implementation Steps.
Conclusion
- Treatment is also the process of deciding what not to do. Acceptance is an affirmative decision, not a blank cell
- Put avoidance, transfer and acceptance on the table. A reduce-only plan balloons past what you can execute
- Transfer does not move accountability or trust. State the untransferable remainder and handle it separately
- Every row needs action, owner (a role), deadline, completion test and residual level. "Ongoing" is not a deadline
- Missing residual acceptance records is the most reliably raised finding. Three columns satisfy the requirement
- Accept sub-threshold risks in bulk, preserving attention for the high ones
With the plan settled, reflect it in Writing the Statement of Applicability and carry it into operation via Setting Security Objectives and KPIs. For the inputs see How to Run a Risk Assessment and Writing an Information Security Policy.
Pottech supports ISMS certification with a focus on healthcare. Plan design and acceptance record format are the highest-leverage places to avoid findings. See ISMS Certification Support or contact us.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
- ISO 31000 Risk management | ISO
- Japanese Industrial Standards Committee (JISC)
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Personal Information Protection Commission, Japan
Note: interpretation of requirements and the handling of accreditation and certification are governed by the standard itself and by the publications of the accreditation and certification bodies, and may change with revisions.