ISO 27001 Clause 6: Planning, Risk Treatment, and the Statement of Applicability

If Clause 4 defines your world and Clause 5 commits your leadership, Clause 6 is where the ISMS actually decides things: which risks matter, what you'll do about them, and — through the Statement of Applicability — why each of Annex A's 93 controls does or doesn't apply to you. It's the intellectual core of the standard, and the part auditors read most closely. This is part three of our clauses 4–10 series (hub here, Clause 5 before it).

6.1.1 — Risks and opportunities, generally

The clause opens by requiring you to consider the issues from Clause 4.1 and the requirements from 4.2 and determine the risks and opportunities that need to be addressed — so the ISMS achieves its outcomes, prevents or reduces undesired effects, and improves continually. This is the traceability hinge of the whole standard: your context analysis is supposed to feed your risk work. When an auditor finds a context document and a risk register that share no vocabulary, both start looking decorative.

6.1.2 — Information security risk assessment

What it requires: define and apply a risk assessment process that:

• establishes risk acceptance criteria and criteria for when assessments are performed;
• produces consistent, valid and comparable results — the phrase that outlaws vibes-based scoring that changes with whoever ran the workshop;
• identifies risks to confidentiality, integrity and availability of information within the ISMS scope, and identifies risk owners;
• analyzes them — potential consequences, realistic likelihood, resulting level of risk;
• evaluates them — compare against your criteria and prioritize for treatment.

Notably absent from the 2022 standard: any required methodology. Asset-based, scenario-based, a 3×3 matrix or a 5×5 — all fine, as long as the process is documented, criteria exist before scoring starts, and two people running it would land in roughly the same place. If you're building your first register, our startup risk assessment guide covers the practical mechanics.

Evidence in practice: the documented method and criteria, the risk register itself (with named owners — "the company" is not an owner), and results of the assessment being run at planned intervals or after significant change, not once at certification and never again.

6.1.3 — Risk treatment and the Statement of Applicability

What it requires: define and apply a risk treatment process that selects treatment options (modify, retain, avoid, share), determines all controls necessary to implement those options, and then — the standard's most misunderstood step — compares your determined controls with Annex A to verify no necessary control has been overlooked.

Read that order again: you derive controls from your risks first, and Annex A is the checklist you verify against, not the menu you start from. In practice everyone works both directions at once, and that's fine — but the audit story must run risk → control, because that's what the standard says the SoA documents.

The outputs 6.1.3 demands:

• The Statement of Applicability (SoA) — for each Annex A control: is it applicable, justification for inclusion, justification for exclusion, and implementation status. Justifying exclusions is where credibility is won or lost; "not applicable" with no reasoning is a finding waiting to happen, while "A.7.14 excluded — no physical media leaves the cloud provider's custody, see risk R-12" survives scrutiny. (Control-by-control detail lives in our Annex A guide; for software teams, the secure development cluster is the hardest set to exclude.)
• The risk treatment plan — which treatments, who owns them, by when.
• Risk owners' approval of the plan and their acceptance of residual risk — a formal step teams routinely skip. Someone with a name has to say "yes, what remains after treatment is acceptable to me," and there must be a record of them saying it.

The SoA deserves respect for one practical reason: it's the single most-read document in your ISMS. Your certification auditor plans the whole audit from it, and increasingly, enterprise customers ask for it alongside your certificate.

6.2 — Information security objectives

What it requires: establish security objectives at relevant functions and levels. They must be consistent with the policy, measurable if practicable, take into account applicable requirements and the results of risk assessment and treatment, be monitored (an explicit 2022 addition), communicated, updated as appropriate, and available as documented information — with plans that define what will be done, resources, responsibility, deadline, and how results are evaluated.

Good startup-scale objectives look like: "100% of production access behind SSO and MFA by Q3," "median critical-vulnerability remediation under 14 days," "restore test of primary database passes within RTO twice this year." Bad ones look like "improve security posture" — unmeasurable, unownable, and a reliable audit observation.

6.3 — Planning of changes (new in 2022)

What it requires: when the organization determines the need for changes to the ISMS, the changes shall be carried out in a planned manner. That's the entire clause — one sentence, added in the 2022 revision.

It sounds vacuous and isn't: it gives the auditor a hook to ask how last year's changes happened. New scope, new risk methodology, replaced ISMS owner, major architecture shift — was each considered, decided, and documented somewhere (management review minutes count), or did the ISMS just mutate? A short "ISMS changes" log, or a standing agenda item in management review, satisfies it cheaply.

Common Clause 6 nonconformities

• Risks without owners, or owners who left the company — 6.1.2 names risk ownership explicitly.
• An SoA disconnected from the risk assessment. Controls marked applicable "because the template said so," with no risk that motivates them — breaking the 6.1.3 chain.
• Lazy exclusion justifications. "N/A" is not a justification; auditors probe exclusions before inclusions.
• No recorded residual-risk acceptance. Treatment plans exist, but nobody formally accepted what remains.
• Objectives nobody monitors. Written for certification, never measured since — the 2022 "shall be monitored" wording made this an easy finding.

The bottom line

Clause 6 is where auditors separate an ISMS that thinks from one that copies templates. Keep the chain intact — context feeds risks, risks have owners, treatments trace to controls, the SoA justifies every yes and every no, and someone accountable accepts what's left over. Do that and the rest of the audit becomes verification rather than archaeology. Next in the series: Clause 7, Support — resources, competence, awareness, and the documented-information rules that decide whether your evidence counts.