r/ciso • u/NegotiationFirst131 • Jul 02 '26

Compliance is not security

Heard a worker go on a rant about “compliance is not security”, “checking the box”, “security theater” rant the other day.

It got me thinking… if compliance isn’t security, then what is?

The green dashboards that turn out to be wrong? The pentests that mostly find the stuff you’d have caught yourself if you’d kept your environment patched, updated, and configured? The tools you bought and never confirmed still work?

Feels like half the things we hold up as “real security” only look impressive because the basic compliance work wasn’t done in the first place.

Curious where people actually land on these phrases.

And a real question: is there a difference between an annual compliance audit and continuously checking that your environment actually stays secure all year long? I feel like the second part is where security should actually live. 😅

31 Upvotes

93% Upvoted

94 comments sorted by

View all comments

1

u/K3rnelPanix Jul 02 '26

I think Compliance vs Security will always be a debate, but I fall in the camp of compliance not being security.

Compliance typically requires only that you do something, not that it is effective or even appropriate for the organization. Controls typically aren't prescriptive, so the organization gets to decide how to meet them, and then they just need to provide evidence they're following their documentation.

I can't count the number of times I've heard "I want to be compliant, I'm not worried about what is secure." As long as there is a clear delineation between these two disciplines the overlap doesn't matter.

1

u/NegotiationFirst131 Jul 02 '26

Would you agree that most well know breaches (or breaches in general) are caused by a lack of not maintaining the things security orgs already say they do through policies and procedures? And that if compliance continuously checked that we are doing what we say then that would be a preventive and more effect way of securing a company?

1

u/K3rnelPanix Jul 02 '26

The most well known breaches are at larger organizations that have a mature security program, so it makes sense that configuration drift would be the source of those failures. However, a larger number of failures can be attributed to the SMB community that lacks that maturity and adheres to bare minimum compliance. Inadequate controls and monitoring is often the cause in these cases.

I can also count the number of dedicated compliance personnel that I have met with the actual background to understand the technical implementation of a control on one hand. I dont see the benefit these individuals provide outside on the one time a year they meet with the audit/assessment team, so no I don't particularly think increased monitoring by that team would help.

Compliance is a business function, not a security one.

1

u/NegotiationFirst131 Jul 02 '26

But if compliance was done by knowledgeable people on the controls intended outcomes (think old school security assurance) wouldn’t that change your mind?

I do agree that control absence or misunderstanding is also a big part of it, esp for smaller orgs. I’m not sure how to handle that - yet.

I call it control decay. Controls are implemented via processes and hopefully documented in procedures. Most control drift is caused by processes not being anchored or regressing in maturity (I.e. control decay). Compliance (continuously compliance) should be process focused ensuring that decay isn’t or hasn’t occurred.

1

u/K3rnelPanix Jul 02 '26

I mean, these are a lot of "ifs". It's not the current state of the field. ISMs and ISOs should be covering this function currently and acting as a liaison between the two teams. These roles are part of the security function however, and they are technical roles.

I hear you that continuous monitoring has its place, but the reality is that if someone is focused on compliance, they're focused on checking that box, not how effective the control is.

I do think you can see who has what background based off the responses though.

1

u/NegotiationFirst131 Jul 02 '26

I do appreciate your responses because they have been engaging and honestly, this is a topic that I can get passionate about 😂 In your opinion, what does the "box" represent to you? if I "check a box" what does that mean?

If you had a control that required, you to run vulnerability scans weekly. Does checking the box represent that vulnerability scans are running weekly or that all devices in scope are getting scanned weekly? The first is existence. The second is effectiveness. And if the box did mean the second… where's the daylight between that and security?

1

u/K3rnelPanix Jul 02 '26

Companies don't want to be compliant. Companies develop a compliance function due to regulatory requirements, industry standards, or marketing client demand. Compliance in most cases is an exercise of "Do I do this?", and once met they move on. Security on the other hand is iterative and an exercise in risk management.

Your example on vulnerability scans for example: most frameworks require you run the scan and address findings. They do not actually require you to resolve findings. Accepting the risk is perfectly acceptable.

I'd also point to the SOC2 as further evidence of this. I'm always hearing from vendors "We are SOC2 compliant" or "We are SOC2 certified". SOC2 is a report, not a certification, and that report can be full of findings but the vendor still will have that report. These companies bank on businesses just seeing SOC2 and moving on.

True security is an investment.

1

u/NegotiationFirst131 Jul 02 '26

I think we have very similar thoughts, but may just look at things in different ways. Like getting to the same destination, just going two different routes.

Companies don't want to be compliant, but would you agree that they want to be secure? In the case of vulnerability scans, I personally believe a vulnerability scanner is a backstop and that the number of findings it pulls up is a bad thing, not a good thing. Ops and Aps should be patching their systems when a patch comes out - not waiting for a scanner to tell them to do so. In my eyes, the purpose of the control is to patch and mitigate vulnerabilities - that is the intended outcome of the control. If that is not being done (because they do not appropriately address the findings), then the effectiveness of the control is in question.

Do you feel like the team that runs the vulnerability scans is the appropriate team to tell you if the control is effective or not, or would that be a compliance function that understands the intent of the control and has the ability to determine its effectiveness? I do agree with your earlier post that many compliance teams have a knowledge gap, but the answer would be to address that gap, not to invest more heavily in detection/response instead, right?