Welcome back to our series on building security programmes. A series we hope helps not only you better secure your organisation, but also highlights CDW’s commitment to help customers approach security holistically and effectively with their unique business context in mind. 

In this instalment I want to introduce the part of the framework that handles compliance, or rather, third-party compliance. 

It may surprise some that we’re now 12 domains deep into our example framework and only now touching on compliance…but that’s not actually true. 

Everything is geared towards compliance

In fact, everything we’ve done has been with compliance in mind. Indeed, the very purpose of the framework and the programme is to achieve and maintain compliance. 

The difference is that it’s compliance to what we’ve determined is best for our particular organisation. As it should be!  

A lot of organisations build their security programmes off the back of third-party frameworks like ISO, CIS, or NIST. 

I believe this is a mistake for the simple reason that those frameworks lack focus addressing their business’ specific systems and processes. 

We are far more likely to have complete, holistic, and appropriate coverage, in more business-aligned, less expensive, and less disruptive ways, by moulding a bespoke framework to our reality rather than trying to retrofit a third party’s idea of security. 

Especially when that “security” is mostly technical security controls with limited understanding of people and business, and zero understanding of our people and our business. 

We now associate “compliance” with ISO, NIST, CMMC, Cyber Essentials, etc. That’s not what compliance is though, is it? 

Compliance is the measure or process by which our reality meets its defined and desired optimal or ideal state. 

That means having those definitions of what good (as in secure) looks like for everything in our environment is crucial for any effort at compliance to yield any actual security. It’s why today’s “compliance” to arbitrary third-party standards rarely, if ever, ensures optimum security outcomes by themselves. That is, however, the precise point of our framework and its various domains.  

In short, our ultimate compliance goal is to be compliant to what we have defined in our framework.  

We define our ideal state, for each system and business process, and comply to it. It’s not just a lot easier and a better fit than trying to apply a generic control to every business process. Instead, by moulding our ideal state according to our business we are far, far less likely to omit important elements or areas of our business than by basing ourselves on an external standard that has no awareness of them.  

It also means that our compliance activities make more sense to others in the business as they are a direct reflection of it, which helps gain traction from stakeholders and increases the likelihood of that compliance being maintained. 

Not just 'compliance', but third-party compliance

As such, the Compliance Domain is a bit of a misnomer in the same way that “compliance” is, nowadays, mostly a misnomer. Because the entire framework is about compliance, our “Compliance” domain here is actually about third-party compliance. 

In other words: mapping our ideal compliance to what third-party standards expect. 

The good news is that, by having systematically gone through all our business and IT processes to ensure they are secure with our programme/framework, we are likely to be close to 100% compliant to most third-party standards too. What we need to do is map one to the other. 

Each component of this domain is a mapping of all the expected items in each relevant third-party standard to where they can be found in our framework.  

It’s important to note that if a required third-party standard requires something that our bespoke framework lacks, we then add it to our framework. This means we only need to maintain one compliance programme to comply to a potentially significant number of external standards simultaneously. 

That’s another benefit of focusing on our framework: we not only get better security, but we simplify management by only needing to focus on one framework to be compliant with any number of third-party standards.  

Better still, when the need arises to become compliant to a new third-party standard, we only need to engage in a mapping exercise, rather than launching an entire new compliance programme.  

This translates into more agility and opportunity for the business by allowing it to quickly pivot into regions or industries where additional compliance requirements might otherwise have been a barrier. 

Finally, we eliminate a lot of what would normally be considered “compliance work”, because compliance is part and parcel of the processes in our framework. If our processes include what’s needed to demonstrate compliance, then our processes are our compliance. 

As always, if this approach to compliance is one that interests you, don’t hesitate to get in touch so that we can assist. 

Join us next time for a look at defining how our security programme can define security’s commercial contributions to the business.