Clause 6.3 of ISO 27001 requires changes to the information security management system to be carried out in a planned manner. Clause 8.1 adds that planned changes must be controlled and the effects of unexpected changes reviewed. In practice you need a short change record for the ISMS, with an owner, a reason and a check afterwards.
What the clauses say
A public guide to clause 6 lists 6.3, planning of changes, as requiring any change in the ISMS to be done in a planned manner. A guide to clause 8 says 8.1 requires criteria for security processes, control of those processes, control of planned changes, impact analysis of unexpected changes with action to limit harm, and control of externally provided products and services that affect security.
Do not confuse this with the Annex A control on change management (8.32), which is about changes to systems. Clause 6.3 concerns the management system itself.
What counts as an ISMS change
| Change | Why it matters |
|---|---|
| New product or office inside scope | Scope and risk assessment may change |
| Change of a key tool, such as identity provider | Controls and evidence sources change |
| New or replaced critical supplier | Supplier controls and risk change |
| Rewriting a policy or process | Staff must be told and records updated |
| Reorganisation of security roles | Responsibilities must be reassigned and communicated |
| Moving to a new risk method | Past and future assessments must be comparable |
A light change record
For each ISMS change, write down:
- What is changing and why.
- Who owns it and who approves it.
- Which documents, risks and controls are affected.
- The date and how staff will be told.
- How you will check the change worked, and when.
A shared table or ticket type is enough. Auditors want to see that you thought before changing, not a long form.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a check and an approval sit in front of a change before it merges, which is the same idea at code level.
Unplanned changes
Not every change is scheduled. A supplier outage, a departure of the security lead or an emergency tool swap can force a change. Clause 8.1, as summarised, asks you to review the consequences and act to reduce harm. Record what happened, what you assessed and what you did. For tool moves during an audit, see keeping evidence continuous during a tool migration.
Feed changes into management review
List ISMS changes made since the last review in your management review pack, and note any that need a risk reassessment. This ties clause 6.3 to clause 9 and shows the system is managed as a whole.
Quick check
Do we need a separate ISMS change process from our IT change process?
Not necessarily. Some teams extend one ticket system to cover both. The records should show ISMS changes are planned and reviewed.
Is clause 6.3 the same as Annex A change management?
No. Clause 6.3 covers changes to the management system itself. Annex A control 8.32 covers changes to information systems.
Safeguard's policies, gates and guardrails can help enforce review on code changes, and its compliance automation can keep change records together. ISMS level changes are decisions your team plans and records.
Sources
- ISO 27001 clause 6, planning
- ISO 27001 clause 8, operation
- ISO 27001 clause 9, performance evaluation
Last reviewed: 19 October 2026.
