I was talking to one of our customers recently and they asked for my opinion of ISO20000 Part 9 – Cloud Services. Luckily it was an audio Skype conversation so they couldn’t see me shrugging my shoulders and, to my professional shame, I had to admit that I hadn’t read it and so couldn’t give an opinion. Well, as soon as I replaced the virtual Skype receiver to end the call I hurried over to the ISO website to purchase a PDF copy for the princely sum of one hundred and thirty-eight Swiss Francs (gotta love the ISO, they’re so, well…Swiss) and started reading.
Now I have to admit that my experience of buying what might be called “non-core” ISO standards (i.e. those other than the main requirements and accompanying code of practice) is a bit mixed. Some are very useful – ISO27005 (information security risk management) and ISO27017 (information security controls for cloud services) for example; good, solid discussion of important areas of the base standard that add to your knowledge and help you to meet the requirements in a more effective way. Others not so much – when implementing ISO9001:2015 for CertiKit we followed the advice in the standard and bought ISO9000 as it was said to be “indispensable”. Unfortunately I felt no wiser about quality management systems after reading it than before I’d got my credit card out.
So I approached ISO20000 Part 9 with caution, keen to see if delivered on the promise of the title; after all, “Cloud Services” has to be pretty relevant, right? Well, if you were expecting a version of Part 1 (the requirements) expanded to describe how it applies to cloud, then this really isn’t that. Nor does it follow the structure of similar guidance such as ISO27017 and ISO27018 (controls to protect personally identifiable information in the cloud) which expand on the ISO27002 code of practice and clearly map onto that document. No, ISO20000 Part 9 consists of a set of fifteen “Scenarios” which are activities a cloud service provider (CSP) might want to do as part of the lifecycle of a cloud service. For each scenario it then sets out a description, outcomes, applicable clauses from Part 1, guidance on application to cloud services and lastly some examples. The fifteen scenarios covered are as follows:
The standard (or more accurately, the “technical report”) is thirty pages long which, as it happens, is exactly the same length as its equivalent in the area of information security, ISO27017. But is it useful?
Well, one of the ways in which Part 9 differs from the approach taken in ISO27017 (information security controls for cloud services) is that it considers only the point of view of the provider of cloud services; it doesn’t provide any guidance about how to adapt ISO20000 when making use of cloud services as a customer, so in some respects it only gives half the story. I’ve had many lengthy conversations in the past with organizations who want to become certified to ISO20000 but who make extensive use of cloud services from other providers (and let’s face it, who doesn’t nowadays?), with concerns over scope and degree of control required often quoted.
But from a cloud service provider’s viewpoint, Part 9 tries its best to bring out the considerations specific to cloud that need to be considered when implementing and using an ISO20000 service management system (SMS). It mentions the key issues including multi-tenancy, geographical spread, automation and self-service provisioning in many places and describes in outline the impact these considerations may have on how the SMS should work. Whist the guidance section of each scenario is fairly useful, it’s really the examples part that contains probably the most helpful content, setting out lists of issues to consider and questions to be asked and mixing those in with suggestions about how a cloud service could be set up and managed. I do wonder however, whether it may have made more sense to the reader to structure Part 9 around the headings and processes in Part 1 and then provide the examples in an appendix. This would then have brought out the cloud specifics of familiar processes such as service level, change and release management and make it easier to relate to the requirements as stated in Parts 1 and 2. Maybe this would have made it too similar to Part 2 – was that their thinking perhaps?
The overall impression I’m left with when reading Part 9 is that, whilst there are some ways in which an SMS for cloud differs from an SMS without cloud, the fundamentals are of course the same. So does Part 9 add value to Parts 1 (requirements) and 2 (code of practice)? Just about – but I don’t believe Part 9 will be seen as an indispensable document for cloud service providers when implementing an SMS any time soon. It will be interesting to see how much of the content of Part 9 makes its way into the next version of Part 1 which I’m told is due mid to late 2018, although this is likely to focus on making the management system Annex SL (High Level Structure) compliant.
Overall recommendation – Buy Part 9 if you’re a CSP with money to spare, but don’t worry about missing out if you don’t buy it.