6.3 — Planning of changes
The shortest requirement in clause 6, and one of the shortest in the whole standard — but it is exactly the kind of thing an auditor asks about after seeing a change that clearly was not planned.
In plain language
In plain language: whenever your organization decides the ISMS needs to change — a new system, a restructured team, a new supplier, a revised risk treatment — that change has to be carried out in a planned way, not improvised as it happens.
Position in the standard
Why this requirement exists
Unplanned changes are where ISMS gaps quietly appear: a new tool gets adopted without anyone updating the risk register, a team reorganization leaves a security responsibility unassigned, a scope-affecting decision gets made without anyone checking it against clause 4.3. This sub-clause exists to catch exactly that.
Scenario: a company migrates its customer database to a new cloud provider over a busy weekend, purely as an IT project, with no one checking whether the ISMS scope, risk assessment, or Statement of Applicability needed updating. Three months later an auditor asks who reviewed the security implications of the migration — and there is no answer.
What the standard expects
The requirement itself is brief: when the organization determines a need for change to the ISMS, that change must be carried out in a planned manner. In practice, this means treating ISMS-relevant changes with the same discipline as any other project: assessing the security impact before making the change, updating affected documentation (scope, risk register, SoA, policies) as part of the change rather than after the fact, and assigning someone accountable for making sure that happens.
In practice
- Add a short "ISMS impact" checkpoint to your existing change management process instead of building a separate one from scratch.
- For any change affecting scope, risk, or controls, update the relevant document (4.3, 6.1.2/6.1.3, or the SoA) before the change goes live, not weeks later.
- Keep a simple log of significant ISMS-relevant changes — what changed, who approved it, what was updated as a result.
Evidence the auditor will ask for
- A change log or change-management records showing security impact was considered for significant changes.
- Evidence that scope, risk, or SoA documents were updated in step with recent changes, not retroactively during audit prep.
Common pitfalls
- Treating this as a separate, heavyweight process instead of a checkpoint inside existing IT or project change management.
- Updating the SoA and risk register in a batch just before the audit instead of as changes actually happen.
Related requirements
6.2 Security objectives
Pursuing an objective is itself a change that needs planning.
6.1.3 Risk treatment
New treatment decisions often trigger ISMS changes covered by 6.3.
8.1 Operational planning and control
Where this planning discipline gets applied operationally, including control of unintended changes.
Parent link: Clause 6 · Planning
2013 → 2022 mapping
Frequently asked questions
Does every IT change need a formal ISMS review?
Keep ISMS changes planned, not improvised.
Sentrix flags when a change affects your risk register or SoA, so nothing slips through unnoticed before the next audit.