ISO 27001 clause 6.3: Planning ISMS changes
ISO 27001 clause 6.3 requires changes to the ISMS to be carried out in a planned manner when the organisation determines they are needed. The clause is short, but its practical role is significant: the management system should not become inconsistent when the business, its scope or its way of making decisions changes.
What clause 6.3 requires in practice
Clause 6.3 is one of the shortest in the standard. When the organisation decides that the ISMS needs to change, those changes must be carried out in a planned manner. The clause does not define what a change is, specify a procedure or name any record.
In practice, the changes in question are those to the management system itself: widening or narrowing the scope, altering the risk method, reassigning key responsibilities, restructuring processes or merging with another organisation. They are different from day-to-day technical changes to systems, which are handled through operational control and the relevant Annex A control.
Planned means that someone has thought about purpose, consequences, resources, responsibilities and effects on the integrity of the system before acting. The output is a system that stays coherent while the business moves, with documents, roles and processes still aligned afterwards.
Recognise an ISMS change
Examples include expanding the scope to a new service, changing the risk-assessment method, moving key responsibilities to a shared function or integrating an acquired organisation. A new technology can trigger ISMS changes where it affects risks, responsibilities, documented information or performance evaluation. Not every minor technical adjustment needs a separate management-system project.
Clause 6.3 concerns planned change to the ISMS. Clause 8.1 addresses operational control, including planned and unintended changes. Annex A control 8.32 concerns change management for information processing facilities and systems where selected. One coordinated process can address related needs if the different decisions remain clear.
A practical planning approach
Start with the purpose of the change and the intended result. Identify which processes, people, suppliers, locations and information are affected. Consider dependencies and what could become ineffective during the transition. Decide the necessary actions, ownership, resources and checks before the new arrangement is treated as established.
This is implementation advice, not a prescribed clause 6.3 checklist. The standard does not specify a universal form, approval hierarchy or mandatory change board. Use a level of planning proportionate to the consequences. A major scope expansion deserves more coordination than updating a low-impact reporting arrangement.
Significant proposed or actual changes can also trigger risk reassessment. Do not wait until after a migration to discover that the new operating model invalidates access assumptions or supplier responsibilities. Plan communication and competence needs so the revised system is understood when it starts operating.
Why planned ISMS change matters to the business
Businesses change constantly, and the management system can quietly fall behind. A new service added without revisiting scope, an acquisition with a different risk method or a reorganisation that leaves roles unassigned can each open gaps that were not there before. Planning those changes prevents surprise findings at the next assessment and protects the reliability of what customers were told. It also saves rework: adjusting scope, risks and documents together costs less than repairing them separately after problems appear. For leaders, it provides assurance that growth and restructuring do not erode the protection of information that clients depend on.
How to implement clause 6.3
Keep the approach light so people actually use it. One method Sterling teams use is a short checklist applied whenever the business proposes a significant change. The test of success is that nothing in the system is left contradicting the change afterwards.
- Define which kinds of change count as ISMS changes, such as new services, scope shifts, role changes or method revisions.
- Ask project and business owners to flag proposals early, before decisions are final.
- Consider the effects on scope, risks, controls, responsibilities, documented information and objectives.
- Assign responsibility for each adjustment and agree timing so the system is never left inconsistent.
- Record the decision briefly, including who approved it.
- After the change, confirm that documents, roles and records match reality and report the outcome to management review.
- Include a short check in project and change processes asking whether the ISMS is affected, so that management-system changes are noticed by people who would otherwise treat them as purely operational matters.
Illustrative examples
The company ends an outsourced support arrangement. Its change plan addresses ownership of customer records, staff competence, access rights, incident escalation and performance measures. It verifies that contractual information-return obligations are met and that the revised internal process can operate before considering the change complete.
Management wants comparable reporting across two sites. It tests the proposed criteria against representative risks from both locations, resolves inconsistent interpretations and plans how existing records will be migrated. It retains enough traceability to explain why a changed score reflects a changed method rather than necessarily a changed exposure.
Evidence and completion checks
A business change record, project plan or management decision can show planned execution. Clause 6.3 does not separately demand a document called an ISMS change plan. Nevertheless, evidence should be sufficient to explain the planning and fulfil any related documentation requirements.
Check whether responsibilities, scope information, risk decisions and relevant instructions agree after implementation. Sample actual work under the new arrangement. A project can close administratively while the ISMS still refers to a former service or a departed owner. An effectiveness check helps identify that gap.
Common mistakes
Avoid updating only the scope statement while leaving assessment, treatment, competence and audit coverage unchanged. Another weakness is treating an organisational change as a technical ticket, with no business owner. Conversely, imposing the same heavy process on every editorial correction can encourage staff to bypass it.
A phased change needs clear interim responsibilities. If teams temporarily use different risk methods or reporting routes, define which decisions govern each phase and how the transition will be checked. Otherwise, a planned rollout can leave incompatible arrangements operating together without an accountable owner.
Frequently asked questions
Does clause 6.3 require a separate ISMS change form?
No particular form is prescribed. An existing project or change record can support planning if it addresses the affected ISMS decisions, responsibilities and checks, together with any related documentation requirements.
Do all changes require a formal change board?
No particular board is prescribed. Plan changes in a proportionate way with appropriate ownership, decisions and checks for their consequences.
How is this different from IT change management?
ISMS changes can affect scope, governance, risk methods and responsibilities as well as technology. Coordinate the processes, but do not assume technical approval alone covers those management-system effects.
Keep the ISMS effective while the business changes
Talk to Sterling to review a planned acquisition, new service or organisational change before responsibilities and evidence become disconnected. Build the relevant knowledge through Risk Management at Sterling Academy. We can also assess whether Effivity ISO & GRC automation software suits the agreed workflow and programme. Certification decisions remain with an independent certification body.