Reading between the lines of ISO27001 [L O N G]
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 Information Security Management System 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 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*
- 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.