Frankly Speaking 6/28/22 - Don't confuse compliance with security

Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.

I know it’s been a rough week for many people, including myself, so I want to thank everyone for taking the time to read and subscribe. As always, I welcome feedback and suggestions on content.

LET’S BE FRANK

I’ve written that compliance drives security value in the past, but I realize I didn’t capture many of the nuances in that post. I’m revisiting this and possibly revising some of my previous statements because I believe that security has been slow to keep up with recent tech trends. In fact, by talking with security leaders and observing security strategies, I am certain that this area will remain confusing for a while.

To be clear, compliance and security should be treated as two separate goals. However, of course, if compliance and security can be achieved in the same initiative, that’s an ideal situation. I will talk about a few cases where that’s happened, and it’s no surprise those tools have driven immense value.

In this newsletter, I’ll talk about the following:

• Why compliance and security should be separate goals, especially with the cloud

• Consequently, how we should think about these goals in an organization

• How security companies should think about compliance and security as go-to-market strategies

• Finally, I’ll talk about some products that achieve both goals

Compliance and Security: A Tale of Two Cities

It is common to conflate compliance and security. Many compliance requirements might seem like they provide security. For example, certain scanning tools might fulfill compliance requirements, but a company probably shouldn’t blindly follow the output of these tools. Is it good to keep your dependencies up to date? Probably. However, companies don’t have unlimited engineering resources. Updating a dependency requires testing the codebase to ensure functionality, which might be complex. Could this limited engineering time be better spent doing something else?

This is the crux of the fallacy — the belief that compliance leads to better security. Compliance is necessary for an organization to demonstrate they have a bare baseline of security, but saying it is necessary for security might actually be dangerous and counterproductive.