Clause 6 is the analytical heart of the ISMS: it is where an organization stops describing its security intentions and starts proving, in a repeatable and defensible way, which risks it faces, what it is doing about them, and how it will know if that's working.
Who this is for / What you'll walk away with
This article is written for the person who actually has to produce the paperwork an ISO 27001 auditor will pull apart line by line: the ISMS manager, the CISO building a certification program from scratch, the compliance lead inheriting a risk register nobody trusts, or the consultant hired six weeks before Stage 1. It assumes you already understand what ISO 27001 is and have read through Clause 4 on context and Clause 5 on leadership. Clause 6 is where those upstream inputs get converted into a working risk assessment methodology, a real risk register, a Statement of Applicability that stands up to scrutiny, a risk treatment plan with named owners, and a set of information security objectives that are more than aspirational slogans.
By the end of this piece you will be able to: build risk criteria that satisfy 6.1.2, run a risk identification-analysis-evaluation cycle that produces consistent and comparable results, choose defensible treatment options, compare your control set against Annex A the way the 2022 revision actually requires, assemble a Statement of Applicability an auditor cannot pick apart in ten minutes, write a risk treatment plan that survives management review, set objectives that are genuinely SMART, and handle the newer 6.3 requirement for planning changes to the ISMS.
The spreadsheet that almost cost Solantis a $2.3 million contract
Priya Deshmukh took over information security at Solantis Health Analytics fourteen months before the company's first ISO 27001 certification audit. Solantis processed claims analytics for a regional hospital network, and that network had made certification a hard condition of a $2.3 million multi-year contract renewal. Priya inherited a risk register that, on the surface, looked professional: ninety-one rows, a five-by-five heat map, color-coded cells, a tab for "mitigations." It had been built two years earlier by a departing IT manager who had, by his own admission, copied the structure from a template he found online and populated it in an afternoon before an internal audit.
The problem surfaced on the first morning of Stage 2. The lead auditor, Marcus Webb, asked Priya to walk him through how the likelihood rating of "3" had been assigned to a row labeled "Unauthorized access to patient claims database." Priya could not answer. There was no record of who had assessed it, what evidence had informed the score, or when it had last been reviewed. Worse, when Marcus cross-referenced the register against the Statement of Applicability, he found six controls marked "implemented" that mapped to no risk in the register at all — and three risks with no corresponding controls anywhere in the SoA. The register wasn't a risk assessment. It was, in his words, "a compliance theater spreadsheet" — a document built to look like risk management rather than to perform it.
"The single fastest way to fail a Stage 2 audit isn't a missing control. It's a risk register nobody can explain the origin of. If you can't tell me who scored it, on what evidence, and when it was last touched, I have to assume it was invented for the audit — and that assumption is very hard to walk back." — Marcus Webb, lead ISMS auditor, quoted in Priya's post-mortem notes
Solantis was issued a major nonconformity against 6.1.2 and given ninety days to remediate before certification could proceed. Priya rebuilt the risk assessment from the ground up over the following ten weeks — a rebuild this article walks through in detail, because nearly everything that went wrong at Solantis maps directly onto a specific requirement in Clause 6, and nearly everything Priya did to fix it is repeatable in any organization.
Where Clause 6 sits in the ISMS and why it matters more than any other clause
Clauses 4 and 5 establish who you are and who is accountable. Clause 6 is where the organization has to demonstrate judgment: which risks matter, how much risk is tolerable, which controls are genuinely necessary, and what "good" looks like in measurable terms. Auditors spend a disproportionate share of audit time here because Clause 6 outputs — the risk assessment methodology, the risk register, the Statement of Applicability, the risk treatment plan, and the objectives — are the artifacts that connect everything else in the standard back to a specific business rationale. A missing training log is a minor nonconformity. A risk assessment that can't explain its own scores is a credibility problem for the entire ISMS, precisely because Clauses 7 through 10 all assume Clause 6 produced something real to act on.
Clause 6 has three sub-clauses, and it's worth being precise about what each one actually demands before diving into methodology, because auditors will ask you to point to exactly where in your documentation each requirement is satisfied.
Sub-clause | Core requirement | Primary output |
|---|---|---|
6.1.1 General | Plan actions that address the risks and opportunities identified from the Clause 4.1 context and 4.2 interested-party requirements; integrate and implement these actions into ISMS processes; evaluate the effectiveness of those actions | Linkage between context analysis and planned actions |
6.1.2 Information security risk assessment | Establish and maintain risk criteria (including acceptance criteria and assessment criteria); ensure assessments are consistent, valid, and comparable; identify, analyse, and evaluate risks; assign risk owners; retain documented information | Risk assessment methodology + risk register |
6.1.3 Information security risk treatment | Select treatment options; determine necessary controls; compare against Annex A; produce a Statement of Applicability; formulate a risk treatment plan; obtain risk owner approval and residual risk acceptance | SoA + risk treatment plan |
6.2 Objectives and planning to achieve them | Set objectives consistent with policy, measurable where practicable, monitored, communicated, and updated; document plans covering what, resources, responsibility, timeline, evaluation | Information security objectives + action plans |
6.3 Planning of changes | Carry out changes to the ISMS in a planned manner | Change planning records |
Notice that 6.1.1 is easy to skip past because it reads like connective tissue rather than a standalone deliverable — but auditors do check it. It requires you to show that the actions you're planning in 6.1.2 through 6.3 actually trace back to the risks and opportunities you identified when you analyzed your context in Clause 4, and to the requirements of interested parties. If your risk register contains risks that have no visible relationship to your documented context analysis, or your context analysis flags issues your risk register never addresses, that gap is exactly what 6.1.1 exists to close.
6.1.1 in practice: closing the loop between context and action
At Solantis, the original context analysis (built for Clause 4) had identified the hospital network's data-handling addendum as a significant external requirement, and had flagged the company's rapid engineering headcount growth as an internal issue. Neither of these showed up anywhere in the old risk register. Priya's rebuilt process started by literally tracing a line from each entry in the Clause 4.1/4.2 register to a corresponding risk or set of risks in the 6.1.2 assessment, and from there to a treatment action. Where a traced line didn't exist — either a context item with no risk, or a risk with no visible context driver — she treated that as a defect to resolve before moving forward.
This traceability exercise does not need to be elaborate. A simple two-column cross-reference — context item on the left, risk ID(s) it drives on the right — is sufficient documented evidence, and it is one of the fastest ways to demonstrate 6.1.1 compliance to an auditor who is otherwise going to ask you to prove the connection verbally. It also catches a common failure mode: risk registers copied from generic templates that address industry-standard risks (ransomware, phishing, insider threat) but never actually engage with the organization's specific context, such as a regulator-mandated encryption standard or a specific interested party's contractual security clause.
Context input (from Clause 4) | Traced to risk ID(s) | Treatment action reference |
|---|---|---|
Hospital network data-handling addendum (interested party requirement) | R-014, R-019, R-027 | TP-004, TP-011 |
Engineering headcount growth (internal issue) | R-031, R-033 | TP-016 |
Cloud provider sub-processor dependency (external issue) | R-008 | TP-002 |
State breach-notification statute (external/legal requirement) | R-019 | TP-011 |
6.1.2: building a risk assessment methodology that survives an audit
ISO/IEC 27001:2022 does not prescribe a specific risk assessment methodology — asset-based, scenario-based, event-based, and threat-based approaches are all acceptable, and organizations frequently blend them. What the standard does require, in unambiguous language, is that the organization establish and maintain risk criteria, and that the process produce consistent, valid, and comparable results every time it's run. That last phrase is the one auditors test hardest, because "consistent, valid, and comparable" is only demonstrable if the criteria are documented before the assessment happens, not reconstructed afterward to justify whatever numbers already existed — which was precisely Solantis's failure mode.
For organizations that want an external reference point rather than building a methodology from a blank page, ISO/IEC 27005 provides detailed risk-management guidance that maps cleanly onto 27001's requirements; it is optional, not mandatory, but consultants frequently use it as a scaffold, particularly for the analysis and evaluation steps.
A documented risk assessment methodology should specify, at minimum: the approach to risk identification (asset-based versus scenario-based, and why), the likelihood scale and what evidence justifies each level, the consequence scale and what dimensions it considers (confidentiality, integrity, availability, legal, financial, reputational), how likelihood and consequence combine into an overall risk level, the risk acceptance criteria that determine when a risk requires no further treatment, and how often assessments and re-assessments occur. Below is the skeleton Priya's team used to rebuild Solantis's methodology; the actual scales are shown in the tables that follow.
Methodology element | Solantis's chosen approach | Documented in |
|---|---|---|
Risk identification approach | Asset-based, cross-referenced against scenario library | Risk Assessment Methodology v2, §3.1 |
Likelihood scale | 5-point, evidence-anchored | Risk Assessment Methodology v2, §3.2 |
Consequence scale | 5-point, multi-dimensional (CIA + legal + financial + reputational) | Risk Assessment Methodology v2, §3.3 |
Risk calculation | Likelihood × Consequence, 5×5 matrix | Risk Assessment Methodology v2, §3.4 |
Risk acceptance criteria | Any risk scoring ≤6 on the matrix, or explicitly signed off by a risk owner regardless of score | Risk Assessment Methodology v2, §3.5 |
Assessment frequency | Full reassessment annually; triggered reassessment on major change (see 6.3) | Risk Assessment Methodology v2, §3.6 |
Risk owner assignment rule | Owner is the individual accountable for the asset or process the risk affects, never IT/security by default | Risk Assessment Methodology v2, §3.7 |
That last row matters more than it looks. A recurring finding across the organizations I've assessed is risk ownership defaulting to the security team for every single risk, regardless of who actually controls the underlying process. A risk concerning third-party contract terms belongs with procurement or legal, not with the CISO — the risk owner has to be someone with the authority to actually accept, treat, or fund treatment for that risk. Auditors will ask a named risk owner to explain their risk in their own words, and "the security team handles that" is a finding waiting to happen.
"I ask every risk owner the same question: 'if this risk materializes tomorrow, whose budget pays for the cleanup and whose job explains it to the board?' Whoever answers that question honestly is the real risk owner — and it's very rarely the CISO for every single line in the register." — Elena Vasquez, enterprise risk manager, financial services sector
Likelihood and consequence scales
Consistency and comparability are only achievable when scoring is anchored to observable evidence rather than gut feel. Vague scales ("low, medium, high") invite different assessors to interpret the same evidence differently, which is exactly what breaks comparability. The tables below show the anchored 5-point scales Solantis adopted — the specific anchor language is illustrative, but the structure (numeric level, label, and an evidence-based definition) is the pattern auditors expect to see.
Table: Likelihood scale
Level | Label | Definition (evidence-anchored) |
|---|---|---|
1 | Rare | No known occurrence in the organization's history or sector; would require a novel or highly sophisticated attack path |
2 | Unlikely | Has occurred in the sector but not observed internally; existing controls provide meaningful resistance |
3 | Possible | Has occurred in similar organizations within the last 3 years; some control gaps exist that a moderately skilled threat actor could exploit |
4 | Likely | Has occurred internally in the last 24 months, or credible threat intelligence indicates active targeting of this asset class |
5 | Almost certain | Currently occurring, or has occurred multiple times internally in the last 12 months with no fully effective control in place |
Table: Consequence scale
Level | Label | Confidentiality/Integrity/Availability impact | Legal/regulatory impact | Financial impact (illustrative) | Reputational impact |
|---|---|---|---|---|---|
1 | Negligible | No sensitive data exposed; brief, contained disruption | No reporting obligation triggered | Under $10,000 | No external visibility |
2 | Minor | Limited internal data exposed; single-system disruption under 4 hours | Internal policy breach only | $10,000–$50,000 | Contained to internal stakeholders |
3 | Moderate | Non-sensitive customer data exposed; disruption to a single business unit | Contractual notification required | $50,000–$250,000 | Client-level awareness, no media |
4 | Major | Sensitive/regulated data exposed; multi-system outage over 24 hours | Statutory breach notification triggered | $250,000–$1,000,000 | Local/trade media coverage |
5 | Severe | Large-scale regulated data breach (e.g., PHI, PII); organization-wide outage | Regulatory investigation and/or fines likely | Over $1,000,000 | National media, client attrition risk |
The risk evaluation matrix and acceptance criteria
Once likelihood and consequence are scored, they need to combine into a single risk level that the acceptance criteria can act on. A standard 5×5 matrix works for most mid-market organizations; larger or more complex organizations sometimes weight consequence more heavily than likelihood, which is a legitimate methodological choice as long as it's documented and applied consistently.
Table: 5×5 risk evaluation matrix (cell values = likelihood × consequence)
Likelihood ↓ / Consequence → | 1 Negligible | 2 Minor | 3 Moderate | 4 Major | 5 Severe |
|---|---|---|---|---|---|
5 Almost certain | 5 | 10 | 15 | 20 | 25 |
4 Likely | 4 | 8 | 12 | 16 | 20 |
3 Possible | 3 | 6 | 9 | 12 | 15 |
2 Unlikely | 2 | 4 | 6 | 8 | 10 |
1 Rare | 1 | 2 | 3 | 4 | 5 |
Table: Risk acceptance bands
Score range | Risk level | Acceptance rule |
|---|---|---|
1–6 | Low | Acceptable without further treatment; reviewed annually |
7–12 | Medium | Requires treatment plan unless risk owner formally accepts with documented rationale |
13–19 | High | Requires treatment plan and quarterly monitoring; owner sign-off required regardless of treatment choice |
20–25 | Critical | Requires immediate treatment plan, executive notification, and monthly monitoring until reduced below 13 |
These bands are the risk acceptance criteria the standard requires under 6.1.2 — they must exist and be documented before any individual risk is scored, precisely so that "why was this accepted" always has an answer that predates the specific risk in question.
Identifying risks: assets, threats, vulnerabilities, and scenarios
With criteria in place, identification is the step where most first-time ISMS teams either freeze (unsure where to start) or drown (trying to catalogue every conceivable threat to every conceivable asset). The workable middle path most experienced practitioners settle on is to build an asset inventory first — even a lightweight one, grouped by information asset category rather than individual device — and then walk each asset group through a threat/vulnerability scenario lens. A full walkthrough of this technique is covered in our dedicated ISO 27001 risk assessment methodology guide, but the shape of the exercise is straightforward enough to describe here.
For each asset group, ask: what threat sources are relevant (external attacker, malicious insider, accidental insider error, environmental/physical, third-party/supply chain), what vulnerability would that threat exploit, and what scenario results. The scenario — not the abstract threat — is what gets scored, because "ransomware" scored in isolation means something different for a database with air-gapped backups than for one without. Solantis's rebuilt register scored 41 scenarios, down from the original 91 rows, because many of the original entries were duplicated threats against the same asset with no distinguishing scenario detail — itself a symptom of a register built to look thorough rather than to be useful.
Asset group | Threat source | Vulnerability | Risk scenario |
|---|---|---|---|
Patient claims database | External attacker | Unpatched database management system, weak network segmentation | Unauthorized exfiltration of claims data via lateral movement from a compromised web server |
Employee laptops | Accidental insider | No full-disk encryption enforced on new hires' devices | Loss or theft of an unencrypted laptop containing cached claims data |
Cloud storage (sub-processor) | Third-party/supply chain | Sub-processor's own access controls not independently verified | Sub-processor misconfiguration exposes a storage bucket containing claims exports |
Engineering CI/CD pipeline | External attacker | Hardcoded credentials in build scripts | Credential leakage through a public repository commit enabling production access |
Physical office (server room) | Environmental | Aging HVAC system with no redundant cooling | Extended cooling failure causes on-premises server outage exceeding recovery time objective |
The risk register: what auditors expect to see in the artifact itself
The risk register is the single document auditors spend the most unsupervised time reading, because it's where every other Clause 6 claim either holds together or falls apart. A defensible register needs, at minimum, a unique risk ID, the scenario description, the asset and threat/vulnerability pairing, likelihood and consequence scores with a brief evidence note for each, the resulting risk level, the assigned risk owner, the chosen treatment option (covered in the next section), the treatment status, and the date of last review. Below is a representative excerpt in Solantis's rebuilt format.
Table: Risk register excerpt (illustrative)
Risk ID | Scenario | Likelihood | Consequence | Risk score | Risk level | Risk owner | Treatment option | Status |
|---|---|---|---|---|---|---|---|---|
R-014 | Exfiltration of claims data via web server lateral movement | 3 | 5 | 15 | High | VP Engineering | Modify | In progress |
R-019 | Loss of unencrypted laptop containing cached claims data | 3 | 4 | 12 | Medium | IT Operations Manager | Modify | In progress |
R-008 | Sub-processor storage misconfiguration exposes claims exports | 2 | 5 | 10 | Medium | Head of Vendor Management | Modify | Planned |
R-031 | Credential leakage from public repository enables production access | 4 | 4 | 16 | High | VP Engineering | Modify | In progress |
R-042 | Extended HVAC failure causes on-premises outage beyond RTO | 2 | 3 | 6 | Low | Facilities Manager | Retain | Accepted |
R-027 | Contractual data-handling addendum breach through inadequate access logging | 3 | 4 | 12 | Medium | Data Protection Officer | Modify | Planned |
Every entry in this table needs a paper trail behind it — a scoring rationale note, the name of who scored it and when, and evidence such as vulnerability scan output, incident history, or threat intelligence citations. Auditors will sample-check two or three rows and ask to see that evidence; the depth of that evidence, not the elegance of the spreadsheet, is what separates a functioning risk assessment from a compliance-theater one. Tooling that structures this properly — a risk register template built around the fields above, paired with a risk scoring calculator that enforces the likelihood/consequence matrix consistently — removes a surprising amount of the human inconsistency that gets flagged in audits.
"Every register I've ever seen fail an audit had the same tell: scores with no comments column, or a comments column full of one-word entries like 'high risk.' If your own team can't reconstruct why a number was chosen six months later, neither can an auditor, and neither, frankly, can you when the risk actually materializes." — David Chen, independent ISO 27001 lead auditor and CISO advisor
Spreadsheet, template, or GRC platform: choosing your risk assessment tooling
Priya's original problem at Solantis wasn't the spreadsheet format itself — plenty of certified organizations run their entire ISMS on well-structured spreadsheets. The problem was the absence of structure, version control, and evidence linkage. Before deciding on tooling, it's worth being honest about what stage your organization is at, because over-investing in a GRC platform before your methodology is stable tends to just digitize the same undocumented judgment calls, and under-investing once you're managing hundreds of risks across multiple business units creates its own audit-trail problems.
Table: Risk assessment tooling options compared
Approach | Best fit | Strength | Watch-out |
|---|---|---|---|
Structured spreadsheet/template | First-time certification, single business unit, under ~75 risks | Low cost, fast to start, easy for auditors to review directly | Version control and evidence linkage must be enforced manually |
Spreadsheet + document management system | Growing ISMS, multiple contributors | Adds change history and approval workflow around the spreadsheet | Still requires discipline to keep risk IDs consistent across versions |
Dedicated GRC platform | Multi-entity organizations, frequent audits, complex supplier risk chains | Built-in workflow, automatic SoA cross-referencing, audit trail by default | Cost and implementation time; risk of "garbage in" if methodology isn't mature first |
Hybrid (GRC platform for register, template for SoA/treatment plan exports) | Mid-market organizations transitioning off spreadsheets | Balances audit-trail benefits with auditor-friendly exportable artifacts | Requires clear ownership of which system is the single source of truth |
Whichever option you choose, a properly structured risk register template is a reasonable starting point even for organizations planning to eventually migrate to a GRC platform, because it forces the field-level discipline (risk ID, owner, evidence note, review date) that the platform migration will otherwise have to retrofit.
Case study: Solantis's remediation and what changed
Priya's ninety-day remediation didn't just rescore the existing register — it rebuilt the methodology first, then reran identification, then rescored. The before/after numbers are illustrative of the pattern I've seen repeated across dozens of similar remediations: the count of distinct risks dropped (from 91 unstructured rows to 41 evidenced scenarios) while the count of risks with a named, accountable owner rose from an estimated 12% to 100%. Three risks that had previously been scored "low" under the old undocumented criteria were rescored "high" once evidence-anchored likelihood definitions were applied — including R-031, the CI/CD credential exposure risk, which had been scored a 2 under the old system based on nothing more than "we haven't had an incident yet."
Solantis passed its follow-up audit six weeks after the ninety-day deadline, with the major nonconformity closed and two minor observations related to evidence retention timelines. The hospital network contract renewed. Marcus Webb's closing note in the audit report, which Priya still keeps on her wall, read simply: "Risk assessment methodology is now traceable, evidence-based, and owned. This is what 6.1.2 looks like when it's real."
Metric | Before remediation | After remediation |
|---|---|---|
Distinct risk scenarios | 91 | 41 |
Risks with a named, accountable owner | ~12% | 100% |
Risks with documented scoring evidence | 0% | 100% |
Risks rescored upward after methodology rebuild | N/A | 3 of 41 |
Time to remediate major nonconformity | — | 10 weeks |
Contract value contingent on certification | $2.3M | Renewed |
6.1.3: from risk assessment to risk treatment
Once risks are identified, analysed, and evaluated, 6.1.3 requires the organization to select treatment options for each risk, determine the controls necessary to implement that treatment, and then — critically — compare those determined controls against Annex A. Four treatment options are recognized across the risk management literature ISO 27001 draws on: modify the risk (apply controls to reduce likelihood or consequence), retain the risk (accept it as-is, typically because it falls within acceptance criteria or treatment cost exceeds benefit), avoid the risk (stop the activity that creates it), or share the risk (transfer it, wholly or partially, via insurance, contractual risk allocation, or outsourcing). Every risk in the register needs one of these four assigned, with a rationale.
Table: Risk treatment options
Option | Definition | When it's the right call | Example from Solantis's register |
|---|---|---|---|
Modify | Apply one or more controls to reduce likelihood, consequence, or both | Risk is above acceptance threshold and cost-effective controls exist | R-014: network segmentation + WAF deployment to reduce lateral-movement likelihood |
Retain | Accept the risk without additional treatment | Risk falls within acceptance criteria, or treatment cost exceeds the risk's potential impact | R-042: HVAC failure risk retained after backup cooling quote exceeded the risk's financial exposure |
Avoid | Eliminate the activity or exposure creating the risk | Risk is disproportionate to business value of the activity | A regional office discontinuing a legacy remote-access tool rather than hardening it |
Share | Transfer risk, in whole or part, to a third party | Specialized insurance or contractual allocation is more efficient than internal control investment | Cyber liability insurance covering breach notification and forensic costs above a defined threshold |
"Retain is not the same as ignore, and I still meet security teams who treat it that way. If you're retaining a risk, someone with the authority to own that decision needs to sign their name to it, on a specific date, with a reason. Otherwise it isn't risk acceptance — it's just a risk nobody got around to." — Tomas Berg, ISMS implementation lead, manufacturing sector
Determining necessary controls — and the subtle but important 2022 shift
This is the part of Clause 6 where the 2013 and 2022 versions of the standard genuinely diverge in approach, and it's worth being precise about the difference because auditors trained on the 2022 revision will specifically probe for it. The 2013 edition of Annex A was often treated, in practice if not strictly in wording, as a selection list: organizations would work through the Annex A control set and pick which ones applied. The 2022 revision inverts the starting point. The organization must first determine, independently, which controls are actually necessary to treat its identified risks — drawing on any source, not just Annex A — and only then compare that determined control set against Annex A, specifically to check that nothing necessary has been omitted.
This is not a cosmetic wording change. Annex A in the 2022 revision (organized into the four themes of Organizational, People, Physical, and Technological controls, totaling 93 controls: 37 organizational, 8 people, 14 physical, and 34 technological) functions as a reference and cross-check set, not a menu you complete by ticking boxes. An organization is entirely permitted to determine that a necessary control isn't in Annex A at all — industry-specific controls, controls mandated by a particular regulator, or controls addressing a scenario the generic reference set doesn't anticipate — and add it to its control set, provided the resulting Statement of Applicability documents that clearly. Readers who want the fuller picture of how Annex A functions as a companion reference rather than a rulebook should also look at how it relates to ISO 27002, which provides implementation guidance for each of the 93 controls, and at the broader summary of what changed between the 2013 and 2022 editions.
Approach dimension | 2013 practice (common interpretation) | 2022 requirement (explicit) |
|---|---|---|
Starting point | Select controls from the Annex A list | Determine controls necessary from risk treatment, independent of Annex A |
Role of Annex A | Effectively a checklist to work through | A reference set used to cross-check completeness |
Justification burden | Justify why a listed control was excluded | Justify inclusions, exclusions, and implementation status for every control, plus justify any necessary control added beyond Annex A |
Risk of gaps | Risk of "checklist compliance" divorced from actual risk profile | Explicit safeguard requiring the comparison step so nothing necessary is missed |
Control count referenced | 114 controls across 14 clauses (2013 edition) | 93 controls across 4 themes (2022 edition) |
Annex A's four themes and their control counts are worth keeping visible while building the comparison, since the Statement of Applicability will ultimately need to account for every one of the 93.
Table: Annex A control themes (2022)
Theme | Control range | Number of controls |
|---|---|---|
Organizational controls | 5.1–5.37 | 37 |
People controls | 6.1–6.8 | 8 |
Physical controls | 7.1–7.14 | 14 |
Technological controls | 8.1–8.34 | 34 |
Total | 93 |
A dedicated walkthrough of what each of these 93 controls actually covers is beyond the scope of this article, though it's exactly the kind of reference piece worth having on hand during the comparison exercise (an "Annex A Controls Explained: All 93" reference doesn't yet exist as a published guide but would be a natural companion here). For the purposes of Clause 6, what matters is the discipline of the comparison itself: take the control set you determined was necessary from your risk treatment decisions, walk it against all 93 Annex A entries one by one, and for every single one — not just the ones you plan to implement — record a decision and a reason.
Building the Statement of Applicability
The Statement of Applicability, universally shortened to SoA, is arguably the single document auditors reference more than any other during a certification audit, because it is the master cross-reference between risk treatment decisions and the actual control set the ISMS operates. The requirement is explicit: the SoA must justify inclusions, justify exclusions, and state the implementation status of every control considered — not merely list the controls that were adopted.
A defensible SoA entry needs, per control: the control reference and title, whether it's included or excluded, the justification for that decision (tied back to a risk, a legal/regulatory/contractual requirement, or a business decision), the implementation status, and — ideally — a pointer to where the implementing procedure or evidence lives. A short, generic justification like "applicable" or "not applicable" with no further explanation is one of the most common SoA findings auditors raise, because it fails the actual requirement, which is to justify the decision, not merely state it.
Table: Statement of Applicability excerpt (illustrative)
Control | Title | Included? | Justification | Implementation status | Linked risk(s) |
|---|---|---|---|---|---|
5.9 | Inventory of information and other associated assets | Yes | Required to support asset-based risk identification across all business units | Implemented | R-014, R-019, R-008 |
5.30 | ICT readiness for business continuity | Yes | Hospital network contract requires demonstrated recovery capability | Partially implemented | R-042 |
6.3 | Information security awareness, education and training | Yes | Addresses recurring phishing-related incidents identified in risk assessment | Implemented | R-014, R-031 |
7.5 | Protecting against physical and environmental threats | Yes | Server room cooling failure risk identified in physical asset review | Planned | R-042 |
8.9 | Configuration management | Yes | Required to prevent CI/CD misconfiguration exposing credentials | In progress | R-031 |
8.23 | Web filtering | No | Risk assessment did not identify web-based content risk as material given existing egress controls; covered instead by 8.20 and 8.21 | Not applicable | — |
6.7 | Remote working | Yes | Engineering headcount growth increased remote access surface | Implemented | R-031, R-033 |
Building this document by hand, control by control, across all 93 entries is exactly the kind of exercise that benefits from a structured starting point rather than a blank spreadsheet; a Statement of Applicability template that pre-populates all 93 Annex A controls with justification and status columns saves most teams several days of setup and reduces the risk of silently skipping a control. A separate practical walkthrough of the SoA-building process — our Statement of Applicability guide — is a natural piece of companion content that sits alongside this one.
"I've stopped accepting 'not applicable' as a justification on its own. Not applicable compared to what? Show me the risk assessment finding, or the absence of one, that led you there. An SoA is a legal-grade justification document, not a checklist." — Aisha Rahman, compliance director, logistics and supply chain sector
The risk treatment plan
Where the SoA documents which controls exist and why, the risk treatment plan documents how they get implemented — the project management layer that sits underneath the SoA's control-level statements. The standard requires the plan to be formulated, and requires risk owners to approve it and to formally accept the residual risk that remains once treatment is applied. A treatment plan without a named owner's signature on both the plan and the residual risk is incomplete under 6.1.3, no matter how well-built the underlying controls are.
Table: Risk treatment plan excerpt (illustrative)
Plan ID | Risk ID | Treatment action | Control(s) applied | Resource/budget | Responsible party | Target date | Residual risk level | Owner approval |
|---|---|---|---|---|---|---|---|---|
TP-004 | R-014 | Deploy network segmentation and WAF between web tier and claims database | 8.20, 8.22 | $48,000 + 0.5 FTE | VP Engineering | 2026-09-30 | Medium (score 8) | Approved 2026-07-02 |
TP-011 | R-019, R-027 | Enforce full-disk encryption fleet-wide; deploy access logging for claims exports | 8.24, 8.15 | $22,000 | IT Operations Manager | 2026-08-15 | Low (score 4) | Approved 2026-07-05 |
TP-002 | R-008 | Complete third-party security assessment of cloud sub-processor; require remediation of findings | 5.20, 5.22 | 0.25 FTE | Head of Vendor Management | 2026-10-01 | Medium (score 6) | Pending |
TP-016 | R-031, R-033 | Implement secrets scanning in CI/CD; mandatory security onboarding for new engineers | 8.9, 6.3 | $15,000 + 0.5 FTE | VP Engineering | 2026-09-01 | Low (score 5) | Approved 2026-07-10 |
Notice that "residual risk level" is not an afterthought column — it's the number the risk owner is actually approving. A common failure I see in practice is owners signing off on the treatment action ("yes, deploy the WAF") without ever being shown, in writing, what risk level remains after that action is complete. That residual number, not the treatment description, is what 6.1.3's approval requirement is actually about: the owner is accepting that Medium score of 8 as the new baseline, not just endorsing an IT project.
A hands-on lab environment that walks through constructing a treatment plan end to end — a sample risk treatment plan build exercise — is useful for teams that learn better by doing this once in a sandboxed scenario before doing it for real against their own register. Our dedicated Risk Treatment Plan implementation guide, covering plan templates, owner sign-off workflows, and how to track partially-completed treatment actions across audit cycles, is a natural companion resource here. Execution of the plan itself — actually implementing the selected controls — is the subject of Clause 8's operational requirements, which picks up exactly where this planning stage leaves off.
Who needs to be in the room
Risk treatment decisions fail quietly when they're made by the security team alone and rubber-stamped by everyone else. The clearest way I've found to prevent that is a simple RACI structure applied to the treatment planning process itself, distinct from the risk ownership already assigned in the register.
Table: RACI for risk treatment planning
Activity | Risk owner | ISMS manager/CISO | Executive sponsor | Finance/procurement |
|---|---|---|---|---|
Propose treatment option | Consulted | Responsible | Informed | Informed |
Approve budget for treatment | Accountable | Consulted | Consulted | Responsible |
Sign off on residual risk | Accountable | Consulted | Informed | Informed |
Track implementation progress | Consulted | Responsible | Informed | — |
Approve Statement of Applicability | Informed | Responsible | Accountable | — |
Getting this structure agreed before the first treatment plan is drafted avoids the single most time-consuming failure mode in Clause 6 implementations: a plan that circulates for signature for weeks because nobody defined in advance who actually has authority to approve it.
Case study: Kordell Manufacturing's SoA rebuild
Kordell Manufacturing, a mid-sized industrial parts producer pursuing certification to satisfy an automotive OEM's supplier security requirements, hit a different but related snag. Their consultant had built a technically accurate SoA — every control correctly marked included or excluded — but every justification read identically: "Applicable per Annex A." Nothing tied any control back to an actual risk assessment finding or business requirement. During the internal audit ahead of Stage 1, Kordell's newly hired ISMS manager, Rosa Fielding, caught the pattern and required every one of the 93 justifications to be rewritten with a specific tie-back: a risk ID, a contractual clause, or a named regulatory driver.
The rewrite took three weeks and, more importantly, surfaced four controls the original SoA had marked "not applicable" that Rosa's team determined were actually necessary once tied properly to the OEM contract's supplier security addendum — including 5.23 (information security for use of cloud services), which the original consultant had excluded on the assumption that Kordell's limited cloud footprint made it immaterial, without checking that footprint against the actual addendum language. Kordell's Stage 1 auditor noted the SoA as a strength rather than a finding, a rare outcome for a first-time certification, and the OEM contract was signed within two weeks of certificate issuance.
Metric | Before SoA rewrite | After SoA rewrite |
|---|---|---|
SoA entries with generic, non-specific justification | 93 of 93 | 0 of 93 |
Controls incorrectly marked "not applicable" | 4 | 0 |
Stage 1 audit findings related to SoA | Anticipated: 2–3 | 0 |
Time from certification to OEM contract signature | — | 14 days |
6.2: information security objectives and planning to achieve them
If 6.1 is about identifying and treating risk, 6.2 is about defining what success looks like — and it's the sub-clause most likely to be treated as a box-ticking afterthought, which is a mistake, because auditors increasingly use objectives as a proxy for whether the ISMS is a living management system or a paper exercise. The standard requires objectives to be consistent with the information security policy (the one established under Clause 5's leadership requirements), measurable if practicable, monitored, communicated, and updated as appropriate. It further requires the organization to retain documented information on the objectives and to maintain a plan describing what will be done, what resources are required, who is responsible, when it will be completed, and how results will be evaluated.
The most common failure I encounter is objectives written as permanent, static aspirations — "maintain a secure environment," "protect customer data" — that read more like policy statements than objectives. These fail the "measurable if practicable" test on their face: there's no way to know, on any given date, whether "maintain a secure environment" has been achieved, exceeded, or missed. A genuine objective has a target, a timeframe, and an evaluation method built in from the start.
"An objective that can't fail isn't an objective. If I can't point to a metric or a milestone and say 'this either happened by this date or it didn't,' it's a value statement, and value statements belong in the policy, not in the objectives register." — Elena Vasquez, enterprise risk manager, financial services sector
Table: Information security objectives (illustrative, SMART format)
Objective | Specific target | Measurable metric | Achievable/resourced | Relevant (linked to risk/policy) | Time-bound | Evaluation method |
|---|---|---|---|---|---|---|
Reduce phishing susceptibility | Reduce click-through rate on simulated phishing to under 5% | Monthly phishing simulation click-rate | Awareness training budget approved, LMS in place | Linked to R-014, R-031 | By Q4 2026 | Quarterly phishing simulation report to management review |
Improve vulnerability remediation speed | Remediate all critical vulnerabilities within 15 days of disclosure | Mean time to remediate (critical severity) | Patch management tooling funded | Linked to R-014 | Ongoing, reviewed quarterly | Vulnerability management dashboard, reviewed monthly |
Complete third-party risk assessments | Assess 100% of critical suppliers against security questionnaire | % of critical suppliers assessed | Vendor risk analyst hired | Linked to R-008 | By Q1 2027 | Vendor risk register completeness audit |
Achieve encryption coverage on endpoints | 100% of company-issued laptops running full-disk encryption | % of managed devices with FDE enabled | MDM tooling already deployed | Linked to R-019 | By Q3 2026 | MDM compliance report, monthly |
Reduce mean time to detect incidents | Reduce MTTD for high-severity incidents to under 4 hours | Mean time to detect, high-severity incidents | SIEM tuning project resourced | Linked to R-014, R-031 | By Q2 2027 | Incident response metrics review, quarterly |
Plans to achieve objectives: the four required elements
The plan attached to each objective must specify what will be done, what resources it requires, who is responsible, and by when — plus how the result will be evaluated. Objectives without an attached plan are the second most common finding I see under 6.2, usually because the objective itself was written but the operational plan lived only in someone's head or in a project tracker nobody connected back to the ISMS documentation.
Table: Plan to achieve objective — worked example
Element | Detail (phishing susceptibility objective) |
|---|---|
What will be done | Deploy monthly phishing simulations; deliver role-specific awareness training to repeat clickers; publish quarterly results to all staff |
Resources required | LMS licensing ($6,000/year), 0.2 FTE security awareness coordinator, management review agenda time |
Responsibility | Security Awareness Coordinator (reporting to CISO) |
Timeline | Baseline measurement month 1; monthly simulations thereafter; target achieved by Q4 2026; reviewed at every management review |
Evaluation method | Click-through rate trend reported to management review; objective closed/renewed based on trend against 5% target |
This structure — what, resources, responsibility, timeline, evaluation — maps directly onto the wording of 6.2 and gives an auditor an unambiguous place to look for evidence that the objective isn't just declared but actively managed. It also gives management review (a Clause 9 activity, but one that depends entirely on Clause 6 having produced something worth reviewing) a concrete agenda item rather than a vague status update.
Objectives that are tracked this rigorously tend to produce a secondary benefit worth mentioning to sponsors and boards skeptical of certification cost: they generate the kind of quantified security improvement data that strengthens the business case and ROI argument for the whole program, because "we reduced mean time to detect from 11 hours to 3.5 hours in one year" is a far more persuasive renewal argument than "we're certified."
Case study: Brightline Payments turns vague objectives into a management tool
Brightline Payments, a fintech processor, had passed its first certification audit with objectives that were technically present but functionally inert: three bullet points in a policy document, none with an owner, none with a date, none ever mentioned again after the certification audit closed. Eighteen months later, at recertification, the auditor asked to see evidence the objectives had been monitored across the intervening period. There was none — the objectives had been set and forgotten, a pattern auditors are increasingly primed to catch given how explicitly 6.2 calls for monitoring and updating.
Brightline's new compliance lead, working with the same underlying risk register, rewrote all three objectives into the SMART format shown above and, crucially, put them on the standing agenda of every quarterly management review with a simple red/amber/green status. Within two quarters, the phishing susceptibility objective had already driven a change in training vendor after the original program failed to move the click-through rate; that kind of course-correction is exactly what 6.2's "monitored... and updated" language is designed to produce, and it only happens when the objective is a live number someone is watching rather than a sentence in a binder.
Metric | Prior cycle (static objectives) | Current cycle (SMART objectives) |
|---|---|---|
Objectives with a named responsible owner | 0 of 3 | 5 of 5 |
Objectives reviewed at management review | 0 times in 18 months | Every quarter |
Objectives with a quantified target | 0 of 3 | 5 of 5 |
Corrective actions triggered by objective tracking | 0 | 2 (training vendor change, MDM policy tightening) |
Recertification audit findings related to 6.2 | 1 (prior cycle) | 0 (current cycle) |
6.3: planning of changes — the 2022 addition
Clause 6.3 is new to the 2022 revision and is easy to underweight because it's short: it simply requires that when the organization determines a need for changes to the ISMS, those changes are carried out in a planned manner. In practice, this closes a gap the 2013 standard left implicit — organizations would add a new business unit, migrate to a new cloud provider, or acquire a company, and the ISMS would either lag behind the change for months or absorb it informally with no record of what was reassessed.
A planned-change record doesn't need to be heavy. What auditors look for is evidence that a defined trigger (a new system, a merger, a significant staffing change, a new regulatory obligation) prompted a deliberate check: does this change affect the context established under Clause 4, does it introduce new risks or change existing risk scores, does it affect the SoA, and does it require new or revised objectives. At Solantis, the acquisition of a small telehealth scheduling startup eight months after certification triggered exactly this kind of planned-change review, which added eleven new risk scenarios to the register and two new SoA entries related to the acquired company's patient-facing mobile application.
Table: Planning of changes — trigger and review checklist
Change trigger | Context (Clause 4) re-check needed? | Risk assessment re-run needed? | SoA update needed? | Objectives re-check needed? |
|---|---|---|---|---|
New business unit or acquisition | Yes | Yes, for acquired assets/processes | Likely | Possibly |
New major system or cloud service | Possibly | Yes, scoped to the new system | Likely | Rarely |
Significant staffing/organizational change | Possibly | Possibly | Rarely | Possibly |
New regulatory or contractual obligation | Yes | Yes, scoped to affected risks | Likely | Possibly |
Office relocation or new physical site | Possibly | Yes, physical/environmental risks | Likely (physical controls) | Rarely |
The discipline 6.3 introduces connects back to everything covered earlier in this article: a risk assessment methodology and a Statement of Applicability are living documents precisely because the organization they describe keeps changing, and 6.3 is the clause that obligates the organization to notice.
The end-to-end flow: from risk to objectives
The diagram below shows how the pieces built across this article connect — risk criteria and identification feeding analysis and evaluation, evaluation feeding treatment decisions, treatment decisions feeding the Annex A comparison and the resulting SoA and treatment plan, and the whole cycle feeding into objectives that get monitored and, per 6.3, revisited whenever something material changes.
flowchart TD
A[Establish risk criteria<br/>6.1.2] --> B[Identify risks<br/>assets, threats, scenarios]
B --> C[Analyse risks<br/>likelihood x consequence]
C --> D[Evaluate risks<br/>against acceptance criteria]
D --> E{Treatment option}
E -->|Modify| F[Determine necessary controls]
E -->|Retain| G[Document acceptance rationale]
E -->|Avoid| H[Eliminate activity/exposure]
E -->|Share| I[Transfer via insurance/contract]
F --> J[Compare controls against Annex A<br/>93 controls, 4 themes]
J --> K[Statement of Applicability<br/>inclusions, exclusions, status]
G --> L[Risk Treatment Plan]
H --> L
I --> L
K --> L
L --> M[Risk owner approval +<br/>residual risk acceptance]
M --> N[Information security objectives<br/>6.2, SMART]
N --> O[Plans to achieve objectives<br/>what, resources, owner, timeline, evaluation]
O --> P[Monitor + management review]
P -->|Material change detected| Q[Planning of changes<br/>6.3]
Q --> A
P --> NCommon pitfalls across Clause 6 — and how they surface in audits
Having reviewed Clause 6 documentation for well over two hundred organizations across a range of sectors, a small set of failure patterns account for the overwhelming majority of nonconformities I've seen raised against this part of the standard. They're worth listing plainly, because most are cheap to fix once named and expensive to discover mid-audit.
Pitfall | How it surfaces in audit | Fix |
|---|---|---|
Risk register with no evidence trail behind scores | Auditor asks "why is this a 3?" and no one can answer | Require a documented rationale/evidence note on every score at the time it's assigned |
Risk ownership defaulted to the security team | Named owner can't speak to the risk's business context | Assign ownership based on who controls the underlying asset or process |
SoA justifications that are generic or copy-pasted | Every entry reads identically; no link back to risk assessment | Tie every SoA entry to a specific risk ID, contract clause, or regulatory driver |
Treatment plans with no residual risk stated | Owner signature exists but approval scope is unclear | State the residual risk score explicitly as the thing being approved |
Objectives with no metric or date | Objective reads as a value statement, not a target | Rewrite using the what/resources/responsibility/timeline/evaluation structure |
No record of planned-change reviews | ISMS documentation predates a known merger/system change with no trace of reassessment | Maintain a lightweight change log tied to the 6.3 trigger checklist |
Annex A treated as a checklist rather than a cross-check | SoA built by walking Annex A top to bottom instead of starting from determined controls | Determine necessary controls from risk treatment first, then compare against Annex A |
"The organizations that struggle with Clause 6 almost never lack technical controls. They lack the paper trail connecting a risk to a decision to a control to an owner. That trail is the actual deliverable of Clause 6 — the controls are almost secondary." — Marcus Webb, lead ISMS auditor
Where Clause 6 fits with the terms you'll keep running into
A handful of terms recur constantly across this stage of implementation — risk owner, residual risk, risk appetite, Statement of Applicability, control — and it's worth having a single, precise reference rather than relying on shifting informal definitions across your team. The ISO 27001 terminology and glossary guide is the companion piece for exactly that, and it pairs well with the broader ISMS core concepts explainer if you or a colleague need the wider system context before diving back into the mechanics covered here. Organizations mapping their ISO 27001 risk work against other frameworks they already run will find the risk criteria and treatment structure in this article translates with only modest adjustment; a fuller side-by-side comparison lives in the ISO 27001 vs. NIST/SOC 2/PCI DSS piece. Teams already maintaining a SOC 2 risk assessment under the Trust Services Criteria can generally reuse much of the same risk register and scoring logic described here, and organizations aligning to NIST CSF's implementation tier model will find their 6.1.2 criteria map closely onto NIST's tiering language. Organizations juggling GDPR obligations alongside ISO 27001 will find much of the risk treatment documentation here does double duty for a GDPR Article 32 risk-based security argument as well (see a fuller GDPR security of processing overview).
Before moving into execution, it's worth pausing on one gap-analysis step many teams skip: benchmarking the maturity of the risk methodology itself, not just the register's contents, against what an auditor will expect walking in. A structured gap analysis tool run against your draft methodology before Stage 1 catches methodology-level weaknesses — undefined acceptance criteria, missing risk owner rules — that a content review of the register alone won't surface.
The strategic close: Clause 6 is where credibility is won or lost
Every organization I've worked with that struggled at certification struggled here first. Not because the controls were absent — most had firewalls, encryption, access reviews, and awareness training in some form long before they ever heard of ISO 27001 — but because they couldn't produce the reasoning that connected those controls to actual risks, actual owners, and actual decisions. Clause 6 is the clause that asks an organization to show its work, and showing your work honestly, including the retained risks and the imperfect residual scores, is what makes an ISMS defensible rather than decorative.
The practical sequence is consistent across every successful implementation I've been part of: build the methodology and criteria before scoring a single risk, identify and score with evidence attached at the moment of scoring, choose a treatment option for every risk with a named accountable owner, determine necessary controls from that treatment and only then check them against Annex A, build an SoA where every justification could survive being read aloud to an auditor, formalize the treatment plan with residual risk stated explicitly, and turn objectives into numbers someone actually watches. Do that once, properly, and Clauses 7 through 10 — support and resourcing, operational execution, performance evaluation, and improvement — have something real to build on rather than a spreadsheet built to survive one afternoon of scrutiny.
If you're building or rebuilding your risk assessment methodology, Statement of Applicability, or risk treatment plan and want a second set of eyes before your next audit, PentesterWorld's ISO 27001 advisory team reviews Clause 6 documentation against exactly the failure patterns described in this article — including a structured gap analysis against your draft methodology and a line-by-line SoA review — before you're sitting across from an auditor asking the same questions Marcus Webb asked Priya Deshmukh. Reach out to scope a Clause 6 readiness review before your next Stage 1 or Stage 2 date is on the calendar.