Risk assessment takes more effort than any other part of an ISMS build, produces the widest variation in quality, and gets probed the hardest at audit. What auditors examine is not the numbers. It is how those numbers came to be assigned, and whether a different person following the same method would arrive at something comparable.
The standard requires that repeated assessments produce consistent, valid and comparable results. That single requirement drives everything practical. Comparability requires fixed criteria; fixed criteria require scales written down before scoring begins. The quality of a risk assessment is set by the design of the criteria, not by the scoring work.
This article organises the process around that design. For the input see Building an Information Asset Register; for the requirement itself, 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. Starting by scoring
The register is done, so scoring begins. This is where most projects lose quality. Criteria design must be finished before scoring starts. Retrofitting criteria while scoring means the first assets assessed and the last are judged differently — a wobble inside one register that auditors reliably detect.
2. Reverse-engineering from Annex A
Listing the 93 controls and inventing a matching risk for each fills the SoA but surfaces none of your own risks. Annex A is a verification checklist, not a starting point — and this is where that principle is most often broken.
3. No balance between coverage and feasibility
A 200-row register expanded by five threats and three vulnerabilities each yields 3,000 risks. Nobody assesses 3,000 properly; the work silently turns mechanical. Estimate how many risks you can genuinely assess, then work backwards to the expansion granularity.
4. Leaving risk owners until last
Decide owners after scoring and the ISMS manager ends up owning everything. A risk owner is the person with authority to decide treatment and to accept residual risk. A register that does not match actual authority is a standard finding.
What You Are Actually Deciding
| Decision | Options | The deciding question |
|---|---|---|
| Approach | Asset-based / scenario-based / both | Coverage or depth |
| Scale points | Three / five | How many assessors, and how fine a priority ordering you need |
| Deriving risk value | Product / sum / matrix lookup | How you want to control the count of high risks |
| Where the acceptance line sits | Which value obliges treatment | Work backwards from what you can treat |
| Risk owner assignment rule | Asset's responsible department / process owner | Do they have authority to decide? |
Asset-based versus scenario-based
The first fork. They are not exclusive, and using both is usually the workable answer.
| Asset-based | Scenario-based | |
|---|---|---|
| Starting point | Each row of the asset register | Plausible events (ransomware, leakage via a supplier) |
| Expansion | Asset × threat × vulnerability | Event → affected assets → path |
| Strength | High coverage, easy to evidence at audit | Closer to lived experience; discussion works, controls get concrete |
| Weakness | Count explodes; turns mechanical | Only surfaces events you imagine; coverage hard to prove |
| Fits | First build, where certification is the goal | Year two onward, raising effectiveness |
Build coverage asset-based the first time, then add your own risks scenario-based. That combination satisfies both the audit and reality.
Three points or five
| Three | Five | |
|---|---|---|
| Assessor variance | Low | High; 2-vs-3 and 3-vs-4 are hard to separate |
| Priority resolution | Coarse | Fine |
| Effort to define the scale | Low | Writing five distinguishable definitions is genuinely hard |
| Fits | Small organisations, first build | Experienced assessors, larger organisations |
For small and mid-sized healthcare companies, start at three. Five looks more precise but, without decidable wording for each point, collapses into a pile of 3s that is coarser than a three-point scale would have been. Revisit in year two once scoring is stable. See also ISMS for Small Organisations.
Where the acceptance line goes
The most consequential decision here. Without a line drawn before scoring, you finish with 200 high risks and no capacity to treat them. The correct order is backwards:
- Estimate the effort and budget available for treatment over the next year
- Convert that into a feasible number of risks to treat (say 30–50)
- Trial the scoring on 20–30 rows and look at the distribution
- Draw the line so the count obliging treatment lands inside step 2
- Record why the line is where it is
Step 5 matters. "Our annual security budget and staffing support roughly N treatments per year, so risks at level X and above fall inside that capacity" is an answer to the audit question about the validity of criteria. "There were too many" is not.
How to Do It
Step 1 — Write the risk assessment procedure first
Document the approach, the scale definitions in words, how risk values are derived, the acceptance criteria, the rule for assigning risk owners, and the frequency and timing. This document is the mechanism that delivers "comparable when repeated."
Step 2 — Define the scales in words
| Score | Consequence | Likelihood |
|---|---|---|
| 3 (high) | Affects business continuity; regulator notification or public disclosure; the customer's clinical operations halt | Current controls cannot prevent it; could occur annually, or a similar event has occurred |
| 2 (medium) | Customer notification required; contractual exposure or damages possible | Controls exist but are incomplete; plausible every few years |
| 1 (low) | Contained internally; recovery costs effort but no external impact | Adequately controlled; occurrence hard to envisage |
In healthcare, define consequence separately for C, I and A. Generic scales lean toward confidentiality, but trial data and clinical records make integrity loss the largest consequence, and EMR integrations make availability loss the largest. One combined scale erases that difference.
Step 3 — Trial on a small sample and look at the distribution
Score 20–30 rows. Problems — everything landing on "medium," or half the register scoring high — are visible here, while adjusting the wording is still cheap. Changing the scale after scoring everything means rescoring everything.
Step 4 — Expand asset-based across the register
Apply threats and vulnerabilities to each row. Control the expansion by preparing a threat catalogue and fixing which threats apply to each asset class — this caps the count and reduces variance between assessors.
| Asset class | Threats to apply |
|---|---|
| Production data in cloud | Unauthorised access, misconfiguration, tenant separation failure, insider misuse, availability failure |
| Endpoints | Loss or theft, malware, unauthorised removal |
| Paper | Loss, theft, overlooking, wrongful disposal |
| Information held by suppliers | Leakage at the supplier, undisclosed sub-contracting, non-return at contract end |
| Tacit knowledge | Recovery impossible after the holder leaves |
Step 5 — Add your own risks scenario-based
Work from events with the engineers and support staff in the room. "What if this happened?" surfaces what no register row implies.
Step 6 — Assign risk owners
Fix the rule first. Usually the head of the department that uses the asset in its work. Test it with two questions: can this person decide whether to treat? Can this person say they accept the residual risk?
| Common assignment | Verdict | Why |
|---|---|---|
| ISMS manager owns everything | Unsuitable | Does not match actual authority; a standard finding |
| IT director owns all technical risks | Conditional | Works if they control budget and headcount |
| Department heads own risks in their own work | Suitable | They can actually decide |
| The CEO owns everything | Unsuitable | Tends to mean nobody is really looking |
Step 7 — Review the results and check the criteria held
Look at the distribution. Far more high risks than planned, or almost none, means the scale or the acceptance line is wrong. Revising at this point is legitimate, but it means rescoring everything and recording why.
Where It Goes Wrong
Everything scores "medium." Guaranteed when the scale lacks decidable wording. Only step 2 prevents it.
The acceptance line set afterwards. Moving the line because "there were too many" is not a justification. Ground it in effort and budget.
Different assessors score the same asset differently. Happens when departments score independently. Beyond distributing the wording, run a short calibration session with worked examples before scoring.
Threats and vulnerabilities conflated. "Access control is inadequate" is a vulnerability, not a threat. Structuring it as "unauthorised access (threat) exploiting inadequate access control (vulnerability)" makes the treatment obvious; conflated, nothing tells you what to fix.
Not a single company-specific risk. A generic threat catalogue applied straight through produces a register indistinguishable from any other company's. Auditors read it as formalistic. Step 5 is the cure.
All risks owned by the ISMS manager. Avoided by fixing the rule in step 6 first.
Changing the criteria in year two. Comparability is lost. Changing for genuine improvement is permitted, but the year you change, you cannot compare to the previous one — record the reason and the effect. Rewriting scale wording unconsciously is the dangerous version.
No date or assessor on the record. Without who assessed, when, and who approved, you cannot show the assessment is actually repeated.
Healthcare Examples
Risk entries that a generic threat catalogue will not produce, and which should be added scenario-based.
A SaaS provider for healthcare institutions
| Risk | C/I/A | Typical cause | Why consequence is high |
|---|---|---|---|
| Multi-tenant separation failure | C | Missing tenant filter in a query; cross-tenant visibility from an admin console | Another hospital's patient data is exposed |
| Uncontrolled production access during support | C | Access without request, approval, time limit or logging | Unrecorded access to the most sensitive data |
| Failure to return or delete customer data | C | No defined procedure at contract end | Contract breach and a guidelines problem |
| Prompt injection into an AI feature | C/I | Insufficient validation of external input; weak permission design | Other patients' information can leak into generated output |
| Coupled failure with an integrated hospital system | A | No failure isolation designed at the integration boundary | Directly halts clinical work |
See AI Voice Charting Security, MCP Permission Design, and Shared Responsibility in AI EMR Security Design.
A PHR operator
Consent management failure stands as its own risk: use continuing after a withdrawal, or scope-change history that cannot be traced. Both map directly to legal breach. See ISMS for PHR Operators.
A clinical trial systems company
A scale weighted toward integrity is mandatory. "A gap in the audit trail" and "retrospective alteration undetectable" carry consequence equal to or above disclosure. Splitting the consequence scale by C, I and A pays off here.
A SaMD developer
Assessment runs in two streams — ISMS risk and product safety risk (ISO 14971). Do not merge them, but make touchpoints explicit: "the update channel is compromised" connects to "malfunction harming a patient." See SaMD, ISMS and QMS.
Common ground: the three-ministry guidelines
The safeguards your hospital customers require overlap with what your assessment already produces. Placing guideline compliance inside the risk treatment plan rather than running it as a separate project keeps management in one place. See Three-Ministry Guidelines and Implementation Steps.
Conclusion
- Quality comes from criteria design, not scoring. Write the procedure first
- Build coverage asset-based, then add your own risks scenario-based. Never reverse-engineer from Annex A
- Start at three points. Without decidable wording, more points do not mean more precision
- Draw the acceptance line backwards from treatable capacity, and record the reasoning
- Risk owners must be able to decide treatment and accept residual risk — department heads, not the ISMS manager
- Trial on 20–30 rows first. Changing the scale after full scoring means rescoring everything
Next comes selecting treatment and deciding acceptance: Risk Treatment Plans and Acceptance and Writing the Statement of Applicability. The input is covered in Building an Information Asset Register.
Pottech supports ISMS certification with a focus on healthcare. Criteria design and surfacing healthcare-specific risks depend on knowing the sector. 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.