ISO 27001:2022 Clause 6.3 Planning of Changes Explained

In this guide you will learn how to implement ISO 27001 Clause 6.3 Planning of Changes and pass your audit from ISO 27001 Lead Auditor Stuart Barker – author of the ultimate ISO 27001 Toolkit.

The 2022 update to the ISO 27001 standard introduced a new control called ISO 27001:2022 Clause 6.3 planning of changes.

There is nothing to worry about here, so let us take a look at what it is and what you have to do.

First off, don’t panic.

Definition

ISO 27001 defines ISO 27001 Clause 6.3 as:

When the organisation determines the need for changes to the information security management system, the changes shall be carried out in a planned manner.

ISO 27001:2022 Clause 6.3

What is ISO 27001 Clause 6.3 Planning of Changes?

The new control ISO 27001 clause 6.3 planning of changes relates directly to changes to the information security management system and that you will make the changes in a planned manner.

There is nothing at all to worry about here and you will have been doing this all along.

It is just now explicit in the standard.

Implementation Guide

To meet the requirement all you have to do is plan your changes to your information security management system and evidence that you managed the change.

This is easy to do if you follow best practice and review and republish your documents annually. Make sure you have a documented plan that shows when you last did it and when you are going to do it again.

You will have a Documents and Records Policy and be following it.

You will use the management review team to sign off your changes and you will update your communication plan with evidence of the communications taking place to communicate those changes.

It is good practice to have version control in your documents but also to keep previous revisions of documents / the information security management system so that you can revert back if needed.

The fact that you will already have continual improvement, incident management, internal audit policies and processes in place already factor in your planning for changes to the information security management system and can be used as evidence of such.

How to implement ISO 27001 Clause 6.3

Implementing ISO 27001 Clause 6.3 requires a structured approach to ensure all changes to the Information Security Management System (ISMS) are planned, assessed, and controlled. This process prevents unintended security gaps and ensures that modifications to people, processes, or technology do not compromise the integrity of your certification. As an ISO 27001 Lead Auditor, I can confirm the following ten steps outline the exact technical requirements to satisfy auditors and maintain operational resilience.

1. Formalise the Change Management Policy

• Action: Establish a documented Change Management Policy that defines the scope of changes requiring formal approval, clearly distinguishing between standard, normal, and emergency changes.
• Result: Sets the foundational governance required to prevent unauthorised modifications and ensures compliance with ISO 27001 expectations.
• Technical Requirements: Categorise changes by risk level (Low, Medium, High), explicitly assign IAM roles for the Change Requester and Change Advisory Board (CAB), and integrate the policy with your existing Information Security Policy and Access Control Policy.

2. Provision a Centralised Change Register

• Action: Deploy a robust mechanism to log, track, and manage all change requests from initiation to closure.
• Result: Creates an immutable audit trail that serves as your primary evidence repository for external audits, ensuring no change occurs off the books.
• Technical Requirements: Utilise a ticketing system (e.g., Jira, ServiceNow) or a dedicated Asset Register, configuring mandatory fields for ‘Reason for Change’ and ‘Back-out Plan’, and directly mapping change requests to specific items in your Asset Inventory.

3. Execute Impact and Risk Assessments

• Action: Conduct a mandatory risk assessment before authorisation for every significant change to evaluate potential security implications.
• Result: Ensures that the modification does not introduce new vulnerabilities or violate existing controls.
• Technical Requirements: Assess the impact on Confidentiality, Integrity, and Availability (CIA) using a standard Risk Assessment Methodology, identify upstream and downstream dependency mapping, and attach the documented outcome directly to the change ticket.

4. Authorise via Competent Authority

• Action: Secure formal approval from the designated authority before any implementation activity begins.
• Result: Enforces the segregation of duties, which is critical for preventing unauthorised or malicious changes to the ISMS.
• Technical Requirements: Convene the CAB for high-risk changes, require digital signatures or timestamped approvals within your ticketing system to validate authorisation, and document a separate approval path for emergency changes.

5. Implement and Validate in Controlled Environments

• Action: Execute the change strictly according to the approved plan, pushing changes to a non-production staging environment first.
• Result: Validates functionality and security configurations, ensuring the change delivers the intended result without adverse effects.
• Technical Requirements: Ensure a tested ‘Back-out Plan’ is ready to revert the system to its previous known good state, and mandate User Acceptance Testing (UAT) confirmation from key stakeholders before production rollout.

6. Architect the Production Deployment Plan

• Action: Architect a detailed deployment schedule and resource allocation strategy for transitioning the validated change into the live environment.
• Result: Guarantees that production modifications are carried out in a planned manner, minimising disruption to core business operations.
• Technical Requirements: Define strict maintenance windows and establish formal Rules of Engagement (ROE) documents for major infrastructure updates.

7. Execute the Change in Production

• Action: Deploy the approved and validated change into the live production environment exactly as detailed in the deployment plan.
• Result: Transitions the system to its new operational state securely and reliably.
• Technical Requirements: Implement real-time monitoring of server logs, network traffic, and system performance metrics during deployment to detect anomalies instantly.

8. Orchestrate Stakeholder Communication

• Action: Orchestrate targeted communication to all relevant stakeholders regarding the scope, timing, and potential impact of the implemented change.
• Result: Minimises user confusion, reduces helpdesk support tickets, and maintains transparency across the organisation.
• Technical Requirements: Automate notifications detailing required user actions, such as password resets or Multi-Factor Authentication (MFA) re-enrolment.

9. Audit and Post-Implementation Review

• Action: Conduct a retrospective review to close the change lifecycle, analysing what went well and identifying areas for process optimisation.
• Result: Drives continual improvement and provides definitive proof to auditors that the change achieved its objectives without causing incidents.
• Technical Requirements: Verify documentation updates across network diagrams, the Asset Register, and Standard Operating Procedures (SOPs), formally closing the ticket only after all verification steps are complete.

10. Manage Emergency Change Protocols

• Action: Formalise an expedited, secure pathway for deploying critical security patches or resolving rapid zero-day vulnerabilities.
• Result: Balances the operational need for immediate remediation with the compliance requirement of maintaining a secure and documented ISMS.
• Technical Requirements: Define specific criteria for emergency break-glass procedures, ensuring retrospective documentation and CAB review occur within a defined SLA post-deployment.

ISO 27001 Clause 6.3 FAQ

What is ISO 27001 Clause 6.3 Planning of Changes?

ISO 27001 Clause 6.3 is a preventative control that mandates all changes to the Information Security Management System (ISMS) be carried out in a planned and systematic manner. The bottom line is that organisations must assess the potential impact of any modification—whether to people, processes, or technology—before execution. This clause specifically aims to prevent the 80% of service interruptions and security incidents that industry data suggests are caused by unplanned or poorly executed changes.

How do I demonstrate compliance with Clause 6.3 during an audit?

To satisfy an auditor, you must provide a verifiable audit trail linking the change request to a formal risk assessment and final authorisation. Specifically, you need to produce evidence such as Change Advisory Board (CAB) minutes, completed Change Request Forms (CRFs), and updated asset registers. Auditors will look for a ‘Golden Thread’ where a change to a critical asset (like a firewall configuration) can be traced back to a specific, approved ticket in your change management system.

Does every minor change require a full risk assessment?

No, not every minor adjustment requires a comprehensive risk assessment; applying a ‘one-size-fits-all’ approach is a common efficiency killer. Instead, you should categorise changes into ‘Standard’ (pre-approved, low risk), ‘Normal’ (requires assessment and CAB approval), and ‘Emergency’ (expedited approval). Only ‘Normal’ and ‘Emergency’ changes typically require a specific documented risk assessment to evaluate the impact on confidentiality, integrity, and availability (CIA).

What is the difference between Clause 6.3 and Clause 8.1?

While both clauses deal with planning, Clause 6.3 focuses specifically on changes to the ISMS itself (the management system and framework), whereas Clause 8.1 focuses on the operational planning and control of information security processes. In practice, they overlap significantly; however, Clause 6.3 is the governing requirement ensuring that the integrity of the certification is not compromised during transitions, such as migrating to a new cloud provider or restructuring the security team.

What tools should I use to manage ISO 27001 change planning?

You do not need expensive GRC software; a well-configured ticketing system like Jira, ServiceNow, or even a structured SharePoint list is sufficient for most organisations. The critical requirement is that the tool must enforce mandatory fields for ‘Risk Impact’, ‘Back-out Plan’, and ‘Authorisation Date’. For smaller setups, the ISO 27001 Toolkit provides pre-built Change Management Logs and Policy templates that are fully compliant with the standard.

About the author