ISO 27001 Planning of Changes | Clause 6.3 | The Lead Auditor’s Implementation and Audit Guide

/ By
ISO 27001 Clause 6.3 Planning Of Changes Certification Guide

ISO 27001 Clause 6.3 is a security control that mandates all changes to the Information Security Management System (ISMS) be carried out in a planned manner. It requires a formal risk assessment and authorization prior to implementation to prevent security gaps. This control protects the organization and ensures the continuous integrity of your ISO 27001 certification.

In this guide, I will show you exactly how to implement ISO 27001 Clause 6.3 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.

I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.

Table of contents

Stop Guessing. Start Passing.

AI-generated policies are generic and fail audits. Our Lead-Auditor templates have a 100% success rate. Don’t risk your certification on a prompt

Get the Auditor-Proven Toolkit.
Fay Barker - High Table - ISO27001 Director

ISO 27001 Planning of Changes

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.

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.

ISO 27001 Clause 6.3 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

ISO 27001 Clause 6.3 Implementation Guidance

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.

ISO27001 Clause 6.3 Planning of Changes

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 Implementation Checklist

Planning Of Changes ISO 27001 Clause 6.3 Implementation Checklist:

ISO 27001 Clause 6.3 Implementation Checklist
Implementation Step Requirement Description Common Challenge Recommended Solution
1. Establish a Change Management Process Define a formal process for managing changes to the ISMS, including procedures for planning, approving, implementing, and reviewing changes. Lack of a documented and consistently followed process; resistance to adopting formal procedures. Develop a clear and concise change management policy. Provide training to all relevant personnel and emphasise benefits like reduced risk.
2. Assess the Impact of Changes Conduct a thorough assessment of potential impacts on the ISMS, including risks and opportunities, before implementation. Overlooking potential impacts; difficulty in predicting the consequences of complex changes. Involve relevant interested parties in the impact assessment. Use risk assessment methodologies to identify potential risks (positive and negative).
3. Plan Changes in a Controlled Manner Plan changes carefully, considering resources, timelines, testing, and communication requirements. Inadequate planning leading to delays or disruptions; difficulty in coordinating complex changes. Develop detailed implementation plans for each change. Assign clear responsibilities and conduct thorough testing before production.
4. Authorise Changes Obtain appropriate authorisation from designated authorities before implementing any change. Lack of clear approval authority; implementing changes without proper authorisation. Define clear approval levels for different change types. Establish a formal approval process and use a system to track sign-offs.
5. Implement Changes as Planned Execute changes strictly according to the documented and approved plan. Deviations from the plan leading to unexpected issues; difficulty managing changes during implementation. Closely monitor the implementation process using project management tools. Maintain rollback plans for unforeseen issues.
6. Test Changes Thoroughly test changes in a staging environment before they are deployed to production. Inadequate testing leading to operational problems or security gaps. Develop comprehensive test plans and utilise different testing methods (e.g., UAT, security regression).
7. Communicate Changes Inform relevant interested parties about changes in a timely and effective manner. Lack of communication leading to confusion and disruption; difficulty reaching all affected parties. Develop a communication plan for each change using multiple channels (email, intranet) to provide clear information.
8. Review Changes Review the effectiveness of the change post-implementation and identify lessons learned. Forgetting to review changes; failure to capture and apply lessons learned. Schedule post-implementation reviews for all significant changes. Document findings to improve future planning.
9. Document Changes Maintain accurate, up-to-date records of all changes made to the ISMS. Difficulty in keeping change records current; lack of integration with other ISMS documentation. Use a centralised change management system. Integrate change records with risk registers and asset inventories.
10. Manage Emergency Changes Maintain a specific process for managing urgent changes that require rapid implementation. Difficulty in balancing the need for speed with necessary security controls during emergencies. Define clear criteria for emergency changes. Establish an expedited approval process that still ensures documentation and review.

ISO 27001 Clause 6.3 Audit Checklist

Planning Of Changes ISO 27001 Clause 6.3 Audit Checklist:

ISO 27001 Clause 6.3 Audit Checklist
Audit Objective Verification Criteria Required Evidence & Audit Methods
1. Review the Change Management Process Verify the existence and adequacy of a documented change management process aligned with best practices.
  • Review of policies and procedures.
  • Interviews with IT and security personnel.
  • Walkthrough of the process flow.
  • Comparison against frameworks like ITIL.
2. Assess Impact Assessment Procedures Ensure procedures exist for assessing the impact of changes on the ISMS, covering both risks and opportunities.
  • Review of impact assessment templates.
  • Examination of past change requests.
  • Testing with a hypothetical change scenario.
3. Evaluate Change Planning Verify that changes are planned in a controlled manner, considering resources, timelines, and testing.
  • Review of implementation plans and resource allocation.
  • Analysis of change schedules and timelines.
  • Review of pre-implementation test plans.
4. Examine Change Authorisation Ensure that changes are formally authorised by appropriate personnel before implementation begins.
  • Review of approval workflows and authorisation records.
  • Verification of approval levels for different change types.
  • Interviews with designated approvers.
5. Assess Change Implementation Verify that changes are implemented strictly according to the approved plan.
  • Observation of implementation activities.
  • Comparison of system logs/configurations (before vs. after).
  • Review of implementation records and tickets.
6. Evaluate Change Testing Ensure thorough testing is conducted and documented before deployment to production.
  • Review of test cases, results, and reports.
  • Interviews with testers regarding pass/fail criteria.
  • Independent testing of implemented changes.
7. Assess Change Communication Verify that changes are communicated to relevant interested parties effectively and on time.
  • Review of communication plans and records.
  • Analysis of feedback or effectiveness surveys.
  • Examination of channels used (e.g., email, intranet).
8. Examine Change Review Ensure post-implementation reviews (PIR) are conducted to assess effectiveness and capture lessons learned.
  • Review of PIR reports and success metrics.
  • Examination of ‘lessons learned’ logs.
  • Analysis of incident rates related to changes.
9. Evaluate Change Documentation Verify that accurate, tamper-evident records of all changes to the ISMS are maintained.
  • Review of Change Management System (CMS) records.
  • Examination of audit trails and change logs.
  • Verification of data integrity and completeness.
10. Assess Emergency Change Management Verify the effectiveness of the process for managing urgent changes without compromising security.
  • Review of emergency change procedures.
  • Examination of past emergency requests.
  • Testing the process with a simulated emergency scenario.

What an auditor looks for ISO 27001 Clause 6.3

Audit Focus Area What The Auditor Verifies Required Evidence & Examples
1. Defined Process Does a formal procedure exist for managing changes, distinguishing between Standard, Normal, and Emergency changes? Is it actually being followed, or is it just shelf-ware?
  • Document: Approved Change Management Policy.
  • Example: A flowchart showing the steps for a ‘Normal’ change vs. an ‘Emergency’ hotfix.
2. Risk Assessment Was the impact on information security (Confidentiality, Integrity, Availability) assessed before the change was authorised? Did you consider dependencies?
  • Record: A field in the change ticket (e.g., Jira/ServiceNow) labeled “Security Impact Analysis”.
  • Example: A risk assessment for migrating to a new cloud server, highlighting potential downtime or data exposure risks.
3. Formal Authorisation Who approved this? Did the approver have the correct level of authority? Was the approval given before implementation started?
  • Audit Trail: timestamped approval logs.
  • Example: Meeting minutes from the Change Advisory Board (CAB) approving a major firewall rule update, or a CTO’s digital signature on a purchase order for new software.
4. Testing & Verification Was the change tested in a non-production environment? Is there evidence that the change achieved its intended purpose without breaking security controls?
  • Evidence: UAT (User Acceptance Testing) sign-off emails or automated test reports.
  • Example: Screenshots of successful login tests in a staging environment following an authentication policy update.
5. Rollback Planning If the change failed, was there a plan to revert to a secure state? Was this plan feasible?
  • Field: The “Back-out Plan” section in the Change Request.
  • Example: “If the patch causes latency >500ms, restore Virtual Machine Snapshot taken at 09:00 AM.”
6. Emergency Changes How were urgent changes handled? Were they retrospectively documented and authorised, or used as an excuse to bypass the process?
  • Log: Emergency Change Log.
  • Example: An incident report for a zero-day patch applied at 2 AM, followed by a retrospective Change Request filed the next morning for approval.

ISO 27001 Clause 6.3 Top Non Conformities

Top 3 Audit Non-Conformities for Clause 6.3

As a Lead Auditor, I frequently fail organisations on Clause 6.3 not because they didn’t want to follow the process, but because their tools got in the way. Complex SaaS GRC platforms often force rigid workflows that staff find frustrating, leading them to bypass the system entirely.

Here are the most common non-conformities I raise, and how “rented” software often contributes to them:

Non-Conformity Type The Auditor’s Finding The SaaS vs. Toolkit Reality
1. “Shadow” Changes (Bypassing the Tool) “Critical infrastructure changes were made without a record because the staff member found the GRC ticketing process ‘too complex’ for a 5-minute fix.” SaaS Failure: Over-engineered SaaS forms with 20+ mandatory fields encourage staff to work “off the books.”
Solution: Use a simple, low-friction Excel register or Policy template that staff actually use.
2. Broken Audit Trails (The Subscription Gap) “The organisation could not produce evidence for changes made in Q1/Q2 because they switched GRC vendors and lost access to the historical data.” SaaS Failure: You rent your compliance. If you switch vendors or stop paying, you lose your audit trail and fail the audit.
Solution: Own your data. Files stored on your own SharePoint/Drive are yours forever.
3. The “Emergency” Flag Abuse “Standard changes were falsely labelled as ‘Emergency’ just to bypass the rigid CAB approval workflow enforced by the software.” SaaS Failure: SaaS platforms often lack the flexibility to handle “Standard” changes easily, forcing users to “game the system” to get work done.
Solution: Use a flexible process (Word/Excel) that relies on human judgement, not hard-coded software logic.

Measuring Change and KPIs

Key Performance Indicators (KPIs) for ISO 27001 Clause 6.3

To satisfy ISO 27001 Clause 9.1 (Monitoring, measurement, analysis and evaluation), you must evidence that your change management process is effective. You cannot improve what you do not measure. An auditor will expect to see that you are tracking specific metrics to identify trends, such as an increasing reliance on emergency changes or a high failure rate.

We recommend tracking the following three KPIs to demonstrate control and drive continual improvement:

KPI Name Formula / Definition What Good Looks Like
Change Failure Rate (CFR) (Count of changes resulting in incident / Total count of changes) × 100 Target: < 5%
A high CFR indicates poor testing environments or inadequate risk assessment (Clause 6.1).
Emergency Change Ratio (Count of Emergency Changes / Total count of changes) × 100 Target: < 10%
A high ratio suggests a “fire-fighting” culture and poor planning (Clause 6.3 failure). Emergency changes should be the exception, not the rule.
Average Lead Time Average time elapsed between Change Request Creation and Implementation. Target: 3–5 Days (Normal Changes)
Lead times that are too short often skip testing; lead times that are too long encourage staff to bypass the process.

ISO 27001 Change Management RACI Matrix

3. Clear RACI Matrix (Roles & Responsibilities)

In smaller organisations, confusion over who actually authorises a change is a top cause of non-conformity during an audit. You must clearly define who is Responsible, Accountable, Consulted, and Informed.

Use this simplified RACI matrix to satisfy the “competent authority” requirement of Clause 6.3 without creating unnecessary bureaucracy:

ISO 27001 Change Management RACI Matrix
Role Standard Change
(Low Risk / Pre-Approved)		 Normal Change
(Significant / CAB Required)		 Emergency Change
(Critical / Expedited)
Requester
(Dev / IT Staff)		 R (Responsible) R (Responsible) R (Responsible)
Change Manager
(Process Owner)		 A (Accountable) R (Organises CAB) C (Consulted)
Change Advisory Board (CAB)
(Tech Leads)		 I (Informed) A (Authorises) I (Post-Implementation Review)
CISO / Security Lead
(Risk Owner)		 I (Informed) C (Risk Assessment) A (Authorises)
Key: (R)esponsible: Does the work. (A)ccountable: Signs it off. (C)onsulted: Provides input. (I)nformed: Notified of outcome.

ISO 27001 Templates

Implementing ISO 27001 can be a significant undertaking and incur significant ISO 27001 Costs. To streamline the process and potentially save valuable time and resources, consider utilising pre-written ISO 27001 templates. This ISO 27001 Toolkit offers a comprehensive set of resources specifically designed for those seeking to achieve ISO 27001 certification independently. With this toolkit, you can potentially build your Information Security Management System (ISMS) within a week and be ready for certification within 30 days.

Applicability of ISO 27001 Clause 6.3 across different business models.

Business Type Applicability Level Why It Is Important (Clause 6.3 Context) Examples of Application
Small Businesses High (Proportionate) Prevents operational chaos where undocumented changes (often made by a single key person) create security gaps. It ensures that shifting IT providers or tools does not void the ISMS certification.
  • Switching Managed Service Providers (MSPs).
  • Updating the remote working policy.
  • Migrating from on-premise servers to SharePoint/Teams.
Tech Startups Critical Balances the “move fast” culture with necessary governance. It proves to enterprise clients and investors that rapid scaling and infrastructure updates are not compromising security stability.
  • Modifying CI/CD deployment pipelines.
  • Changing cloud infrastructure regions (e.g., AWS vs Azure).
  • restructuring admin access during a hiring sprint.
AI Companies Vital Ensures that modifications to algorithms, datasets, or processing environments do not introduce vulnerabilities, bias, or data integrity issues, which is essential for upcoming AI regulations.
  • Changing data ingestion sources or APIs.
  • Updating model weights or inference parameters.
  • Altering access controls for sensitive training datasets.

Fast track ISO 27001 Clause 6.3 compliance with the ISO 27001 Toolkit

Comparison Factor ISO 27001 Toolkit (HighTable) Typical SaaS GRC Platform Why It Matters for Clause 6.3
Asset Ownership Permanent Ownership You download and keep your Change Management policies and logs forever. They are yours. Rental Model You lose access to your historical change records and policies the moment you stop paying the monthly fee. Clause 6.3 requires evidence of planned changes over time. Losing access to past records due to a lapsed subscription creates a major audit non-conformity.
Ease of Use Universal Familiarity Built on Microsoft Word and Excel. No training required; your team already knows how to use them. High Learning Curve Requires staff training on proprietary interfaces and complex workflows to log simple changes. Change management fails when processes are too complex. Using familiar tools ensures staff actually log changes instead of bypassing the system.
Cost Structure One-Off Fee Pay once, use forever. No recurring costs per user or per month. Recurring Subscriptions Expensive monthly or annual fees that often scale up with the number of users or assets. For a single control like “Planning of Changes,” paying a monthly subscription is overkill. A one-time purchase delivers higher ROI.
Vendor Freedom No Lock-In You are free to move your documents to SharePoint, Google Drive, or any internal system you choose. Vendor Lock-In Migrating data out of a SaaS platform is often difficult, expensive, or technically restricted. Your ISMS should adapt to your business infrastructure, not force you to build your processes around a vendor’s rigid software limitations.
Customisation Full Control Edit every single word, column, and field to fit your specific change workflow perfectly. Rigid Frameworks You are often forced to use their pre-defined fields and workflows, which may not fit your reality. Clause 6.3 implementation must be proportionate. Toolkits allow you to simplify the documentation to match your exact size and risk profile.

Clause 6.3 (Planning of Changes) is a governance requirement that mandates that any change to the Information Security Management System (ISMS) itself or significant changes to the organization must be planned, resourced, and assessed for risk before execution.

Below are the primary clauses and Annex A controls that directly relate to, support, or are triggered by Clause 6.3.

These clauses within the main body of the standard govern how Clause 6.3 is operationally executed.

These are the specific security controls (safeguards) you implement to ensure a change doesn’t break your security posture. Note: Clause 6.3 is about changing the Management System (Strategic). Control 8.32 is about changing Technology/Systems (Operational). In practice, they often happen together.

To fully satisfy an auditor for Clause 6.3, they will look for a chain of evidence that touches multiple areas:

  1. The Plan (6.3): “We need to move to a new server.”
  2. The Risk (6.1): “What if the data is lost during the move?” (Risk Assessment).
  3. The Control (8.1 & A.8.32): “We will use a staging environment and get CAB approval.”
  4. The Doc Update (7.5 & A.5.37): “We updated the network diagram and the backup procedure.”

ISO 27001 Clause 6.3 Mapped to other Standards

Here are the key standards and frameworks that relate to, overlap with, or support ISO 27001 Clause 6.3.

Mapping ISO 27001 Clause 6.3 to Related Standards (Including AI, NIS2 & DORA)
Standard / Framework Specific Reference Relationship to ISO 27001 Clause 6.3
ISO/IEC 42001 (AI Management) Clause 6.3 & Control A.9.3 The “Twin” standard for AI. It applies Clause 6.3 specifically to AI models. It ensures that changes to training data, model architecture, or hyperparameters are risk-assessed to prevent bias drift or performance degradation.
EU AI Act Article 17 (Quality Management System) Mandates a QMS for providers of high-risk AI systems. It explicitly requires procedures for “management of modifications” to the AI system. ISO 27001 Clause 6.3 provides the underlying governance structure to satisfy this legal requirement.
EU NIS2 Directive Article 21 (Risk Management Measures) Mandates “security in network and information systems acquisition, development and maintenance.” Clause 6.3 provides the required governance framework to demonstrate these activities are planned and risk-assessed.
EU DORA (Digital Operational Resilience Act) Article 11 (ICT Project and Change Management) Explicitly requires financial entities to uphold ICT change management policies. Clause 6.3 is the direct compliance mechanism to ensure changes are recorded, tested, and approved as per DORA requirements.
ISO 9001:2015 (Quality) Clause 6.3 Shares the exact clause structure. Allows for a unified process that assesses both security (27001) and quality (9001) risks simultaneously.
ISO 22301:2019 (BCMS) Clause 6.3 Focuses on resilience. Requires validation that planned changes will not inadvertently disrupt business continuity or invalidate Disaster Recovery plans.
ISO 20000-1:2018 (ITSM) Clause 8.5.2 Provides the detailed operational workflow (CAB, Request for Change). Certification to ISO 20000 automatically satisfies the governance requirements of 27001 Clause 6.3.
SOC 2 Criteria CC8.1 Explicitly requires evidence of authorisation, testing, and approval. You cannot pass a SOC 2 Type II audit without the audit trails generated by Clause 6.3.
NIST SP 800-53 Control CM-3 (Configuration Change Control) A more prescriptive federal standard that mandates testing, validation, and documentation of changes before implementation, aligning directly with Clause 6.3.
PCI DSS v4.0 Requirement 6.5 Mandates strict change control for the Cardholder Data Environment (CDE), specifically requiring separation of duties between developers and releasers.
ITIL 4 Practice: Change Enablement Defines the “How-To” implementation. Most auditors expect to see ITIL-aligned workflows (Standard, Normal, Emergency) as evidence of controlled planning.
GDPR Articles 25 & 32 Links change planning to privacy. Significant changes to data processing activities identified in Clause 6.3 may trigger a mandatory Data Protection Impact Assessment (DPIA).

ISO 27001 Clause 6.3: Myths vs. Auditor Reality

There is a lot of bad advice online, often written by vendors trying to sell complex software. As a Lead Auditor, let me clear up the most common myths about Planning of Changes so you don’t waste time on unnecessary bureaucracy.

The Myth The Auditor’s Reality
Myth: “You need a dedicated Change Manager.” Reality: False. In a small startup, the CTO or Engineering Lead can fulfill this role. You just need to define the responsibility, not hire a new person.
Myth: “Every change needs a CAB meeting.” Reality: False. “Standard Changes” (low risk, repetitive) should be pre-approved. Dragging every minor update to a committee is a failure of process, not a success.
Myth: “You need a digital ticketing system.” Reality: False. While Jira is common, a simple spreadsheet or a Word document “Change Log” is perfectly acceptable for ISO 27001, provided it is kept up to date.
Myth: “Clause 6.3 is just for IT software.” Reality: False. This is the biggest trap. Clause 6.3 applies to the ISMS. If you move office, restructure your team, or change your background check provider, you must plan and risk-assess that change too.

List of Required Documents for Clause 6.3

To pass your audit, ensure you have the following documents ready and available. If you use the ISO 27001 Toolkit, these templates are already populated for you.

  • Change Management Policy: defining your change types (Standard, Normal, Emergency) and approval hierarchy.
  • Change Log / Register: The central record of all changes, past and present.
  • Change Request Form (CRF): A template (digital or document) capturing the risk assessment, test plan, and back-out plan.
  • CAB Meeting Minutes: Evidence of discussion and approval for high-risk changes.
  • Training Records: Evidence that staff know how to raise a change request.

Pro Tip: Using Project Management as Clause 6.3 Evidence

A common mistake is treating “Change Management” and “Project Management” as two separate worlds. They are not. If you are running a large project (e.g., implementing Salesforce or moving to a new office), you do not need to create a separate “Change Ticket” to satisfy Clause 6.3.

Your Project Plan is your evidence, provided it contains these three specific elements:

Required Element Where to find it in your Project Plan
1. Planning Your Gantt chart, Trello board, or Project Timeline serves as evidence that the change was “carried out in a planned manner.”
2. Risk Assessment Your RAID Log (Risks, Assumptions, Issues, Dependencies) serves as the Clause 6.1 / 6.3 risk assessment.
3. Authorisation The Project Charter or the “Go-Live” email approval from the Project Sponsor serves as your formal authorisation.
Auditor Tip: Don’t duplicate work. If you have a Project Plan, simply cross-reference it in your Change Log instead of creating a new record.

What should be in your Change Management Policy?

If you are writing your Change Management Policy from scratch to satisfy Clause 6.3, ensure it contains the following mandatory sections. Missing any of these creates a gap that an auditor can exploit.

(Note: The ISO 27001 Toolkit includes this pre-written policy fully populated.)

  • 1. Purpose & Scope: Explicitly stating this applies to the ISMS, not just “IT Servers.”
  • 2. Roles & Responsibilities: Defining the CAB, Change Manager, and Requester (as per the RACI matrix).
  • 3. Change Categorisation: Definitions for Standard, Normal, and Emergency changes.
  • 4. The Request Process: How to log a ticket and what fields are mandatory (Risk Assessment).
  • 5. The Approval Process: Who signs off what (and evidence of segregation of duties).
  • 6. Testing & Rollback: The requirement for staging tests and back-out plans.
  • 7. Emergency Procedures: The specific “Break Glass” protocol.
  • 8. Auditing & Review: How often the logs are reviewed (Clause 9.1).

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

Stuart Barker
🎓 MSc Security 🛡️ Lead Auditor ⚡ 30+ Years Exp 🏢 Ex-GE Leader

Stuart Barker

ISO 27001 Ninja

Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management. Holding an MSc in Software and Systems Security, he combines academic rigor with extensive operational experience, including a decade leading Data Governance for General Electric (GE).

As a qualified ISO 27001 Lead Auditor, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. His toolkits represent an auditor-verified methodology designed to minimise operational friction while guaranteeing compliance.

Shopping Basket
Scroll to Top