The following is a guest post from Rob, our Information Security Manager. We spend a lot of time at Cronofy thinking about how to do security well rather than just demonstrably — so when Rob offered to write about why he thinks compliance work is more creative than its reputation suggests, we were glad to hand him the keyboard.
The most constrained roles produce the best creative thinking, and I have ISO 27001 to thank for it.
Most people hear "Information Security" and picture someone just ticking boxes and writing reports, and while I may own a clipboard, this misconception couldn't be further from the truth.
The reputation isn't entirely undeserved. Most people probably don't have a "favorite section" of ISO 27001 (I do, it's Clause 8.1 – Operational planning and control, but that's not the point). If you were to read this standard for the first time, you're not likely to see this as a creative playground, more of a list of rules you must abide by. It's not particularly an easy read either, the language is precise and dry by design. Compliance frameworks exist to create consistency and accountability, which calls for defined structure.
It's easy to see why people assume that structure leaves no room for independent thought, let alone creativity. If the standard tells you what to do, surely your job is just to do it? Tick the box, pass the audit, repeat again next year. In my opinion, though, this is confusing the guidelines with the end result. The framework describes the destination, and provides freedom around how you get there.
What ISO 27001 actually gives you is a set of outcomes to achieve rather than a strict script to follow. The purpose of this particular standard is "to provide requirements for establishing, implementing, maintaining and continually improving an information security management system". It doesn't tell you how to design that system for your organization, your specific company culture, or your risk appetite. That gap between the requirement and the implementation is where the real work happens. This is where we can put down the clipboard for a moment and get creative.
Every business is different. Compare a tech startup with a 150-year-old financial institution. Both might be working toward the same ISO 27001 certification, but the controls they build will look almost nothing alike. The framework provides a standard, not a shared blueprint. It must be interpreted for your context, which includes balancing security controls with actual usability, and applying pragmatism to find what will work in the day-to-day of your business.
I've come to think of the framework less as a constraint and more as a foundation. It handles the "what needs to be true" question so that I can focus my energy on the more interesting "how do we make it true here, for Cronofy, in a way that actually works."
Let me give you a concrete example from our own ISMS implementation. Take, for example, Annex A, Control 6.3 – Information security awareness, education and training. The control requirement states:
"Personnel of the organization and relevant interested parties shall receive appropriate information security awareness, education and training and regular updates of the organization's information security policy, topic-specific policies and procedures, as relevant for their job function."
Information security training; the one thing everyone cannot wait to do when they join a new company. It would be easy, and perfectly reasonable, to see this requirement and implement an hour of videos covering a range of security topics, along with mandatory agreement to all the company policies. Box ticked, right?
In some cases, that is really the approach you need. Creativity can often provide more challenges than just ticking the box. Take 5.5 – Contact with authorities, for example. The best way to implement this control is to simply just do it, getting creative here is more likely to cause you pain and introduce risk than it is to deliver value.
However, let's consider the real intention behind control 6.3. Is it to make people sit through videos and thousands of words of company policies? Or is it to ensure that everyone receives business appropriate guidance on how they need to conduct themselves day-to-day in order to uphold the company's security posture?
That's why we decided to do this in a format we believe easier to digest. All new starters have a 30 minute meeting with the Information Security Manager, where we run through a practical session (PowerPoint aided) on their day-to-day responsibilities with regards to information security, and what the practical applications of this guidance are. This is an open session to allow employees to ask as many questions as they like, and the session is tailored to the role the individual will be performing.
An example slide from the training deck, outlining some key high level behaviors that help underpin our Compliance culture.
Of course, policy agreement is also a part of this, but we supplement our policies with a handy practical guide to what this means in reality, which we call our Security Practices. Reviewing the details of critical policies is important, but having a reference guide on hand that is more straightforward to digest makes it more likely that people will ask the right questions, and therefore do the right thing when the time arises.
You can't get away from the fact that all employees need to review and agree to the business' security guidelines, but we choose to apply this in a manner that will actually land with the team. This wasn't a box that needed ticking, it was an opportunity to deliver long term value through considered implementation.
We've applied this same creativity in numerous other areas of our ISMS. For example, learning from information security incidents. Cronofy is a business that encourages and thrives off honest and open feedback. This means we can use post-incident reviews as an opportunity to not only learn more about the incident itself, but as an open forum to discover how we can all do better. This will often surface potential improvements beyond the immediate post-incident remediation. For example, development opportunities for more junior members of the team often come out of our post-incident reviews, by getting them involved in process improvement and the design of new controls. This only happens because we are considering the value we can derive from the process rather than reviewing the incident at face value in order to tick the box.
Anyone working inside a defined set of rules, such as in finance, in engineering, or in HR, often faces the same choice. You can treat the rules as a ceiling, doing exactly what's required and no more. Or you can treat them as a floor, a guarantee of minimum standards that then allows you to build something better on top.
The framework isn't what makes the job feel constrained. If anything, it's what makes ambition feel safe. You have a strong foundation, a shared standard, and a common language with auditors and stakeholders. Within that, there's more room than most people expect.
There's no need to put down the clipboard or take off the high-vis, but if you work in a role that lives inside rules, are you treating your framework as a checklist, or as a canvas?