ISO 27001 Clause 6.3 — Planning of changes
The newest requirement in the standard: two lines that say changes to the ISMS have to be planned rather than absorbed
Clause 6.3 requires 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. That is the entire text. It is the only genuinely new clause the 2022 edition introduced, and it closes a gap that used to be argued about in every transition audit.
📌 Quick navigation
What the clause asks for
Read the trigger carefully: it is when the organisation determines the need for changes to the ISMS. This is about the management system itself — its scope, its policy, its processes, its objectives, its roles, its controls — not about every change in the IT estate. Ordinary technical change is handled under clause 8.1 and the Annex A change management control.
“In a planned manner” is not defined, and that is deliberate. The standard does not prescribe a form, a document or an approval chain. What it rules out is the opposite: ISMS change that simply happens — a scope that quietly widens, a process that drifts, a control that is dropped because nobody was running it any more.
There is no documented information requirement in 6.3. But a change carried out in a planned manner leaves a trace almost by definition, and an auditor who cannot find one will ask how you know it was planned.
What it looks like in practice
| Change to the ISMS | What planning it properly looks like |
|---|---|
| Scope change — a new site, entity, service or country | Impact assessed on the risk picture, the Statement of Applicability and the certificate; scope document updated and re-approved; the certification body informed. |
| New or revised process | Criteria defined before the change, owner named, the interaction with other ISMS processes checked — the point clause 4.4 makes about processes and their interactions. |
| Change of objectives | Re-planned against the five questions in clause 6.2: what, resources, who, when, how evaluated. |
| Change of roles or authorities | Reassigned and communicated, per clause 5.3 — including the two responsibilities the standard names. |
| Change of risk criteria or method | Consequences for comparability considered before the change, so that repeated assessments still produce comparable results. |
| Change of supplier or outsourced process | Risk assessed before contracting, per clause 8.2, and the arrangement brought under control per 8.1. |
| Transition to a new edition of the standard | A project with a plan, a gap analysis and dates — the most visible example of this clause in action. |
You do not need a new procedure for this. In most organisations the cleanest answer is to bring ISMS changes inside the change process that already exists, with a short additional step: what does this change do to the scope, the risks, the SoA, the objectives and the roles? A change request form with those five lines satisfies 6.3 completely.
The second option is to make it an explicit output of management review. Clause 9.3.3 already requires the review to produce decisions on any needs for changes to the ISMS — which is exactly the trigger 6.3 names. If those decisions carry an owner, a date and a check that the change landed, 6.3 is met without any new machinery.
Read 6.3 together with clause 8.1. 6.3 plans the change; 8.1 requires planned changes to be controlled and the consequences of unintended changes to be reviewed. Between them they cover change you chose and change that happened to you.
What an auditor will want to see
- Evidence that ISMS changes went through a defined route rather than happening informally — change records, project plans, or management review decisions.
- For a scope change: an updated and re-approved scope document, and the downstream effects worked through.
- Management review records (9.3.3) showing decisions on needs for changes, with owners and dates.
- A Statement of Applicability whose version history reflects the changes that were made to it.
- Evidence that a planned change was checked afterwards — that it did what it was supposed to do.
Where it usually goes wrong
| Pattern | Why it fails |
|---|---|
| Treating 6.3 as IT change management | It is about the management system, not the estate. Pointing an auditor at the server change queue answers a different clause. |
| Scope drift | The organisation acquires a site, a product or a country and the ISMS scope follows months later, informally. This is the failure 6.3 was written for. |
| A new procedure nobody uses | Writing a standalone “ISMS change procedure” because the clause is new. Integrating into the existing change process works better and is what the standard actually asks for. |
| Changes decided and never landed | Management review decides the ISMS needs changing and nothing tracks whether it happened. The decision is not the plan. |
| No check after the change | Planned, executed, never verified. A change that did not achieve what it was for is the same problem as one that was never planned. |
What changed in the 2022 edition
Clause 6.3 did not exist in the 2013 edition. It was introduced with the 2022 edition through Amendment 1 (published 2024), which added it to ISO/IEC 27001:2022 and to the other management system standards built on the same harmonised structure.
That has a practical consequence during transition: a gap analysis run against the 2013 edition will not have looked for it, and an ISMS that was perfectly conformant in 2021 can have nothing at all to show here. It is one of the cheapest gaps to close — usually five lines added to an existing change form — and one of the easiest to overlook.
Check your copy of the standard: an ISO/IEC 27001:2022 print that does not contain clause 6.3 predates Amendment 1.
Frequently asked questions
Does clause 6.3 require documented information?
No, it does not name any. In practice a change carried out in a planned manner leaves records, and those records are how you evidence it.
Is this the same as Annex A change management?
No. The Annex A control covers changes to information processing facilities and systems. Clause 6.3 covers changes to the management system itself. Different objects, different evidence.
Do we need a separate ISMS change procedure?
Not necessarily, and usually not. Adding an ISMS impact step to the change process you already run is simpler to maintain and easier to evidence.
What counts as a change to the ISMS?
Anything that alters what the ISMS is or how it works: scope, policy, objectives, processes, roles and authorities, risk criteria or method, the set of necessary controls, or the organisation the ISMS sits in.
Our copy of the standard has no clause 6.3 — is that a problem?
It means your copy predates Amendment 1:2024. The requirement applies; obtain a current copy before the next audit.
Clause 6.3 is a small gap with a simple fix, and it is one of the first things a transition audit looks for. Contact us if you want a second opinion on yours, or take the Practitioner course for the full clause-by-clause treatment.
Where this sits
This page explains the requirement in our own words, for study and orientation. It is not a substitute for the standard: the authoritative text is ISO/IEC 27001:2022, available from ISO and from national standards bodies.
