ISO 27001 · Step-by-step series · Article 3 of 7

ISO 27001 Clause 6: Planning — Information Security Risk Assessment, Treatment and the Statement of Applicability

Clause 6 of ISO 27001:2022 is the engine room of the whole information security management system (ISMS). It is where the organization identifies what could go wrong with its information assets, decides how likely and how damaging each scenario would be, chooses how to respond, and produces the single document every auditor asks for first: the Statement of Applicability. Everything implemented later under clause 8 (operation) and the Annex A controls exists because clause 6 decided it should. This guide walks through each subclause with the practical detail a real implementer needs.

Structure of clause 6: from risk to a documented plan

Clause 6 follows a clear chain: first you decide, in general terms, how you will address risks and opportunities across the whole ISMS; then you run a dedicated process to assess information security risks and decide how to treat them, producing the SoA and the risk treatment plan as outputs; and finally you set measurable information security objectives and the concrete plans to reach them. The subclauses are:

• 6.1.1 General: the umbrella requirement to plan actions addressing risks and opportunities linked to context (clause 4) and interested parties.
• 6.1.2 Information security risk assessment: the criteria, the process, and the identification/analysis/evaluation of information security risks.
• 6.1.3 Information security risk treatment: selecting treatment options, comparing against Annex A, producing the Statement of Applicability, and the risk treatment plan.
• 6.2 Information security objectives and planning to achieve them: setting measurable objectives and the action plans to reach them.
• 6.3 Planning of changes (2022 revision): a new subclause requiring changes to the ISMS to be carried out in a planned manner.

6.1.1 General: planning with context and interested parties in view

Before any risk assessment work starts, clause 6.1.1 requires the organization to consider the issues referred to in clause 4.1 (internal and external issues relevant to the organization's purpose) and the requirements referred to in clause 4.2 (needs and expectations of interested parties, including which of those needs will be addressed through the ISMS), and to determine the risks and opportunities that need to be addressed to give assurance that the ISMS can achieve its intended outcomes, prevent or reduce undesired effects, and achieve continual improvement.

The organization must also plan actions to address these risks and opportunities, how to integrate and implement the actions into its ISMS processes, and how to evaluate the effectiveness of these actions. In practice, this means the risk register isn't built in a vacuum — regulatory exposure, contractual security obligations from clients, cloud migration plans, or a recent supplier breach elsewhere in the sector should all shape which risks get prioritized in 6.1.2.

6.1.2 Information security risk assessment: criteria, process and evaluation

Clause 6.1.2 requires the organization to define and apply an information security risk assessment process that establishes and maintains risk criteria, including a risk acceptance criterion and criteria for performing risk assessments; ensures that repeated risk assessments produce consistent, valid and comparable results; identifies information security risks; and analyzes and evaluates those risks. Each element matters:

• Risk criteria: a documented method for scoring likelihood and consequence, plus a defined threshold above which a risk is unacceptable and must be treated. Without this, two assessors can look at the same risk and reach opposite conclusions.
• Consistency and comparability: the same methodology must produce comparable results across different assets, departments and assessment cycles, so risks can be ranked and prioritized meaningfully over time.
• Risk identification: identifying the risks associated with the loss of confidentiality, integrity and availability of information within the scope of the ISMS, and identifying the risk owners.
• Risk analysis: assessing the potential consequences if the identified risks materialize, assessing the realistic likelihood of their occurrence, and determining the levels of risk.
• Risk evaluation: comparing the results of risk analysis against the risk criteria, and prioritizing the analyzed risks for treatment.

The 2022 revision of ISO 27001 simplified this subclause considerably compared to the 2013 version — it no longer prescribes an asset-threat-vulnerability methodology explicitly, giving organizations more freedom to use event-based or scenario-based approaches. What must still be documented is retained information about the risk assessment process itself, since documented information is a mandatory output of 6.1.2.

6.1.3 Information security risk treatment: options, Annex A comparison, and the SoA

Clause 6.1.3 is where risk assessment turns into action, and it is the subclause that produces the ISMS's single most audited artifact. The organization must define and apply an information security risk treatment process to:

Understanding Annex A's four themes for the SoA

The 2022 revision of ISO 27001 reorganized Annex A from 14 clauses down to 93 controls grouped into four themes, which is the structure your SoA should mirror for each control's applicability decision:

• A.5 Organizational controls (37 controls): policies for information security, roles and responsibilities, supplier relationships, incident management, business continuity, compliance.
• A.6 People controls (8 controls): screening, terms and conditions of employment, security awareness and training, disciplinary process, remote working.
• A.7 Physical controls (14 controls): physical security perimeters, secure areas, equipment siting and protection, clear desk and clear screen.
• A.8 Technological controls (34 controls): access control, cryptography, secure configuration, malware protection, backup, logging, network security, secure development.

A common mistake is treating the SoA as a checkbox exercise — marking every one of the 93 controls as "applicable" without linking each one to a specific risk from the register. A defensible SoA traces backward: every control marked applicable should be traceable to at least one risk it treats, and every risk requiring treatment should be traceable forward to the control(s) implemented to address it.

6.2 Information security objectives and planning to achieve them

Clause 6.2 requires the organization to establish information security objectives at relevant functions and levels. Objectives must: be consistent with the information security policy; be measurable (if practicable); take into account applicable information security requirements, and results from risk assessment and risk treatment; be monitored; be communicated; be updated as appropriate; and be available as documented information.

When planning how to achieve these objectives, the organization must determine: what will be done; what resources will be required; who will be responsible; when it will be completed; and how the results will be evaluated. This mirrors the same discipline as the risk treatment plan — an objective without an owner, a resourced action and a completion date is an aspiration, not a plan the ISMS can be audited against.

6.3 Planning of changes: the new 2022 subclause

Clause 6.3 was added in the 2022 revision and is short but consequential: when the organization determines the need for changes to the ISMS, the changes must be carried out in a planned manner. This closes a gap auditors had flagged under the 2013 version, where organizations sometimes made ad hoc ISMS changes — adding a new cloud provider, changing the scope, restructuring the security team — without re-running the parts of clause 6 that the change affects. A new SaaS platform holding customer data, for instance, should trigger a fresh look at risk assessment (6.1.2), potentially a revised SoA entry (6.1.3), and possibly a new information security objective (6.2), not just a note in the change log.

Common audit findings on clause 6

Recurring gaps seen across ISMS audits when it comes to clause 6:

• 6.1.2 — Risk criteria not defined before assessments start: risks get scored with no documented acceptance threshold, so it's unclear which risks actually require treatment.
• 6.1.3 — SoA controls marked "applicable" with no risk linkage: every Annex A control is marked applicable by default, with no traceability back to a specific risk it addresses.
• 6.1.3 — Exclusions without justification: a control is marked "not applicable" with no documented rationale, which auditors treat as an unjustified scope gap.
• 6.1.3 — No risk owner sign-off on residual risk: the security team accepts risk on behalf of the business without the actual risk owner formally approving the treatment plan.
• 6.2 — Objectives with no measurable indicator: statements like "improve security awareness" with no target, metric, or evaluation method attached.
• 6.3 — ISMS changes made without revisiting risk assessment: a new system or supplier is onboarded and only the asset inventory is updated, without re-running the risk assessment or updating the SoA.

Frequently asked questions about ISO 27001 clause 6

Does ISO 27001 require a specific risk assessment methodology?

No. Clause 6.1.2 requires the organization to define its own risk assessment process with documented criteria, but does not mandate a specific methodology. The 2022 revision removed the explicit requirement to identify assets, threats and vulnerabilities separately, giving organizations flexibility to use asset-based, scenario-based, or event-based approaches — as long as the process consistently produces valid and comparable results.

What exactly must the Statement of Applicability contain?

Per clause 6.1.3 d, the SoA must contain the necessary controls determined through risk treatment, a justification for their inclusion, whether each control is implemented or not, and the justification for excluding any Annex A control. It is not simply a copy of the 93 Annex A controls with a yes/no column — every applicable control should trace back to a specific risk, and every exclusion needs a documented rationale.

Can I exclude Annex A controls entirely if they don't apply to my organization?

Yes. Annex A is a reference list of controls to check against, not a mandatory checklist that must be fully implemented. If your risk assessment shows a control addresses a risk that genuinely doesn't exist in your context — for example, physical entry controls for a fully remote organization with no office premises — you can mark it "not applicable" in the SoA, provided you document the justification clearly.

Who should sign off on residual risk acceptance under clause 6.1.3?

Clause 6.1.3 f requires risk owners — not necessarily the ISMS manager or security team — to approve the risk treatment plan and formally accept the residual risk. A risk owner is typically the person accountable for the asset or business process affected, such as a department head or system owner. Approval by the security function alone, without the actual risk owner's sign-off, is a common nonconformity.

What is new about clause 6.3 in the 2022 version of ISO 27001?

Clause 6.3, "Planning of changes," is entirely new in the 2022 revision. It requires that when the organization determines a need for change to the ISMS — new scope, new systems, restructured teams, new suppliers — the change is carried out in a planned manner rather than informally. In practice this means significant ISMS changes should trigger a review of the affected parts of clause 6: does the change introduce new risks, does it affect the SoA, does it require a new objective.

How does clause 6 connect to clause 8 operational implementation?

Clause 6 is where risks are assessed, treatment options selected, the SoA produced, and objectives set. Clause 8 (Operation) is where the risk assessment and risk treatment plan are actually carried out and the selected Annex A controls implemented. An auditor will typically trace a specific risk from the 6.1.2 register through its treatment decision in 6.1.3, its corresponding SoA entry, and finally to evidence that the control is operating under clause 8 — a broken link anywhere in that chain is a nonconformity.

Expert ISO 27001 · Updated 2026-07-31 · ISO 27001 step-by-step series: Article 1 — Clause 4 · Article 2 — Clause 5 · Article 4 — Clause 7 · Article 5 — Clause 8 · Article 6 — Clause 9 · Article 7 — Clause 10