Regulators and auditors expect us to have all kinds of controls in place to manage information security. Standards like ISO 27001 or frameworks like the CIS Controls are helpful guides for applying these controls, but they don’t ask questions in the same way a regulator or auditor would.

Many organisations don’t catalogue the software and controls that protect the good guys and keep the bad guys out. That led me to develop a risk assurance framework to address this gap. To build the framework, I decided to apply the ‘questioning’ approach in some of my previous operational risk roles in regulated organisations.

What is it?

The risk assurance framework defines the security controls we have (or should have) in place across the organisation. It combines asset registers with process descriptions in place to counter risk. It explains how the organisation knows these controls are working, how it verifies that, and what it does next if a control stops working or flags up an alert.

How to create the framework

Standards tend to be deliberately technology agnostic. In the risk assurance framework, we can be much clearer about the tools we have in place: “we use this brand of firewall. This system sends alerts to [a named person/team/email address] [in real time/every day/every week], and here’s how we act on those alerts. These alerts are read [as soon as they arrive/on a daily/weekly basis]. This is how we get oversight to know that the firewall works, and here’s what we do when it doesn’t.”

You can also document where the alerts and other relevant output is stored [the artefacts or evidence which auditors look for], including any periodic reviews, such as formal discussions or meetings [agenda and minutes] with your support teams or providers.

In short, the framework explains how you manage the control. You then repeat the process for each security control in the organisation. It’s all there, in one place, in a format that an auditor wants to see it, in a language they understand. It means you’ve thought about security and risk from their perspective.

Why it’s useful

Asking questions is a great way to define how an organisation currently handles security, because the answers may point the way to where it wants to go. The process of writing down ‘here’s what I have’ leads directly to asking: ‘do I have what I need?’

Even if a control is working, it’s worth asking if it’s at its best. For example, is a tool producing too many unnecessary alerts? Does it need to be reconfigured? As anyone who drives a car can attest, every now and then it’s worth checking the pressure, pumping up the tyres, and measuring the oil level. Rather than only checking when something goes wrong, a periodic health check can uncover ways to improve on security. Think of it as good governance.

For organisations in a regulated sector, this risk assurance process can also save valuable time on preparing a brand-new document in an unfamiliar format, for when the regulator calls. It also cuts down on the time you need to prepare for an audit.

Who can use it

Just because the process I’m describing seems rigorous doesn’t mean it’s only suitable for large organisations. I see it being useful in lots of different scenarios or companies. It’s not about how many people are in your company, it’s about a mindset and approach to security. The risk assurance framework demonstrates that you have effective oversight and are monitoring the security controls you have in place.

I’m not suggesting that every company needs to do it, but if your role involves dealing with auditors or regulators, this will save you valuable time and effort. You can also adapt it for vetting any third-party providers. Even where such a document isn’t a requirement, it’s still good to have because it informs your understanding of your controls are, in plain English, in simple terms. It puts security in a language that a business owner understands, and that’s always a useful exercise.