ISO/IEC 27001 is an international standard for information security, cybersecurity and privacy protection. It is viewed as an essential standard for many organisations to be secure and compliant. The introduction starts with:
This document has been prepared to provide requirements for establishing, implementing, maintaining and continually improving an information security management system.
It’s huge! In the latest 2022 version of the standard, ISO/IEC 27001:2022, there are 10 sections plus 1 annex. During the audit, it is expected that everything is addressed. From section 5 on leadership, all the way through to section 10 on improvement. Every paragraph requires some sort of response. But it gets worse, in Annex A, there are 90+ controls! And each control must have something in place, or justification must be given why it does not apply to your organisation. I think you get the idea of how huge this is.
In previous years, we gave up on our first 2 attempts. It was simply too difficult and too time consuming for an organisation of our size to dedicate the resources needed to address it. But we took it on a third time and we got there in the end. It took us 15 months but we approached it differently. It was our new ISMS mindset and platform engineering that helped save the day.
ISMS Mindset
Like many, we started the 27001 journey because we wanted to get the certification so we could be eligible for work, as many organisations make this a requirement. While this is true, it initially made us approach 27001 with a tick the box attitude. Approaching it with this attitude made it feel like the ISMS sat off to the side of the organisation and people viewed it as a chore.
So, we switched up our approach and came at it with a new attitude. The ISMS should NOT be a tick the box activity, the ISMS must underpin the business and be integrated across the entire organisation! This epiphany was crucial to our eventual success, but at the time when we were staring at the amount of work and organisational change required, it felt like a mountain to climb.
To take on the mountain, we leaned into our strengths. One of the big strengths is platform engineering, which is discussed more in the next section below.
Platform Engineering
Platform Engineering allows teams to create golden paths and produce artefacts. A good way to imagine this process can be seen in the image below. On the left, in pink, the team creates models of whatever it is they are working on. The models are input to a pipeline that does something useful, shown in purple below. The pipelines can generate useful artefacts, like source code and commit these to a repository, shown in green below.
In the case of an ISMS, there is a lot to model as 27001 and security is massive. We created a bunch of models, and some of the concepts covered include:
- Risk: A container to describe the effect of uncertainty on objectives, for example: a vulnerability.
- Treatment: Actions to modify the risk, by changing its likelihood and/or its impact.
- Control: Any process, policy, device, practice or other actions that modify risk.
- Context: The environmental categories that an risk may affect or originate from.
- Information Asset: Anything valuable to an organisation that should be protected from unauthorised access, use, disclosure, modification, destruction or compromise.
- Policy: A statement of action or procedure that is adhered to.
- Document: Maintained documentation communicating a message or providing evidence of what was planned has been actioned upon.
- Process: A set of interrelated or interacting activities which transforms inputs into outputs.
- Checklist: A set of questions derived from a system standard’s requirements and any process documentation.
- Evidence: Data supporting the existence or verity of something.
A good example of one of the models that contains some of these concepts is the risk register, seen in the screenshots below. We modelled all of the risks that included important information like the people involved, pre and post responses, treatments, and heaps more. As you can see in the first screenshot, it is a big model. And in the second screenshot you can see it zoomed in a little.
 |  |
Modelling the risk register like this provided us a shared understanding and source of truth. But this is only the beginning, as the model can be used as input into pipelines and to output artefacts. In this way, we were able to use platform engineering to create our entire ISMS! Upon running our pipelines, the outputted artefacts include 14 documents (412 page pdf) describing the ISMS and how it works, 37 SOP’s (210 page pdf) that we could link through to our controls, and 37 policies (224 page pdf) describing more aspects of the ISMS.
Summary
Our ISMS is in great shape and I encourage others that are going to undertake this journey, or want to improve what you have, to use platform engineering. With our ISMS modelled, we now make changes to the model (like updates to the risk register), hit the run pipeline button, and the entire ISMS is kept up to date and consistent.
So, we made it! A big thanks to the whole team for working on this. And especially the security committee, seen in the picture below, working from left to right: Matty, Leo, Kellie, Chris, and me. Have a great Xmas everyone! 🎄🎁🎅
Written by Eban Escott
Founder of Codebots
Dr Eban Escott received his Doctorate from UQ (2013) in Model-Driven Engineering and his Masters from QUT (2004) in Artificial Intelligence. He is an advocate of using models as first class artefacts in software engineering and creating not just technologies, but methodologies that enhance the quality of life for software engineers.
