Clause 6 of ISO 27001 is about planning. In the first part of this series, we looked at clause 6.1 and the requirement to address risks and opportunities. In the second part, we looked at clause 6.2 and the requirement to establish information security objectives and plan how to achieve them. Now we come to clause 6.3, planning of changes.
This is the shortest part of Clause 6, but it should not be ignored. The wording is brief, but the practical meaning is important. ISO 27001 says that when the organisation determines the need for changes to the Information Security Management System, those changes shall be carried out in a planned manner.
While that is the whole requirement, it raises an important question. What does it mean to change an ISMS in a planned manner?
At its simplest, clause 6.3 is telling the organisation not to let the ISMS drift. Changes should not simply happen because someone updated a document, changed a process, replaced a tool, moved a responsibility, or reacted to a problem without considering the wider effect. An ISMS is a connected management system. A change in one area can affect risks, responsibilities, controls, objectives, documented information, monitoring, audits, and management review.
Why planning of changes matters -
An ISMS is not meant to be static, because organisations are not static. Both will change over the course of time. Processes, systems, suppliers, lines of business all change. Legal and contractual obligations change. The threat environment as well as business priorities change. If the ISMS doesn’t change with them, then it will quickly become disconnected from reality.
This is one of the reasons why clause 6.3 matters. It reminds organisations that changes to the ISMS should be deliberate and thought out, not accidental. A change should be well understood before it is implemented. The organisation should consider what is changing, why it is changing, who is responsible, what are the new risks, what documentation will need to be updated, and how the organisation will know whether the change has been carried out properly or not.
This does not mean every small change needs a complex project plan. ISO 27001 is not asking for unnecessary bureaucracy. The level of planning should fit the significance of the change. A minor update to a template may only need a simple review and version update. A major change to the scope of the ISMS, the risk assessment method, supplier structure, access control model, incident management process, or Statement of Applicability will need more careful planning. The important point is proportionality. The organisation should be able to show that significant ISMS changes were not handled casually, or in an ad-hoc manner.
So then what kind of changes are we talking about?
Clause 6.3 refers to changes to the ISMS. This is broader than technical change management. It is not limited to software releases, firewall rule changes, server upgrades, or application deployments. Those kinds of technical changes are important, and ISO 27002 includes change management guidance for information processing facilities and information systems. ISO 27002 explains that changes to such facilities and systems should be subject to change management procedures, including impact assessment, authorization, communication, testing, implementation planning, fallback considerations, and records. However, clause 6.3 is at the management system level. It is concerned with changes to the way the ISMS itself is planned, operated, maintained, or improved.
Some examples include changes to the ISMS scope, changes in roles and responsibilities, changes to the risk assessment methodology or risk treatment process, changes to policies and procedures, or changes to how performance is monitored and measured. In practice, the line between technical change and ISMS change can overlap. For example, introducing a new cloud service is a technical and operational change, but it can also affect the ISMS. It may introduce new suppliers, new legal or contractual requirements, new access control arrangements, new risks, new controls, new monitoring requirements, and possibly changes to the Statement of Applicability.
What planned manner should include -
A planned change does not need to be complicated, but it should be controlled. For a meaningful ISMS change, the organisation should normally be able to answer several basic questions.
What is being changed? -
The organisation should be clear about the subject of the change. Is the change about scope, policy, process, responsibility, control implementation, documentation, supplier management, risk methodology, or monitoring?
Why is the change needed? -
A change should have a reason. It may come from a risk assessment, internal audit finding, management review decision, legal requirement, incident lesson, supplier change, business change, or improvement opportunity.
Who is responsible? -
Someone should own the change. This does not mean one person must do all the work, but there should be clear responsibility for coordinating the change and ensuring it is completed.
What is the expected impact? -
The organisation should consider whether the change affects risks, controls, interested parties, resources, competence, communication, documented information, monitoring, internal audits, or management review.
What needs to be updated? -
A change to one part of the ISMS often requires updates elsewhere. For example, changing a risk methodology may require updates to the risk assessment procedure, risk register, reporting format, management review input, and internal audit criteria.
How will the change be implemented? -
There should be some form of implementation plan. For smaller changes, this may be a simple task list. For larger changes, it may require a formal project plan.
How will the organisation know the change worked? -
The organisation should consider whether the change needs review, testing, approval, monitoring, audit follow up, or management review.
A simple example: Changing the risk assessment method
Suppose an organisation has been using a very basic risk assessment spreadsheet. Over time, the organisation realizes that the method is too vague. Risk owners interpret likelihood and impact differently, results are inconsistent, and management finds it difficult to compare risks across departments. So, the organisation decides to revise the risk assessment method. This is clearly an ISMS change. It affects clause 6.1.2, the risk assessment process. It may affect risk criteria, scoring, risk acceptance, treatment priorities, reporting, and management review.
A planned approach could include reviewing the weaknesses of the current method, defining updated criteria, agreeing the method with relevant stakeholders, updating the risk assessment procedure, training risk owners, reworking the risk register where needed, and reviewing whether the new method produces more consistent and useful results. Without planning, the organisation might simply replace the spreadsheet and create confusion. With planning, the change becomes controlled and traceable.
A second example: Expanding the ISMS scope
Imagine an organisation originally certified only one department or location. Later, management decides to expand the ISMS to include another business unit. This is not just an administrative edit to the scope statement; it can affect the entire ISMS. The organisation needs to consider the new internal and external issues, interested parties, processes, assets, information flows, suppliers, legal and contractual requirements, risks, controls, objectives, resources, competence needs, communication arrangements, internal audit programme, and management review scope.
A planned approach would define the scope change, assign responsibility, identify affected processes, perform or update risk assessments, review the Statement of Applicability, update policies and procedures where needed, communicate responsibilities, and ensure the new area is included in monitoring and internal audit activities. This is exactly the kind of situation where clause 6.3 becomes important. The change may be beneficial and necessary, but it still needs to be managed.
What an auditor is likely to look for during an audit:
An auditor will not normally expect a large separate procedure just for clause 6.3, unless the organisation has determined that such a procedure is needed. The auditor will usually look for evidence that changes to the ISMS are identified, assessed, approved where appropriate, implemented in a controlled way, and reviewed when necessary. The auditor may ask about recent changes to the ISMS. For example, they may ask whether the scope changed, whether there were changes to policies, roles, tools, suppliers, controls, objectives, risk methods, or legal requirements. They may then follow one or two examples to see whether the change was planned and whether related ISMS elements were updated.
Typical evidence could include meeting minutes, management review records, change logs, project plans, updated procedures, version histories, risk assessment updates, Statement of Applicability updates, internal audit programme changes, communications to relevant personnel, training records, or follow up actions. The auditor will likely be interested in consistency. If the organisation says a change was made because of a new risk, does the risk register reflect that? If a control was added or removed, does the SOA reflect that? If responsibilities changed, were they communicated? If a supplier changed, were supplier risks reviewed? If an incident led to a change, is there evidence that the lesson was carried into the ISMS? This is where clause 6.3 connects with the rest of the standard. It is a short requirement, but it supports the integrity of the whole management system.
Conclusion
Clause 6.3 is brief, but it plays an important role in keeping the ISMS controlled and realistic. It recognizes that an ISMS will change over time, but those changes should not happen by accident, habit, or undocumented reaction. They should be planned in a way that fits the significance of the change.
This does not require unnecessary paperwork for every minor adjustment, but it does require discipline. When a change affects the ISMS, the organisation should understand what is changing, why it is changing, who is responsible, what else is affected, and how the change will be implemented and reviewed. Seen in context, clause 6.3 completes the planning logic of Clause 6. Clause 6.1 requires the organisation to address risks and opportunities. Clause 6.2 requires it to establish objectives and plan how to achieve them. Clause 6.3 then reminds the organisation that when the ISMS itself needs to change, those changes should also be planned. This is how the ISMS remains alive, controlled, and aligned with the organisation. It is not a static set of documents. It is a management system that must be maintained as the organisation changes around it.