Clause 6 takes the most effort of any part of an ISMS build, and it is where quality diverges most. The risk assessment determines the Statement of Applicability; the SoA determines which procedures you must write; the procedures determine daily operation. Clause 6 is the blueprint for everything that follows.
In practice, though, it often shrinks into "build an asset register and score it." Hundreds of rows filled in mechanically, risk values computed, controls assigned to the high ones. The form is right; whether the result carries any meaning as a management decision is a separate question — and that is exactly what auditors look at.
This article translates Clause 6 into practice: designing risk criteria, running the assessment, producing the SoA, and setting objectives. For prerequisites see Clause 4: Context and Clause 5: Leadership; for the whole standard, 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.
What This Clause Actually Asks For
Clause 6 divides into three parts.
1. Actions to address risks and opportunities
Using the issues and interested-party requirements from Clause 4, determine the risks and opportunities that must be addressed for the ISMS to achieve its intended outcomes. This is the hinge joining Clause 4 to Clause 6.
Within it sit the specific requirements for risk assessment and risk treatment.
Risk assessment, in substance, requires you to:
- Establish risk criteria — both criteria for accepting risk and criteria for performing assessments
- Ensure repeated assessments produce consistent, valid and comparable results
- Identify risks associated with loss of confidentiality, integrity and availability
- Assign a risk owner to each identified risk
- Analyse the consequences and likelihood of each risk and determine its level
- Evaluate levels against the criteria and prioritise for treatment
Risk treatment requires you to:
- Select treatment options for each risk (reduce, avoid, transfer, accept)
- Determine the controls needed for the chosen treatment
- Compare those controls against Annex A to verify nothing necessary has been omitted
- Produce a Statement of Applicability (SoA) recording included controls with justification, excluded controls with reasons, and implementation status
- Produce a risk treatment plan
- Obtain risk owners' approval of the plan and of acceptance of residual risk
The critical framing: Annex A is a checklist for verification, not a starting point. Working top-down through the 93 controls marking "yes/no" runs the standard's logic backwards. Derive controls from your own risks, then cross-check against Annex A for gaps.
2. Information security objectives and planning to achieve them
Set and document objectives at relevant functions and levels. They must be consistent with the policy, measurable where practicable, and take account of applicable requirements and the results of risk assessment and treatment. The plan must state what will be done, what resources are needed, who is responsible, when it completes, and how results will be evaluated.
3. Planning of changes
When the ISMS needs to change, do it in a planned way — assessing the impact before proceeding, rather than reacting ad hoc to each reorganisation, new service or migration.
What You Produce in Practice
| Deliverable | Purpose | Who approves |
|---|---|---|
| Risk assessment procedure | Fixes criteria, scales and method so results stay comparable | ISMS manager (criteria agreed with top management) |
| Information asset register | Identifies what is protected and sets the unit of assessment | Department managers → ISMS manager |
| Risk assessment table | Records identification, analysis, evaluation and the risk owner | Risk owners (department heads, executives) |
| Risk treatment plan | Sets treatment approach, actions, owners and deadlines | Risk owners / top management |
| Statement of Applicability | Lists inclusion/exclusion of the 93 controls with justification and status | Top management |
| Residual risk acceptance record | Makes explicit who accepted what remains after treatment | Risk owners |
| Security objectives register | Objective, metric, target, owner, deadline, evaluation method | Top management |
| Change management procedure | Handles changes affecting the ISMS in a planned way | ISMS manager |
Designing the risk criteria is the first fork. A common approach scores consequence and likelihood on three- or five-point scales and combines them by product or sum. Either is fine, but decide where the acceptance line sits before you start scoring. Skip that and you finish with 200 "high" risks and no capacity to treat them.
Risk ownership is always questioned at audit. The risk owner is the person with authority to decide treatment and to accept residual risk. A register in which the ISMS manager owns every risk rarely matches actual authority and invites a finding. In practice, department heads or executives are the natural owners.
The SoA is the central certification document. For all 93 controls it records inclusion, the justification, and implementation status. An exclusion needs a reason grounded in the risk assessment, not "not needed." If the reason is "we do not develop software in-house, so secure development controls do not apply," that must be verifiable from the asset register and supplier management records. See Writing the Statement of Applicability and Annex A 2022: 93 Controls.
Where It Goes Wrong
An asset register that is too fine or too coarse
One row per laptop produces hundreds of rows nobody maintains. One row for "customer data" is too coarse to yield specific controls. Information type × storage location (system) is usually the workable unit. See Building an Information Asset Register.
Everything scores "medium"
Assessors defaulting to the middle produce no priorities. Prevent it by writing a decidable definition for each point on the scale — for consequence, something like "halts the business" / "requires notifying customers" / "contained internally."
Risks reverse-engineered from Annex A
Listing the 93 controls first and inventing matching risks fills the SoA but surfaces none of your actual risks — multi-tenant data separation failures, prompt injection into an AI feature, a supplier's undisclosed sub-processor. Auditors read this as a formalistic assessment.
Treatment plans with no owner or deadline
"Strengthen access control" cannot be tracked. Without who, by when, doing what, nothing feeds Clause 9 monitoring.
Residual risk acceptance not recorded
Treatment does not reduce risk to zero. If nobody is recorded as accepting what remains, the requirement is unmet. Adding "residual level" and "accepted by / date" columns to the risk table is the simplest fix.
Objectives that cannot be measured
"Raise security awareness" cannot be evaluated. Pair each objective with a metric and a target.
| Objective (weak) | Objective (improved) | Metric | Target |
|---|---|---|---|
| Raise security awareness | All workers complete annual training | Annual training completion rate | 100% by year end |
| Respond to vulnerabilities quickly | Fix critical vulnerabilities within a set window | Mean days to remediate "high" severity | Within 14 days |
| Reduce incidents | Detect and begin response faster | Mean time from detection to first response | Within 4 hours |
| Strengthen supplier management | Complete annual supplier reviews | Share of in-scope suppliers reviewed | 100% |
See Setting Security Objectives and KPIs.
What Auditors Look At
Stage 1 checks the documents exist and the logic holds; stage 2 checks they match reality.
| Aspect | What is asked |
|---|---|
| Criteria set in advance | Were risk and acceptance criteria defined before assessment began? |
| Repeatability | Would a different assessor following the method reach comparable results? |
| Risk owners | Do owners actually have authority to decide treatment? |
| Annex A cross-check | Is there a record of comparing determined controls against the 93? |
| SoA justification | Are exclusions consistent with the assessment results? |
| SoA vs reality | Are controls marked "implemented" actually operating? |
| Measurable objectives | Do objectives carry metrics and targets, with results recorded? |
| Residual risk approval | Is there an owner's approval of residual risk acceptance? |
The most frequent finding is SoA versus reality — a control marked implemented that the floor is not actually operating. Noting, as you write the SoA, which document or record demonstrates each control's implementation makes the audit dramatically easier.
See Common Nonconformities and What Stage 2 Audits Look At.
Healthcare Examples
A healthcare SaaS provider
The indispensable entry is multi-tenant data separation: wrong tenant ID, a missing query filter, cross-tenant visibility from an admin console. Consequence is maximal — another hospital's patient data disclosed — and it rarely appears in a generic IT company's register.
The second is production data access during support and maintenance. Engineers do look at live patient data to investigate incidents; the procedure around it (request, approval, time limit, logging) must be designed as risk treatment. See Shared Responsibility in AI EMR Security Design.
A PHR operator
Because data comes from the individual, consent management failure is a risk in its own right: are grant, withdrawal and scope changes recorded, and can you show actual use stayed inside that scope? This overlaps the personal information law, so managing legal compliance and risk treatment in one plan is efficient. See ISMS for PHR Operators.
A clinical trial systems company
You need criteria weighted toward data integrity. Generic ISMS scoring tends to privilege confidentiality, but in trials "the data was not altered" and "the audit trail is complete" carry enormous consequence. Define the consequence scale separately for confidentiality, integrity and availability.
A SaMD developer
Risk assessment runs in two streams: ISMS risk and product safety risk (ISO 14971). They serve different purposes — protecting information assets versus preventing harm to patients — so do not merge them, but make the touchpoints explicit. A security risk such as "the software update channel is compromised" connects to a safety risk of "malfunction harming a patient."
In every case, folding the safeguards required by the three-ministry guidelines into the risk treatment plan keeps management in one place. See Integrating ISMS Documents with the Three-Ministry Guidelines and Three-Ministry Guidelines.
Conclusion
- Clause 6 is the blueprint for everything downstream: assessment → SoA → procedures → operation
- Annex A is a verification checklist, not a starting point. Derive controls from your risks, then cross-check
- Set risk and acceptance criteria before scoring, or you will produce more high risks than you can treat
- Risk owners must hold real authority to decide treatment and accept residual risk
- The most common finding is SoA diverging from reality. Link each control to the evidence of its implementation
- Objectives need a metric and a target; unmeasurable objectives cannot feed Clause 9
The plan set here gains its people and documentation foundation in Clause 7: Support and is executed in Clause 8: Operation, checked in Clause 9 and fed back through Clause 10. For the hands-on detail see How to Run a Risk Assessment and Risk Treatment Plans and Acceptance.
Pottech supports ISMS certification with a focus on healthcare. Criteria design and SoA quality depend heavily on knowing the healthcare-specific risk entries. 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
- 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.