Written By: Alan Parker, ISO 27001 Consultant
Last Updated: 27/4/26

---

Explore Each ISO 27001 Clause in More Detail by Selecting One to View

---

---

What are the subclauses of ISO 27001 Clause 6: Planning?

There are three main clauses within clause 6. Most of the detail is in clause 6.1 (which in turn has 6.1.1 – 6.1.3), and deals with how the organisation handles security risks.

• 6.1 Actions to Address Risks & Opportunities
• 6.2 Information Security Objectives & Planning to Achieve Them
• 6.3 Planning of Changes

Clause 6.3 (Planning of Changes) was added in the 2022 update. The clause structure of 6.1 (with sub-clauses 6.1.1-6.1.3) and 6.2 stayed the same. No other material changes.

Let’s take a look at each one in detail.

---

Clause 6.1 – Actions to Address Risks and Opportunities

Clause 6.1 is about risk management planning.

The full title is “Actions to address risks and opportunities,” which encompasses identifying what could go wrong (risks) and also considering factors that could enhance security (opportunities).

In practice, this clause includes a few sub-requirements:

---

6.1.1 General

This part sets the stage for planning to address risks and opportunities, considering the issues (from 4.1) and requirements (from 4.2).

It’s a general statement that your risk process should consider the context and interested parties. The main meat comes in 6.1.2 and 6.1.3.

---

6.1.2 Information Security Risk Assessment

The standard asks you to establish and implement a risk assessment process here.

You need to identify information security risks associated with the loss of confidentiality, integrity and availability of information within the scope of your ISMS.

There are lots of ways to identify risks and lots of sources. Here are some;

Risk Identification Methods

• Workshops & Interviews – Gather input from staff across departments.
• Brainstorming – Collaborative sessions to surface potential risks.
• Checklists – Based on ISO 27001 Annex A or other frameworks.
• Scenario Analysis – Explore “what-if” situations.
• Asset-Threat-Vulnerability Model – Map risks by linking assets to threats and vulnerabilities.
• Historical Incidents – Review past security breaches or near-misses.

Risk Identification Sources

• Annex A controls – Use as prompts for areas of concern. (We’ll come back to Annex A, and the Statement of Applicability in a moment)
• Internal audits & assessments
• Regulatory and legal requirements
• Industry threat intelligence/news
• Customer requirements or SLAs
• IT system logs and monitoring reports

Risk Assessments

Once you’ve captured your risks in your risk log (in whatever format you deem best), you need to assess them. This is commonly done by scoring the risks using a method such as the following scoring approach for likelihood and impact.

Once you’ve mapped your risks, you can prioritise them based on their scores.

---

6.1.3 Information Security Risk Treatment

Once you know your risks, this sub-clause requires you to design and implement a risk treatment plan. For each unacceptable risk, you decide on a treatment option:

Risk Treatment Plan – What to Capture

The Statement of Applicability

ISO 27001 expects you to select appropriate controls to reduce risks. Many of these controls will come from Annex A (which provides a comprehensive list of 93 control objectives and controls in the 2022 version).

Importantly, Clause 6.1.3 has a specific required output: the Statement of Applicability (SoA).

The Statement of Applicability is a document in which you list all controls from Annex A (and any additional controls you choose outside Annex A) and declare whether each control is applicable to your ISMS and, if so, whether it’s implemented or not.

You also provide a brief justification for inclusion or exclusion.

Example: Control A.9.4.1 (Physical Security Perimeter) is deemed Applicable and Implemented; justification: We have an office space that needs physical protection, door locks, and CCTV. Or Control A.14.2.7 (Outsourced development) – (or) Not applicable; justification: We do not outsource software development. T

The SoA essentially maps risks to controls, ensuring you don’t overlook any control. It’s also a key document that the auditors review to understand your control set​. Think of it as the bridge between your risk assessment and Annex A.

After determining controls, you also form a Risk Treatment Plan—usually a table listing each risk, the chosen treatment/control, the responsible person, and a timeline. Often, organisations combine the risk register and treatment plan into one matrix that shows risk details and the planned controls or actions.

Grab my risk methodology, drafted treatment plans and Statement of Applicability in my ISO 27001 Toolkit.

Opportunities

While the standard heavily emphasises risk (negative things), it also says to consider opportunities. This could be interpreted as any chance to improve security or business that you identify.

For example, an opportunity might be “by adopting a new cloud service, we could improve security and efficiency.” Opportunities are often implicitly addressed by setting improvement objectives (Clause 6.2).

The standard doesn’t require a separate “opportunities register” or anything; just keep in mind that not everything is doom and gloom—if there’s a beneficial initiative that enhances security, that’s an opportunity to note.

Additionally, ISO 27001:2022 introduced Clause 6.1.4 (in effect), which is not numbered but included: it states that you must consider the controls in Annex A as part of your risk treatment (which you do via the SoA).

ISO 27001:2013, older version of the standard, explicitly mentioned “control objectives and controls from Annex A must be compared against your controls”—in 2022, they simplified the wording, but the expectation is the same: use Annex A as a checklist to ensure you’ve considered all typical controls.

Outputs from 6.1: The outputs here are Risk Assessment methodology/process description (some doc describing how you do risk assessment – criteria, scoring, etc.), Risk Assessment results (risk register), Risk Treatment Plan, and Statement of Applicability.

These are all vital documents for ISO 27001. The standard explicitly requires the SoA; you must show risk assessment documentation to the auditor. Many auditors say the risk assessment and SoA are the heart of ISO 27001.

---

Clause 6.2 – Information Security Objectives and Planning to Achieve Them

ISO 27001 Clause 6.2 asks you to set information security objectives at relevant functions and levels and to make plans for achieving those objectives.

Think of this as goal-setting to improve or maintain security. Objectives should be consistent with the information security policy (for example, if your policy says “we continuously improve security”, an objective could be “implement three security improvements this year”).

They should be measurable, if possible, or at least evaluable, and have defined outcomes. They also need to consider applicable requirements and results from risk assessment.

For an SME, typical security objectives might be:

• Reduce the number of virus/malware incidents to zero for the year.
• Achieve 100% staff completion of security awareness training by Q4.
• Improve backup recovery success rate to 100% (test all critical system restores successfully this year).
• Pass the ISO 27001 certification audit by [target date] (that can be a valid objective during implementation).
• Encrypt all laptops by the end of Q2.

Objectives can be both ongoing targets or project-like goals. The standard then requires that for each objective, you determine who will be responsible, what will be done, what resources will be required, when it will be completed, and how results will be evaluated.

This is essentially an action plan for each objective. You can maintain this as an “objectives and plans” table or as part of a management plan document.

For instance, if the objective is to encrypt laptops by Q2, the plan might say: The IT Manager will deploy encryption software to all 50 laptops, the budget is X, it is to be done by June 30, and success will be measured by verification that all devices show encryption enabled.

Key point – Objectives should be revisited regularly (like in management reviews) to see if they’re met or need updates. For initial certification, the auditor will verify that you have set objectives and plans. In later surveillance audits, they’ll look for evidence that you executed those plans and perhaps set new ones.

---

Clause 6.3 – Planning of Changes

Clause 6.3 was added in the 2022 update. Of the three changes to ISO 27001:2022, it’s the smallest in word count but probably the most under-discussed in practice. The standard says simply that “when the organisation determines the need for changes to the information security management system, the changes shall be carried out in a planned manner.”

In other words: don’t change the ISMS without thinking about it first.

That sounds obvious, but it’s a clause born from real-world experience. Auditors had been seeing ISMSs that worked perfectly at certification, then quietly fell apart over the following 12-24 months because changes were made ad hoc – new products added without scope updates, departments restructured without role re-assignments, cloud platforms migrated without risk reviews. 6.3 is the standard’s response to that pattern.

What counts as a “significant change” to the ISMS?

The standard doesn’t define this deliberately. In my experience, the changes most likely to trigger 6.3 in an SME are:

• Scope changes – adding a new business unit, location, or service to the ISMS
• Major system or platform migrations – moving from one cloud provider to another, replacing a core business application
• Organisational restructures – mergers, acquisitions, significant headcount changes that affect ISMS roles
• New regulatory or contractual requirements that materially change what the ISMS needs to address
• New product or service launches that introduce new data flows or risks
• Changes to top management – particularly the ISMS sponsor or lead

Routine changes (a new starter joining, a minor process tweak, a software update) don’t need formal 6.3 treatment. Use judgment – the question is whether the change could meaningfully affect the integrity of the ISMS.

What does 6.3 actually require you to do?

When a significant change is needed, the standard asks you to consider four things: the purpose of the change and its consequences, the integrity of the ISMS (will the change break anything?), resource availability (do you have what you need to make the change properly?), and the allocation or reallocation of responsibilities (do roles need to update?).

In practice, this looks like a short structured note – sometimes just an email, sometimes a one-page record – that captures the change, its impact, the actions taken, and any updates needed to ISMS documentation (risk register, SoA, scope statement, roles document).

Where 6.3 connects to other clauses

6.3 doesn’t sit in isolation. It connects to:

• Clause 4.4 – the ISMS itself, since changes affect its scope and operation
• Clause 6.1 – significant changes typically warrant a fresh risk assessment
• Clause 9.3 – management review explicitly requires you to consider “changes that could affect the ISMS”
• Clause 10 – if a change creates a nonconformity, the corrective action process kicks in

---

Documentation and Outputs for Clause 6

Clause 6 generates some of the most important documentation in the ISMS:

Risk Assessment Methodology/Procedure

A document describing how you perform risk assessments (criteria for risk evaluation, scoring system, etc.). Not always formally required by the standard text, but it’s practically necessary to ensure repeatability. Auditors often ask, “How do you do risk assessment here?” and this doc answers that.

Risk Register / Risk Assessment Report

These records identified risks, their scores, and initial status. Often, an Excel sheet or table. It should show you’ve considered risks across the scope.

Mandatory record: While ISO 27001 doesn’t explicitly list “risk register” as mandatory, it’s implied because you must demonstrate you’ve identified risks and decided how to treat them. (Also, in Annex A control A.5.9, inventory of assets is a similar required artefact feeding into risk assessment​.)

Risk Treatment Plan

A listing of what you will do for each unacceptable risk – essentially, action items to implement controls. This can be combined with or separated from the risk register. Auditors will check that for each high/medium risk, there’s a corresponding treatment.

Statement of Applicability (SoA)

Mandatory document. This is a cornerstone output of Clause 6. It should list all Annex A controls (93 of them in the 2022 version) and for each, whether it’s applied in your ISMS or not, with justification and status​. Ensure this document is current and accurate when you go to audit. It maps to Clause 6.1.3 d).

Auditors scrutinise the SoA to see if your controls make sense. They might also use it to sample controls to verify implementation (e.g., if SoA says antivirus is implemented per control A.8.23, they might later ask to see it in action).

Information Security Objectives and Plans

You should have documented security objectives (Clause 6.2), typically in a list or in the ISMS manual. Also, evidence of planning for each (like an “objectives action plan” table or entries in a project plan). This must be documented (the objectives themselves, and planning information, could serve as a record).

Changes Planning Records

This one can be informal. If you made changes to the ISMS (like mid-year deciding to add a new control or a new department), it’s good to have a note of how you planned it (e.g., an email or meeting minutes). Some might maintain a change log for ISMS changes. At a minimum, incorporate change considerations in your procedures.

---

What Auditors Look For in Clause 6

---

Case Study

During a customer’s ISO 27001 risk assessment, 30 or so major risks were identified, including “Unauthorised access to customer database due to weak passwords.” It was scored as high impact, medium likelihood. The selected treatment was to implement multi-factor authentication (MFA), mapped to the Annex A control on authentication. All pretty standard.

The auditor reviewed the risk register at the audit and noted the treatment plan: “MFA to be implemented by Q4, responsible: IT Security Lead.” They asked if MFA had been implemented and requested evidence, such as access logs. It was okay because it existed.

If the target date is in the future, auditors assess whether the risk is actively managed — checking for interim controls and alignment with the SoA (e.g. authentication control marked “Planned”). In this case, because the risk, treatment, and SoA were consistent and coherent, the auditor was satisfied that Clause 6 was working effectively.

---

Common Mistakes in Clause 6

In ten-plus years of helping organisations through Clause 6, certain mistakes come up so often I can almost predict them at the start of an engagement. None of them is fatal on its own, but they add up – and Clause 6 is where audit findings tend to cluster.

FAQs

---