Why ISO 27001 Now Has a Clause 6.3
If you have been working with ISO 27001 for a while, you will remember that the 2013 edition had no dedicated clause for planning changes to the information security management system. Changes happened, but the standard gave you little explicit direction on how to manage them. The 2022 revision fixed that. Clause 6.3 is a new addition, and it introduces a structured requirement that organisations must address before making changes to the ISMS.
On this page
This matters for anyone running or auditing an ISMS in Australia. Whether you are a quality or information security manager, an internal auditor, or a consultant helping clients prepare for certification, understanding what Clause 6.3 actually requires will save you from a common class of nonconformities that certification auditors are now routinely raising.
This article explains what the clause says, why it was added, how it connects to the rest of the standard, and what good practice looks like in real organisations.
What Clause 6.3 Actually Says
The clause is short. ISO 27001:2022 Clause 6.3 states that when the organisation determines the need to make changes to the ISMS, those changes shall be carried out in a planned manner. That is essentially it. No prescriptive methodology, no required documentation format, no mandated approval workflow. The standard is deliberately high level.
But short does not mean simple. The clause sits within Section 6, which covers planning. This context is important. Section 6 is where the organisation addresses risks and opportunities (Clause 6.1), sets information security objectives (Clause 6.2), and now, under Clause 6.3, manages changes to the system itself. The placement signals that change management is a planning activity, not an afterthought.
The phrase carried out in a planned manner is doing a lot of work here. It means that changes to the ISMS should not be reactive, ad hoc, or invisible. They should be considered, assessed, and implemented with some degree of deliberate intent. The organisation needs to think before it acts.
Exemplar Global Recognised Training ProviderRTP No. 310970
What Counts as a Change to the ISMS?
This is the first question most practitioners ask, and it is a reasonable one. The clause does not define what constitutes a change, which gives organisations some flexibility but also creates uncertainty.
In practice, changes to the ISMS can include:
- Expanding or contracting the scope of the ISMS, such as adding a new business unit or cloud service
- Introducing new technology that affects information assets, such as migrating to a new platform or adopting a SaaS application
- Restructuring roles and responsibilities related to information security
- Revising the information security policy or related procedures
- Adding, modifying, or removing controls from Annex A
- Responding to a significant change in the threat landscape, such as a new type of attack affecting your sector
- Mergers, acquisitions, outsourcing arrangements, or new third party relationships
- Changes driven by legal or regulatory updates, such as new obligations under the Privacy Act or sector specific requirements
Not every minor update to a document constitutes a change under Clause 6.3. If you correct a typo in a procedure or update a contact name, that is document maintenance, not an ISMS change. The clause is aimed at changes that have a meaningful impact on how the ISMS functions, what it covers, or how risks are managed.
A useful test is to ask: could this change affect the organisation's ability to achieve its information security objectives, manage its risks, or meet its compliance obligations? If yes, it warrants the planning discipline that Clause 6.3 calls for.
How Clause 6.3 Connects to the Rest of ISO 27001
Clause 6.3 does not operate in isolation. It links directly to several other parts of the standard, and understanding those connections helps you implement it sensibly.
Connection to Clause 6.1: Risks and Opportunities
Any change to the ISMS has the potential to introduce new risks or affect existing ones. When you plan a change, you should revisit the risk assessment to understand what the change means for your risk profile. This is not optional. Clause 6.1.2 requires the organisation to perform information security risk assessments when significant changes are proposed. Clause 6.3 reinforces this by requiring that changes be planned, which implicitly includes considering their risk implications.
For example, if your organisation decides to migrate its document management system to a cloud platform, that is a change to the ISMS. Planning that change should include a risk assessment of the new environment, a review of which Annex A controls apply, and an update to the Statement of Applicability if the control set changes.
Connection to Clause 8.1: Operational Planning and Control
Clause 8.1 requires the organisation to plan, implement, and control the processes needed to meet information security requirements. It also states that the organisation shall control planned changes and review the consequences of unintended changes, taking action to mitigate adverse effects. This is the operational counterpart to the planning requirement in Clause 6.3. Together they create a loop: plan the change at the system level under Clause 6.3, then control its implementation at the operational level under Clause 8.1.
Connection to Clause 9.3: Management Review
Management review inputs under Clause 9.3 include changes in external and internal issues relevant to the ISMS. Significant changes to the ISMS should therefore be on the management review agenda, either as planned changes being considered or as implemented changes being evaluated for effectiveness. If your management review minutes never mention ISMS changes, that is a gap worth addressing.
Connection to Clause 10.2: Continual Improvement
Some ISMS changes arise from corrective actions or improvement initiatives. When a nonconformity or incident reveals a weakness in the system, the response may involve changing a process, a control, or a procedure. Clause 6.3 applies to those changes too. The planning requirement ensures that improvements are implemented thoughtfully, not just reactively patched.
What Does Planning a Change Actually Look Like?
Because the clause is not prescriptive, organisations have latitude to design a change management approach that suits their size and complexity. A large financial institution with a complex ISMS will need a more formal process than a small professional services firm with a straightforward system. Both can comply with Clause 6.3.
At a minimum, planning a change to the ISMS should involve the following considerations:
Purpose and Justification
Why is the change being made? Is it driven by a new business requirement, a risk finding, a regulatory change, or an improvement opportunity? Documenting the rationale helps decision makers evaluate whether the change is necessary and proportionate.
Impact on Information Security
What effect will the change have on the organisation's risk profile? Will new assets come into scope? Will existing controls need to be updated? Will new threats or vulnerabilities be introduced? This assessment does not need to be exhaustive, but it should be deliberate.
Resources and Responsibilities
Who will implement the change? What resources are needed? Who is accountable for ensuring the change is completed properly? Assigning clear ownership prevents changes from falling through the gaps.
Timeline and Sequencing
When will the change happen? Are there dependencies? For example, if you are adding a new business unit to the ISMS scope, you may need to conduct a risk assessment for that unit before you can update the Statement of Applicability and train staff in the new requirements. Getting the sequence right reduces the risk of gaps during the transition.
Review and Verification
How will you confirm that the change was implemented as planned and that it achieved the intended outcome? This might be a post implementation review, an internal audit of the changed area, or a management review agenda item.
Documented Information: What Do You Actually Need?
Clause 6.3 does not explicitly require documented information. The standard uses the phrase shall be carried out in a planned manner without mandating a specific record or form. However, this does not mean documentation is unnecessary.
In practice, a certification auditor will want to see evidence that changes to the ISMS are being planned. If there is no documented information at all, it becomes very difficult to demonstrate conformity. The evidence does not need to be elaborate. A change log, a change request form, meeting minutes that record a decision to change the ISMS scope, or an updated risk assessment that reflects a planned change can all serve as evidence.
The key is that the evidence should be proportionate to the significance of the change. A minor update to an internal procedure might be captured in a version history note. A major change such as adding a new business unit to scope warrants more thorough documentation, including the risk assessment, the updated Statement of Applicability, and the communication plan for affected staff.
For a practical look at what documented information the ISMS as a whole requires, the article on documented information in an ISMS under Clause 7.5 provides useful context on how to think about records across the system.
Common Nonconformities Under Clause 6.3
Based on what certification auditors are finding in practice, the most frequent issues relate to organisations that are making changes to their ISMS without any visible planning process. Here are the patterns that tend to attract findings:
Scope Changes Without Risk Assessment
An organisation expands its ISMS scope to include a new cloud service or a new department, but there is no evidence that a risk assessment was conducted for the new area before it was brought into scope. The change happened, but it was not planned in any meaningful sense.
Control Changes Without Updating the SoA
New controls are implemented or existing controls are removed, but the Statement of Applicability is not updated to reflect the change. The SoA and the actual control set become inconsistent. This is a direct consequence of implementing changes without planning them against the ISMS documentation.
Organisational Changes Not Reflected in the ISMS
The organisation restructures, a new team takes over a function with information security implications, or a key role is reassigned, but the ISMS roles and responsibilities documentation is not updated. The change happened at the organisational level but was not planned through the lens of the ISMS.
Technology Changes Without Security Review
A new system or application is deployed without a security assessment or a review of which controls apply. The IT team implements the change, but the information security function is not involved in planning it. This is a classic gap between IT change management and ISMS change management.
If you are preparing for a certification audit, reviewing your ISMS for these patterns is a worthwhile exercise. The article on auditing ISMS operations under Clause 8 covers how auditors approach the operational side of these same issues.
How Auditors Assess Clause 6.3
When an auditor examines Clause 6.3, they are looking for evidence that the organisation has a functioning approach to planning ISMS changes. They are not expecting a perfect, bureaucratic process. They are looking for intent and discipline.
Typical audit questions include:
- How does the organisation identify when a change to the ISMS is needed?
- What process is followed to plan and approve a change before it is implemented?
- Can you walk me through a recent change to the ISMS and explain how it was planned?
- How are risk implications considered when a change is proposed?
- How is the Statement of Applicability kept current when controls change?
- Who has authority to approve changes to the ISMS?
The auditor will then look for documented evidence that supports the answers. If the interviewee describes a process but there is no corresponding evidence, that is a gap. If there is evidence of changes being implemented but no evidence of planning, that is a nonconformity.
One of the most useful things an internal auditor can do before a certification audit is trace a recent ISMS change from start to finish. Pick a change that happened in the last twelve months, such as a new system being brought into scope or a policy being revised, and check whether the planning steps were followed. If they were not, that is an internal finding worth raising before the external auditor finds it.
Integrating Clause 6.3 Into Your ISMS
The practical challenge for many organisations is integrating ISMS change management with existing change management processes. Most organisations already have IT change management procedures, project management frameworks, or business change processes. The goal is not to create a separate ISMS change management bureaucracy on top of those. The goal is to ensure that the information security perspective is embedded in whatever change management process already exists.
This might mean adding an information security review step to the IT change approval process. It might mean including the information security manager in project governance for significant business changes. It might mean establishing a simple trigger list that prompts a review of the ISMS whenever certain types of changes are proposed.
The approach that works best is the one that fits the organisation's culture and operating model. What matters is that changes to the ISMS do not happen invisibly, and that someone with information security responsibility has the opportunity to assess the implications before the change goes ahead.
For those who want to understand how change planning requirements compare across different management systems, the article on planning of changes under ISO 9001 Clause 6.3 provides a useful parallel, given that the requirement originated in the quality management context and has since been adopted across standards using the harmonised structure.
Clause 6.3 and the Harmonised Structure
It is worth noting that Clause 6.3 in ISO 27001:2022 aligns with the harmonised structure that underpins most modern ISO management system standards. ISO 9001 has had a Clause 6.3 on planning of changes since its 2015 revision. ISO 14001:2026 has introduced a similar requirement. The harmonised structure ensures that organisations running integrated management systems can apply consistent change management thinking across their quality, environmental, safety, and information security systems.
If your organisation already has a mature change management process for ISO 9001 or ISO 14001, adapting it to meet the ISO 27001 Clause 6.3 requirement should be straightforward. The information security context adds specific considerations around risk assessment and control selection, but the underlying discipline of planning before acting is the same.
Exemplar Global Recognised Training ProviderRTP No. 310970Preparing Your Team for Clause 6.3 Audits
If you are the information security manager or quality manager responsible for the ISMS, there are a few practical steps worth taking now to ensure your organisation is ready for scrutiny of Clause 6.3.
First, review how changes to the ISMS have been managed over the past twelve months. Look for examples of scope changes, control changes, policy revisions, and technology changes. For each one, ask whether there is evidence of planning. If not, consider whether retrospective documentation is appropriate, and more importantly, whether the process needs to be improved going forward.
Second, make sure your team understands what constitutes a change to the ISMS. Many nonconformities under Clause 6.3 arise simply because people do not recognise that what they are doing constitutes an ISMS change. A brief awareness session or a simple decision guide can help.
Third, check that your risk assessment process is triggered by proposed changes. If risk assessments only happen on a fixed annual cycle, you may be missing the requirement in Clause 6.1.2 to reassess when significant changes are proposed. Linking the change planning process to the risk assessment process closes this gap.
If you are building your auditing skills in the ISO 27001 space, Audit Workshop offers training that covers the full clause structure of the standard, including how to audit planning requirements like Clause 6.3 in practice. The guide to becoming an ISO 27001 information security auditor outlines the training pathway and what to expect from lead auditor level courses.
Summary
Clause 6.3 of ISO 27001:2022 is a new but straightforward requirement. It asks organisations to plan changes to the ISMS before implementing them. It does not prescribe a specific methodology, but it does require that changes be deliberate, considered, and traceable.
For practitioners, the key actions are: identify what counts as a change to your ISMS, build a planning step into how those changes are managed, link change planning to your risk assessment process, and keep enough documented information to demonstrate that planning occurred. Done well, this requirement strengthens the ISMS by ensuring that growth, restructuring, and technology adoption do not quietly erode the security posture the system is designed to maintain.
If you are pursuing ISO 27001 auditor credentials or looking to sharpen your understanding of the 2022 revision, Audit Workshop delivers practical, trainer led courses at Foundation, Internal Auditor, and Lead Auditor levels. The training is built around real audit scenarios, not just clause recitation, so you leave with skills you can apply immediately.
