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.

Popular posts from this blog

Pragmatic ISMS implementation guide (FREE!)

Image
Early this morning ( very  early!) I remotely attended an ISO/IEC JTC 1/SC 27/WG 1 editing meeting in London discussing the planned revision of ISO/IEC 27003:2017 . Overall, the meeting was very productive in that we got through a  long  list of expert comments on the preliminary draft standard, debated the objectives of the project and the standard and reached consensus on most points. In summary: 27003 is to be revised to align with the current 2022 releases of ISO/IEC 27001 , 27002 and 27005 : These changes are  mostly  minor aside from the new section 6.3 on ISMS changes.
Read more

Two dozen information risks that ISO forgot

Image
Selecting the wrong controls - controls that are inappropriate, ineffective, too costly, impracticable, fragile, unnecessary, counterproductive or whatever, often as a result of blind faith in fads and fashions of the day and FOMO e.g. MFA, AI, cyber Failing to select the right controls - controls that are ideal for the particular situation, both now and in perpetuity, for whatever reason - mostly ignorance and prejudice Selecting and implementing controls at the wrong time or in the wrong way (where 'wrong' includes ineffective, inappropriate, sub-optimal e.g. bolting on controls rather than designing and building them in) Inept and inaccurate identification, analysis and quantification of risk, including reliance on p oor quality (incomplete, inaccurate, out of date, misleading, unreliable ...) information about actual risks, particularly subtle and emerging risks plus those involving deliberate concealment and misdirection e.g. fraud, misinformation, disinformation, propagan
Read more

Philosophical phriday - compliance risk

Image
According to a vendor's promotional video interview I saw recently, the 'cybersecurity compliance burden' has allegedly become so significant that [customer] organisations are eagerly buying [their] software tools and services to help them manage and fulfil their obligations. The vendor's argument goes that, instead of accumulating a ragtag bunch of policies and other controls relating to user Identification and Authentication (I&A), for instance, it makes sense to:  Identify all the cybersecurity-related laws, regulations and standards that apply to the organisation; Examine them for any security control requirements relating to, say, I&A; Rationalise the I&A controls down to the smallest set that satisfies all the requirements - the lowest common denominator; Design, implement, use, manage and maintain those I&A controls; Have the I&A controls checked or audited to gain assurance that the compliance requirements are met.  OK so far? Sounds reasonab
Read more

ISMS internal audit priorities

Image
A thread on the ISO27k Forum sparked my imagination over coffee this morning. Hope had previously asked for assistance with an ISO/IEC 27001:2022 audit plan.  Bhushan offered a lengthy and generally sound response explaining how to use a spreadsheet with tabs to plan and record the audit work performed on 100% of the main body clauses and 50% of the 93 Annex A controls, day-by-day. That's OK ... except it wasn't entirely clear that he was interpreting and elaborating on the standard's actual requirements. ISO/IEC 27001 does not explicitly require, for example, that (as Bhushan stated) "ALL the management system clauses from 4 to 10 AND their sub-clauses need to be listed and audited" in an ISMS internal audit, although evidently he interprets it in that way. In clause 9.2.1, the standard states a requirement for internal audits to provide information on whether the ISMS conforms to the organization’s own requirements for the ISMS plus the requirements of the stan
Read more

Reading between the lines of ISO27001 [L O N G]

Image
ISO/IEC 27001 is a succinct, formally-worded standard for two key reasons: It is deliberately generic, being applicable to all manner of organisations regardless of difference in location/s, size, industry, maturity, structure, information risk and security status ... and so on. In effect, it specifies the lowest common denominator - the things that ALL organisations should be doing to manage their information security controls, as a minimum. The hurdle is set low enough that every organisation ought to find value in designing, implementing and operating an I nformation S ecurity M anagement S ystem as laid out in the standard. It is a certifiable standard, explicitly specifying the characteristics that every certified organisation's ISMS is expected to have. Again, it is a minimal specification with no concept of typical, average or maximum security: that is entirely down to the organisations themselves to determine, following the information risk management processes minimally de
Read more

Passionate dispassion

Image
Someone who is actively involved in, or is managing, an activity is patently not independent of it. They may well make a conscious, rational and determined effort to be objective, dispassionately reviewing evidence etc ., but their subconscious/emotional biases/prejudices and beliefs/value-systems will inevitably influence what they do. With the best will in the world, they will struggle to challenge and assess their past decisions and activities, especially if they were "certain" or "determined" or genuinely believed they were "doing the right thing". Furthermore, it is very hard for anyone to review the things they did not do, decisions they did not make or options they did not even consider. Mostly, they remain out of sight or out of the question.
Read more

45 ISO Management Systems Standards

Image
The ISO website  currently lists 45 published M anagement S ystems S tandards: 1. ISO 7101:2023 Healthcare organization management — Management systems for quality in healthcare organizations — Requirements 2. ISO 9001:2015 Quality management systems — Requirements 3. ISO 10012:2003 Measurement management systems — Requirements for measurement processes and measuring equipment 4. ISO 13485:2016 Medical devices — Quality management systems — Requirements for regulatory purposes 5. ISO 14001:2015 Environmental management systems — Requirements with guidance for use 6. ISO 14298:2021 Graphic technology — Management of security printing processes
Read more

Philosophical phriday - a noncompliance ramble

Image
In a previous philosophical phriday post , I moaned about vendors of security compliance support/management tools and services over-promising and under-delivering - an admittedly biased, even cynical opinion piece about the compliance imperative . A recent article in Corporate Compliance Insights notes that "CISOs are not just defenders against cyber threats but also champions of compliance and operational resilience". Hmmm, are CISOs 'compliance champs', really? Today, I'm discussing alternatives to being compliance-driven. How else can organisations drive their information risk, security and related concerns in a positive direction?
Read more

Adaptive SME security Crowdstrike special

Image
As if on cue, along comes a golden opportunity to consider what the Adaptive SME security  approach has to say regarding the Crowdstrike incident: That's not 20/20 hindsight but foresight: I've picked out the most relevant rows from the security controls table published in the guide 24 hours before the incident.  Although Crowdstrike primarily supplies much larger enterprises than SMEs, the incident could equally have afflicted other security software, or indeed operating systems such as Windows and assorted cloud apps commonly used by SMEs. Regardless of the details, it is a wake-up call, an opportunity to consider and respond to the information risks ... and to adapt , accordingly.
Read more