Fractal ISMS changes

'6.3 Planning of changes' is a succinct new clause in ISO/IEC 27001:2022, one accidentally omitted from the contents listing (oops).

Simply put, changes to the Information Security Management System must be planned, rather than simply happening haphazardly.

What kinds of ISMS changes would this cover? Without further clarification, it could be argued that any and every change to the ISMS has to be "carried out in a planned manner", begging further questions about the intended purpose and scope of the clause, and of the ISMS itself. 

If we add a new topic-specific information security policy on IoT, for instance, or update the risks list, would such changes need to be planned? How about simply renaming the organisation's list of risks to, say, Information Risk Register - should that be planned? Would correcting a little typo in an ISMS procedure or awareness item count as an ISMS change that has to be planned? 

Strictly speaking, the answer is yes: even trivial changes should probably not be made purely on a whim because the ISMS is 'a system'. The component parts of the ISMS are designed and intended to work together as a whole, hence changes to any part may have consequences elsewhere. Adding a new security policy, for instance, implies a process to specify, develop, review, approve, implement, raise awareness, monitor and ensure conformity with the policy - a managed sequence of activities that really ought to be planned. Even correcting a simple typo means identifying the error, opening the document, correcting it and closing the document - again a planned sequence. 

What does 'planned' mean in this context? Essentially it means changes to the ISMS should be considered prior to being carried out (performed or made). Significant changes may need to be authorised or approved, although the standard doesn't actually insist on that, leaving such implementation details to the organisations using the standard ... and the certification auditors ...

So, how will clause 6.3 be interpreted by the auditors? It's hard to say at this point because the clause is quite vague and we're all coming to terms with the new edition of the standard. It will take time to develop consensus, if at all: the certification bodies and individual auditors may differ in their understanding and expectation of planned changes. Meanwhile, auditors will probably take an interest in any recent changes to the ISMS, and may seek evidence that they were 'planned'.

We will be advising clients not to ignore clause 6.3 altogether but to interpret it sensibly, pragmatically, focusing on substantial or significant ISMS changes (whatever that means in the client's context). Evidence of change planning may include, for example:

• ISMS change proposals, suggestions, specifications etc.;
• Agenda items, minutes or notes from management meetings where proposed ISMS changes and the implications (including risks) were debated;
• Some sort of change approval, authorisation, agreement or go-ahead, preferably in writing from an appropriate level of management (meaning 'top management' for significant ISMS changes);
• Possibly evidence of proposed changes being rejected, deferred, modified or reconsidered by management, clearly demonstrating their active involvement in the process;
• Project plans showing timescales, steps/activities and resources assigned to complete non-trivial changes;
• And so on. Clients may have different ways of planning changes and being able to demonstrate that if asked. Since the standard does not demand a particular approach, there is plenty of latitude here provided the auditors are satisfied as to conformity with clause 6.3.  

It is conceivable that inexperienced "jobsworth" auditors* will leap on ANY ISMS change, adamantly insisting that not only should it have been planned, but that evidence must be provided to substantiate the planning.  

Although clients could develop and implement an ISMS change policy and procedure, that is not strictly necessary for certification and, to my mind, is pure red tape unless perhaps there have been particular issues with unplanned ISMS changes that need to be brought under management control. It makes more sense, I think, to process ISMS changes through the continual improvement and conformity activities specified in clause 10, so it may be worth adding 'ISMS changes' to the policies, procedures or forms used for continual improvement. 

We will also be advising clients to review ISMS changes in their ISMS management reviews and internal audits, for example evaluating the evidence that any recent reasonably substantial changes were planned. As with other review and audit findings, if the evidence is lacking, that can be addressed through the 'nonconformity and corrective action' activities under clause 10. The idea is simply to use existing mechanisms where possible rather than creating red tape for the sake of it ...

... talking of which, some clients already have change management policies and procedures in place, typically specifying the process of proposing, considering, evaluating and approving changes to IT systems etc. Some even have information security policies and procedures, covering the information risk and security aspects of changes, in which case it may make sense to process ISMS changes in exactly the same way. If not, well maybe this is a change worth proposing ...

Yes, it is necessary to plan how to plan changes.  Fractal or what?

* "Jobsworth" relates to "It's more than my job's worth to let you get away with this" regarding some incidental, insignificant and essentially pointless finding. I'd suggest giving such an auditor a smack about the head, figuratively speaking (not literally, please, no matter how tempting that may be!) by reminding them about the purpose of the ISMS and the audit, and jointly reviewing the precise wording of clause 6.3. It does not specify which ISMS changes are to be planned, nor how that is to be demonstrated to the auditors (e.g. it does not insist on 'documented information'). Technically, credible evidence such as a manager confirming that any single ISMS change was planned in some fashion is sufficient to claim conformity, since the standard does not literally say ALL changes. Reaching a mutually-acceptable position between these two extremes is then simply a matter of debate and persuasion, the usual cut-and-thrust of audit clearance. Good luck with that.