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

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.

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 clause: Clause 6 · Planning

2013 → 2022 mapping