ISO 27001 Clause 6.3: Planning of Changes
Clause 6.3 requires that any changes to your ISMS are carried out in a planned manner. This is one of the shortest clauses in ISO 27001:2022, but it addresses a real operational problem: organizations that make ad hoc changes to their security management system often introduce gaps, inconsistencies, or break things that were working.
What the clause requires
Clause 6.3 states that when the organization determines the need for changes to the ISMS, the changes shall be carried out in a planned manner. It was added explicitly in the 2022 revision of the standard (it did not exist in ISO 27001:2013) and aligns with similar change planning requirements in other ISO management system standards.
The clause requires you to consider:
- The purpose of the change and its potential consequences
- The integrity of the ISMS - will the change maintain the system’s effectiveness?
- Availability of resources to implement the change
- Allocation or reallocation of responsibilities and authorities
This is deliberately broad. The standard does not prescribe a specific change management process - it requires that changes are intentional, assessed for impact, and properly resourced rather than reactive and uncontrolled.
What triggers a Clause 6.3 change
Not every operational adjustment is an ISMS change. Clause 6.3 applies when you modify the management system itself - its scope, processes, policies, or structure. Common triggers include:
Organizational changes. A merger, acquisition, restructuring, or significant growth. A 20-person startup that becomes a 60-person company needs to revisit its ISMS scope, roles and responsibilities, and control implementations.
New regulatory requirements. NIS2 coming into effect, a new data processing agreement with a key customer, or entering a regulated market might require policy updates, new controls, or scope expansion.
Risk landscape shifts. A major incident, a new threat category (such as AI-powered attacks), or a significant change to your technology stack. If your risk assessment identifies new risks that require new controls, the ISMS change should be planned.
Audit findings. Nonconformities from internal audits or certification audits that require structural changes to the ISMS - not just individual corrective actions, but changes to processes or policies.
Technology migration. Moving from on-premise to cloud infrastructure, adopting a new SaaS platform for core operations, or changing your development workflow. These changes affect the technical controls in your Statement of Applicability.
Management review decisions. Changes directed by leadership during management review based on ISMS performance data, changing business strategy, or resource reallocation.
How to plan ISMS changes
You do not need a heavyweight change management process. For most organizations, a structured approach with these elements is sufficient:
Document the change
Before implementing, document what is changing and why. A simple change record should capture:
- What is being changed (scope, policy, procedure, control, role assignment)
- Why the change is needed (trigger event, risk, audit finding, business decision)
- Expected impact on the ISMS
- Who is responsible for implementing the change
- Timeline for implementation
- Resources required
For a SaaS company, this might be a ticket in your project management tool or a section in your management review minutes. The format matters less than the completeness.
Assess the impact
Consider how the change affects other parts of the ISMS. Changing your information security policy might require updates to supporting procedures, training content, and employee acknowledgments. Expanding scope might require a new risk assessment for the added areas.
A useful test: for each proposed change, ask what other ISMS documents or processes reference the thing being changed. Update all of them, not just the primary document.
Implement and verify
Execute the change according to the plan. After implementation, verify that the change achieved its purpose and did not introduce unintended consequences. This might be as simple as a review by the ISMS manager or as formal as an internal audit of the affected area.
Update your documented information to reflect the change. Version histories on your policies and procedures should show when and why changes were made.
Connecting 6.3 to the rest of your ISMS
Clause 6.3 is a cross-cutting clause - it applies whenever any other clause triggers a change to the ISMS.
Clause 4.1-4.3 connection. Changes to your organizational context, interested parties, or scope are ISMS changes that should be planned under Clause 6.3.
Clause 6.1 connection. New risks or opportunities may require changes to controls or processes. The risk treatment response should be planned as a change.
Clause 6.2 connection. Achieving new security objectives often requires changes to existing processes, tools, or structures.
Clause 10 connection. Corrective actions from nonconformities often result in ISMS changes. The improvement cycle and Clause 6.3 work together - the PDCA cycle identifies what needs to change, and Clause 6.3 ensures the change is planned.
What auditors check
Clause 6.3 is typically audited by looking at changes that have already happened, then checking whether they were planned.
Evidence of planned changes. Auditors ask: what has changed in your ISMS since the last audit? They then look for evidence that those changes were planned before implementation. If you expanded your scope but cannot show any planning documentation, that is a finding.
Impact assessment. Auditors check whether you considered the consequences of changes. If you changed a policy but did not update the related procedures, or reassigned a role but did not update the roles document, that indicates unplanned change.
Management review records. Many ISMS changes originate from or are approved during management review. Auditors check the minutes for decisions about changes and whether those decisions were followed through with planned implementation.
Version control on documents. Well-maintained version histories on policies and procedures are indirect evidence of planned changes. Documents that jump from version 1.0 to version 3.0 with no change log raise questions about what changed and whether it was controlled.
Common mistakes to avoid
No change process at all. The most common mistake is simply not having a process for ISMS changes. Organizations update policies, adjust controls, or restructure responsibilities without any documentation of what changed or why. This makes it impossible to demonstrate compliance with Clause 6.3.
Confusing ISMS changes with operational changes. Clause 6.3 applies to changes to the management system, not to every operational change. Deploying a code fix is not an ISMS change. Changing your software development lifecycle process so that security reviews are no longer mandatory - that is an ISMS change. The distinction matters: over-applying Clause 6.3 creates unnecessary bureaucracy, while under-applying it leaves gaps.
Changing documents without updating dependencies. Updating a policy but forgetting to update the procedures that reference it, the training materials that teach it, or the audit checklists that verify it. Every ISMS change has a ripple effect - trace through the impact before closing out the change.
No post-change verification. Implementing a change and assuming it worked without checking. Did the new process actually get followed? Did the updated control achieve its purpose? A brief verification step closes the loop and provides evidence for auditors.
How 27kay can help
We build ISMS change management processes that are proportionate to your organization - lightweight enough to not slow you down, structured enough to satisfy auditors. As part of ISO 27001 implementation, we set up the governance framework that makes Clause 6.3 compliance natural rather than bureaucratic. For the full picture, see our ISO 27001 knowledge hub.
Planning a significant change to your ISMS? Get in touch - we will help you assess the impact and plan it properly.