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

ISO/IEC 27001 is a succinct, formally-worded standard for two key reasons:

1. 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 Information Security Management System as laid out in the standard.
   
   
2. 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 defined in the standard.

There are many things the standard does not specify at all, or at least not in detail, for example here is clause 6.3 (new to ISO/IEC 27001:2022):

6.3 Planning of changes

When the organization determines the need for changes to the information security management system, the changes shall be carried out in a planned manner.

That's it, the entire specified requirement consists of a 3-word heading and a single 24-word sentence. 

Oh boy.

Let's explore that one example in more detail - a deep dive into interpreting the precise language of the standard [dons lawyer's flash suit and all-knowing smirk] ...

• "Planning of changes", for starters, is patently about 'planning', but think about all the different ways we 'plan' things. A plan to do anything significant in a business context would normally be a written plan, probably with some sort of summary/overview and more details on the objectives or purpose, the steps/activities involved, the resources required, the timescales, and maybe other aspects such as the business context, constraints, risks and options - different ways to achieve the objectives, or points in the plan where management decisions are made about whether and how to proceed ... hinting at management or administrative or process controls relating to the management of changes, which in turn refers to change-related strategies plus policies, procedures and practices.
  
  
• In stark contrast, my cunning 'plan' to complete this blog piece today is, a best, a vague intention. I didn't even know for sure what it would cover until I got into it. There was no written plan at all, and nobody but me to review and approve it. The objectives were less clear than a smart, dismissive comment from a typically evasive politician. I didn't need to measure or report progress to anyone or explain why I've blown my notional budget of "an hour or so" to write this piece. Was that 'a plan'? Maybe not. For me it was all I needed, so cunning I could have pinned a tail on it and called it a weasel. And patently it worked, because you are reading these very words, so I honestly don't care what you call it. It doesn't matter one jot.
  
  
• OK, so what about "changes"? What is 'a change'? Is correcting a typo on an intranet page about an infosec policy the kind of change that needs to be planned? What if it is not a typo, but several dozen, some significantly affecting the meaning of the words? Is employing yet another SecOps analyst a 'plannable change'? What about the regular shift changes in the SOC? A new strategy? A different tool? An escalating threat? A slight shift of emphasis or priorities? Appointment of a replacement auditor? These are all 'changes' with vastly different implications, all related to some extent to the ISMS.
  
  
• So, should the type and detail of planning reflect the nature and extent of the change? If so, how? 
  
  
• Oh and what is "a planned manner"? That's about as vague as vague can be!
  
  
• Notice all the things that clause neglects to say, such as that the plan should be documented. Hmm, a vague intention to change something about, within or relating to the ISMS, not even expressed verbally, technically constitutes a "planned manner" but, of course, would be virtually impossible to prove to someone, such as an auditor. Hmmmm.

I'm over-exaggerating here to make a point: as formally worded in the standard, that clause is not explicit and detailed enough to clarify the requirement, in which case (formally speaking) we have the latitude to determine things for ourselves ... but having done that, what if the certification auditors have a different determination? What if they interpret the requirement very narrowly, very broadly, or simply differently to us - what then?  

The solution to this little conundrum is to be sensible about things, making a genuine effort to fulfil the likely intent of the clause by, for instance, preparing documented plans for 'significant' ISMS changes (determined according to the context, in relation to whatever is important at that point), having management authorise/approve and resource the changes, stepping through the plans generating evidence to report progress, and retaining as much information as you think might reasonably be required to convince the certification auditors and - more importantly still - whatever is valuable for your own business purposes. Within that flappy envelope, finer details such as what form the documentation should take, or what 'authorise/approve' actually means, are matters for you and your colleagues to determine. 

Go for it! Knock yerselves out!

The easy option in situations like this is to follow convention, doing the usual things in the usual fashion (where that is reasonably obvious), in the hope that the auditor will be happy. However, a conventional approach may not be ideal in any specific situation, in which case taking a different route within the broad confines of the standard is OK but might catch an auditor's eye - so be ready to explain and justify your approach. This becomes more important if your unconventional approach is notably and deliberately strange for particular reasons. Anything markedly out of the ordinary or controversial is, of course, more eye-catching*  

The certification auditors (specifically) are supposed to be doing straightforward compliance auditing against '27001, so any Major Nonconformity they raise ought to specify the clause stating a particular mandatory requirement that is not satisfied. Even Minor Nonconformities should really be related to requirements in '27001, while there is more latitude to point out general issues and 'good practices' etc. in Observations, without explicitly having to cite any corresponding clauses from the standard.

ISMS internal auditors, however, can do whatever form of auditing they are tasked by management to do, poking into whatever they are pointed at, with very little guidance or constraint from '27001. Likewise with ISMS management reviews. You can use both internal audits and management reviews to your advantage in the case of anything unconventional or controversial about your ISMS: presuming the auditors/reviewers notice and bring them up (potentially having brought them to their attention), you have the chance to try out and maybe refine your explanation or argument. If you can't convince them, you will likely struggle to convince the certification auditors, so you might just have to wind your neck in and become more conventional after all. Nice try, but sorry it didn't work out.

OK, now consider how this relates to the rest of the standard, aside from clause 6.3. Issues of this general nature occur throughout the standard. Some requirements are more explicitly and clearly defined, whereas some are even vaguer-er than that "planned manner" thing. 'The conventional approach' is not always obvious, and there are many points of doubt and potential disagreement once you delve deep into the precise language used, trying to relate and apply the standard to what your organisation needs to do in respect of its ISMS. 

Some of those lingering issues can be resolved by:

• Additional advice/guidance in other ISO27k standards such as 27006, or other applicable standards about auditing, compliance/certification auditing, or accreditation, both ISO and non-ISO ones;
  
  
• The emerging series of Auditor Practice Notes from ISO/IEC JTC 1/SC 27 - most not yet written;
  
  
• Standards, codes of practice, guidelines etc. from audit bodies such as ISACA;
  
  
• "Reading between the lines": despite intentions, the printed words are merely hints to be interpreted by the reader. What do you think the committe was getting at when it wrote, reviewed, revised and eventually published those words? What else might they (we!) have been getting at? How might other people - in particular the certification auditors - interpret the same words?
  
  
• Considering your context - specifically, the business situation and requirements that led you to adopt the standard and implement an ISMS in the first place. Was certification even an essential part of it, or in reality did you actually want to up your game in the area of information risk and security management? Certification is usually optional, so what are the implications of simply doing what is best for the business, regardless of conformity with some ineptly-written unclear and easily misunderstood standard from some distant stuffy committee of so-called experts? Stuff em!
  
  
• Asking for help e.g. raising queries or concerns on the ISO27k Forum. By all means ask us whether your proposed or current approach satisfies the standard, telling us as much or as little as you need to explain it without being too explicit on an open forum. You're welcome to contact me directly about it, preferably with all the nitty-gritty details for a more informed, comprehensive and pragmatic response ... but we should probably enter into a formal agreement first because my time is valuable;
  
  
• Experience. Time served. Situations survived. Challenges conquered. Lessons learnt, and delivered successfully. This is, after all, the reason 'my time is valuable': I've invested most of my working life into this, >35 years so far.

* That may even be a good thing if it diverts the auditors' time and attention from other concerns that you would rather slipped beneath the radar! It's a risky strategy though: the auditors might spot and complain about them both, becoming even grumpier than normal due to discovering this annoying little cluster of concerns. Is it an indication of something deeper, such as governance issues, maybe a deliberate attempt to mislead the auditors? Oh oh. That's bad, very bad.