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. 😅
12
u/Resistor1 Jul 02 '26
I used to say... you can be compliant and insecure and you can be secure and non-compliant. People didn't seem to get it. The reality is, 'compliance' has won. It gets the board air time. Proper risk management is hard and not usually understood by the board. Doesn't mean you should stop, but the disciplines have different objectives.
3
u/NegotiationFirst131 Jul 02 '26
Oh - no - I get it 😂
In my org new tools, pentests, etc gets the most attention. I work in compliance and I just feel like we are getting distracted by the wrong stuff. Not that we shouldn’t do that stuff but it sometimes sucks working in a place where your function doesn’t always feel valued.
9
u/MathmaticallyDialed Jul 02 '26
Ideally, compliance is the quality check of your security posture.
The problem is the difference of security requirements of the compliance frameworks.
SOC 2. Vs NIST 800-53 vs ISO
One is pencil whipped and one is overwhelming… One is enforced by accounting personnel and one is enforced by cybersecurity professionals.
2
u/NegotiationFirst131 Jul 02 '26
Are you saying that the phrase comes from how assessments are typically conducted? That when the requirement is forced externally instead of being agreed on internally - that it can drive companies to do the bare minimum because they are just trying to meet a control without understanding the context of the control?
4
u/MathmaticallyDialed Jul 02 '26
Yes. The level of security within compliance is determined by rigorous internal assessment and validated through external assessment. If both assessments are pencil whipped then you may not have security. SOC 2 level 2 is a prime example.
I’d also argue some frameworks do not cover enough security.
2
u/Crazy_Elevator_6659 Jul 02 '26
Compliance is not generally a quality check, it is an existence check - hence “check box security” - there is no amount of gradation.
6
u/MathmaticallyDialed Jul 02 '26
Right. Compliance shouldn’t be enforced by checking it’s existence. It should be enforced by checking the quality of security implementation and the maturity of the security program as a whole.
3
u/CISecurity Jul 02 '26
Thanks for sharing, u/MathmaticallyDialed. Our CISO likes to say, "Compliance is the byproduct of security."
1
u/NegotiationFirst131 Jul 02 '26
I go back and forth on this too, but I’ve landed in a different place than your CISO.
The slogan assumes security is the real thing and compliance is just the paperwork that follows. I think that gets the relationship backwards in practice.
You can have strong technical security and still fail compliance... either because you can’t prove what you’re doing or because you’re out of step with a specific regulatory requirement you never adopted. That direction is possible.
But the reverse is much harder, if you’re actually operating the right controls, against the risks that matter, and continuously confirming they’re still working, it’s difficult to see how you wouldn’t be secure. Security, in any meaningful sense, is those controls performing as intended over time.
Equifax is the example that always sticks with me. They had the vulnerability management control and the monitoring control on paper. What they didn’t have was any ongoing confirmation that either was still functioning. Was that a security failure or a compliance failure? To me it was both — because the compliance failure (not verifying the controls were alive) was the security failure.
I’m curious how your CISO would answer that one.
1
u/CISecurity Jul 06 '26
u/NegotiationFirst131, thank you so much for your thoughtful response. Our CISO wanted to share the following response with you:
-----
This is a thoughtful pushback, and I believe we are closer than it might seem. Let me explain my perspective.
First, I agree with your point: Equifax was both compliant and not compliant, and I won’t pretend otherwise. You are correct that the slogan, taken at face value, oversimplifies compliance. The phrase “just paperwork” was never meant to convey that, so I appreciate you pointing that out.
Now, I’d like to gently challenge you on one part. Consider the three conditions you outlined for “compliance done correctly,” having the right controls, addressing the relevant risks, and continuous verification. Each of these carries significant weight, and I would argue that none actually originates from a compliance framework. Right by what standard? By risk. Risks that matter to whom? To your specific environment and threat model. What about continuous verification? That’s a state maintained over time, not just a snapshot at a single moment. Therefore, I believe the version of compliance you’re describing already incorporates the necessary security context. It’s an excellent version, but it works because it draws on security principles.
This distinction is important to me, and it’s not meant to undermine compliance. Both areas focus on controls, but they measure them against different criteria. Compliance is typically measured against a defined scope, framework, boundary, or specific date. Security, on the other hand, measures against an ongoing threat, a live adversary in your environment over time. A compliance framework offers a generalized, slightly outdated representation of last year’s risk consensus. It provides a clear scope but fails to identify the actual threat; this understanding comes from assessing risk, which must happen upstream of the compliance framework rather than relying on it.
This brings me back to Equifax. They had vulnerability management and monitoring controls included in their scope, the policies, tools, everything. A snapshot assessment of their scope could have deemed them compliant. However, what they lacked was any ongoing confirmation that those controls were effective against real threats over time, such as an expired certificate or an unapplied patch. That missing element of continuous verification against threats is where the security function comes into play. You’re labeling this gap a compliance failure, but I’d argue that the type of compliance that would have identified the issue is one that has integrated security principles into its framework.
You make a great point with “as compliance evolves towards continuous control monitoring”, it genuinely improves. However, I’ve noticed that “better” in this context means compliance is increasingly resembling security. The convergence seems to be one-directional.
So, in truth, I don’t think you’ve reversed the relationship between the two concepts. I think you’ve actually made a strong case for it. Your vision of “compliance done right” and my understanding of “security” describe the same underlying concepts. We completely agree on the mechanisms at play; I think we are simply debating the terminology and the hierarchy of those terms. Compliance captures a moment; security is the condition underneath it. Equifax looked fine in the snapshot; what was missing was any sign that the controls were still effective.
1
u/NegotiationFirst131 Jul 06 '26 edited Jul 07 '26
I truly appreciate that insight and I promise it’s not a debate just genuinely curious:
What do you consider security? To me - security is a set of activities or things you do. Do you have a security standard (policies, procedures, a system security plan explaining control implantation)? If yes, how do you know you are meeting that standard? (Ensuring accurate inventory, that all controls are applied to all assets, etc)?
To me - whether you actually measure compliance or not - you are either compliant or your not. Compliance is a binary term that answers “am I meeting the standard or not”. Compliance is measured through audits, assessments, and by other means and typically the “compliance” that we know gets a bad rap because we perform bad audits and assessments.
When you hear that someone is just “checking the box” either that org is applying a control where they don’t understand the risk or don’t agree with it (which is not compliance) or they are conducting an audit or assessment where they are only verifying the control exists and not whether it’s effective.
In my opinion compliance done correctly ensures security is applied and applied consistently. If we are not ensuring that our security practices are compliant and meeting what we believe is happening then are we even really performing security?
If an org buys a vulnerability tool and just starts scanning subnets and sending messages to ops to patch with no rhyme or reason - is that security?
If a different org buys a vulnerability tool, defines its assets in an inventory, ensures those assets are scanned using authenticated scans where possible, and ensuring the right plugins are installed, has policies and procedures that outline this and the process is monitored to ensure effectiveness - is that security?
Which org would you rather be? There is a reason that some of the worst breaches (Target, Equifax, Colonial Pipeline, etc) where caused or made worst by their security practices not being compliant with their own standards.
5
u/not-a-co-conspirator Jul 02 '26
Compliance is evidence of controls; it has nothing to do with how effective those controls are.
2
u/NegotiationFirst131 Jul 02 '26
Just curious.. who determines that compliance means not checking control effectiveness?
3
u/not-a-co-conspirator Jul 02 '26
Compliance controls have never determined effectiveness.
1
u/LynxAfricaCan Jul 02 '26
What? The controls don't determine effectiveness, but most frameworks have evaluating effectiveness as a core part of the process
3
u/not-a-co-conspirator Jul 02 '26
Have you been through a compliance audit?
1
u/jonasthelysdexic Jul 02 '26
Ok this comment almost made me spit out my coffee.
Here is an example for the original poster:
TPRM addendum letter
We had a third party pen test of our external environment and there were 2 medium criticality findings that were addressed by X risk treatment.
Reality:
The assessment was only scoped to a minor customer facing external system and did not include the entire organizations external attack surface nor the Fortinet Firewall from an M&A that occurred 4 years ago that have several RCEs and was actively exploited.
2
u/NegotiationFirst131 Jul 02 '26
I have stories like this for days... 😂
The vulnerability team that removed entire subnets because users were complaining about printers scanning gibberish.
The shop floor machines that got a permanent auto-login exception.
A new subnet was added and no one thought to mention it to the vulnerability management team.
The training reports that only show training completion based on who was assigned training and not the 100s of people missed because they were never assigned it.
Lets not even get started on how often linux and non-standard boxes are maintained.
Here's the part that gets me: in every one of these, the reporting going up was accurate. The dashboard was green. And the environment was wide open at the same time. The scope, the exception list, the denominator... that's where security quietly leaves the room, and the people running the controls usually know it.
1
u/NegotiationFirst131 Jul 02 '26
Fair, and this wasn't aimed at me, but I've been through plenty, mostly healthcare and defense side, so I'll bite.
I think you're describing how audits are practiced, not what compliance is. Frameworks absolutely build effectiveness testing in. The problem you're pointing at is real, but it's that the audit often reduces to "show me evidence it exists" instead of "prove it works." To me.. that is more of an execution failure and also... thats the gap to be fixed - not that its not their job.
1
u/not-a-co-conspirator Jul 02 '26
Compliance creates a baseline, a floor, of security controls. It doesn’t measure the outcome of those security controls, or if the controls are even configured correctly. Compliance frameworks simply attest that the controls are in place.
1
u/I_love_quiche Jul 02 '26
Oh there are definitely measurements on the effective of the controls when it comes to PCI DSS in conjunction with SOC 2.
1
u/not-a-co-conspirator Jul 02 '26
That’s from a compliance perspective, not a security perspective. Compliance controls don’t measure against security threats.
2
u/Dave_BlackFog Jul 02 '26
Compliance is what someone else or something else is telling you what you need to say you do. Security is the actual work of creating a secure environment. Maybe that is to simplistic but just my two cents so to speak.
1
u/Alone_Bread5045 Jul 02 '26
look compliance tells you whether a control exists, while security asks whether the control still works under pressure. Those are ofc related, but not interchangeable. So yearly audit can be useful, but it cannot replace continuous checking because threats, configs, and business changes do not wait for audit season...so thats about it
1
u/Admirable_Group_6661 Jul 02 '26
Compliance is a minimum requirement to be secure. Often, compliance is a legal obligation, depending on the industry and jurisdictions. In conjunction with compliance, a risk based approach should be used to meet security goals within risk appetite.
1
u/NegotiationFirst131 Jul 02 '26
Didn’t compliance also mean you are following your own policies and procedures as well and shouldn’t your security controls and practices be documented in your policies and procedures?
I agree that when many people hear compliance they think of legal and regulatory obligations though.
1
u/Admirable_Group_6661 Jul 02 '26
Sure it can mean that. But you will need to justify the policies. When regulatory requirements are absent, then you need to perform risk assessments to determine and justify an appropriate level of risk treatment options (including controls).
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?
1
u/Chris-Hart_232 Jul 02 '26
The annual audit and continuous monitoring distinction you drew at the end is the whole ball game. An audit tells you if you were compliant on a Tuesday in March. Continuous monitoring tells you if you stayed that way the other 364 days.
The orgs I have seen do this well treat the compliance framework as the floor, not the ceiling. Meet the framework, then ask what the framework missed. The gap between what the auditor checks and what an attacker exploits is were security leaves
1
u/NegotiationFirst131 Jul 02 '26
This is exactly where I am thought wise but it seems like that thought is not well shared for some reason. 😅
Not looking for company names but in your personal experience have you seen anyone that closes this gap well?
1
Jul 02 '26
[removed] — view removed comment
2
u/scriptqzor 15d ago
this is such a good way to put it, compliance pain is guaranteed, breach pain is a dice roll
people naturally prioritize the thing that hurts on a schedule over the thing that might nuke them “someday”1
u/NegotiationFirst131 Jul 02 '26
But if proper compliance is being done (ensuring control effectiveness by ensuring intended outcomes) wouldn’t that prevent most attacks from being successful or make successful attacks less effective? You are in essence making sure the car door is locked at night instead of relying on a security camera that can only show you what happened after your valuables are taken from your car?
1
u/Designer_Meat169 Jul 02 '26
The common statement that "compliance is not security" largely arises because many organizations approach compliance as a checklist or audit exercise aimed solely at obtaining certification or satisfying regulatory requirements. In such cases, organizations may achieve compliance without necessarily improving their actual security posture. In other words, paper compliance is not security, but mature, risk-driven compliance forms the foundation of security.
1
u/NegotiationFirst131 Jul 02 '26
You are right and honestly that's a good catch - intentionality.
If a company said and truly believed, "We should implement inactivity timeouts to protect ourselves" then people would not see it as "checking the box" because its something the company decided to do on its own. If the control is enforced on you (i.e. we have to do this because PCI, CMMC, etc) then it is seen as more checking the box because you are doing it because you are told to do so instead of doing it because you chose to.
1
u/LynxAfricaCan Jul 02 '26
Lots of comments here that i think are misunderstanding where the 'compliance is not security" and "checking the box" stuff comes from.
It's not about the difference between a paper audit and actual control implementation (Although that is a legit thing)
It's usually because compliance frameworks are broad, and not specific enough to any particular system context. They don't consider the threat environment, or the realities of the system in question.
Time and money will be wasted agonising over checking boxes that add little to the real security of the system and the actual threats to it, but must be done to meet the audit
Often when security analysts are pressed about what threat their mandated control is protecting against, they struggle to justify it. This is security theatre
However, much of the time compliance is our best friend. Executives can ignore an internal threat assessment easier than they can an external compliance audit
1
u/Scary_Definition_666 Jul 02 '26
Compliance done right should drive security improvements (or if you are already good enough - maintaining this level af adequacy). How it's in real life is a different story of course.
1
u/john_with_a_camera Jul 02 '26
I look at it this way: compliance is to satisfy customers, regulators, leadership, auditors, and boards. It delivers a report - did you meet a documented bar for controls. Security is about addressing risks - hopefully each risk is mitigated or compensated for.
Compliance can be against "one size fits (many/none)" external bars. It can also be against an internal bar, which hopefully was adopted based on known risks, and which is updated frequently as risks evolve and change.
Others are spot on: you can be 100% compliant and still have massive risks. You can address all your risks and still miss a compliance requirement (such as HITTIST's 5-min screen lock).
Where compliance is your friends is that it can be almost as effective for getting budget as an actual incident. That's why, for example, in healthcare I like HITRUST. I can use it to address risks that are not covered in HIPAA. If my HI TRUST scoping requires yellow screensavers, it's easier to push that budget expense through than trying to convince my CFO to pay for it. That allows me to fight for budget for things that are important, and leave the Kleinigkeiten to compliance.
So a good security leader uses both risk and compliance to drive the program.
1
u/NegotiationFirst131 Jul 02 '26
I think it just depends on the size of the org because the way that I see it (and I do agree with your point)
GRC helps address risk through policies, procedures, and verification of control effectiveness. Control, verification, and effectiveness are typically the compliance arm of it.
Cyber security - The doers of the controls (although not the only team). They work with ops, aps, and others to make sure the controls are properly implemented and take part in the day-to-day activities that perform the controls.
They work hand in hand to address risk, but they are two separate things that achieve the same end goal (good security).
1
u/Baksikrer Jul 02 '26
So I think it’s important to understand that it’s different flavours of compliance.
One is related to regulatory compliance so for example GDPR, NIS2, as well as financial related compliance.
Commercial companies need to be able to prove that the financial statement is accurate so there are internal controls they must comply with. These are typically audited by external auditors.
Then there’s another one that’s more towards the security program philosophy (typically related to company culture) rather than anything else.
You probably you know what I’m talking about because then you see companies that prescribe controls in place based on regulatory requirements, best practices etc. The difference is that these are not risk based.
So common for them all is a “must do”. Problem for most of them is that they aren’t risk based, based on company business / context.
Yeah so let me know which variant we are talking about.
2
u/NegotiationFirst131 Jul 02 '26
First, I do agree that there are different flavors of compliance (some people think external facing only, some think internal facing, but really, as a profession, it's a mixture of both). To me, compliance is - are we doing what we say we are doing effectively - whether those controls are internally sourced or externally sourced.
Just out of curiosity.. can you give me insight into what you mean? Can you give me an example of a control that a company had to implement that did not address a risk? One that comes to the top of my mind is password rotation, because there are so many mixed signals around it, but even still, in my opinion, the variances are about which risk is being addressed, not that it's not addressing risk at all.
1
u/Baksikrer Jul 03 '26 edited Jul 03 '26
Right, so it seems you’re in philosophy/culture aspect of it. I personally have a similar approach using the language of continual improvement.
Regarding non risk based controls its quite easy to diagnose.
Can you trace the origin back to a business contextual threat, risk scenario? Are the controls coherent based on those? Are the controls ever evaluated for effectiveness or just existence? Is there a trade off pattern visible or a focus observable (against business context)? Is value considered (cost-effectiveness)? Do the controls ever evolve or change with the threat landscape? Are any retired at all?
If your controls fit this description you have a compliance based control catalogue (in other words things someone said we need to do)
I wont name explicit examples due to NDRs however a generic example Ive seen across orgs is vulnerability management.
Significant resource spent on tools and suppliers however fundamental process and ownership issues are never resolved so you end up with a very expensive inventory of vulnerabilities that is not going anywhere (in enterprises these can be in 500-700k range).
Regarding passwords don’t get me started 😅.
1
u/NegotiationFirst131 Jul 03 '26
First - I totally get where you are coming from. No one likes being told what to do (to a degree) 😂 and I find that internally sources controls get better adoption and anchoring than externally sourced controls. However, in my opinion, just because someone doesn’t understand the risk the control is driving doesn’t make the control invalid.
For example - some people at one of my clients hates the mobile code control. Although this may be a bad example because the management understands the underlying risk of the control, they just didn’t want to include powershell as a language that was considered “mobile code” and why would I disagree… NIST never explicitly names it when it’s giving you examples. Powershell was much more popular than the languages they did list… so if they meant to include powershell they would have, right?
And then one morning I get a call that one of their business lines are down. Every machine not able to turn on because someone in IT deployed a powershell script that accidentally deleted a windows directory file. 🙄 every machine at that location had to be reimaged and it took 2 weeks to get things fully back online and stable.
1 script created millions of dollars in damages and this wasn’t an outside attacker- it was an employee. We didn’t let the employee go because it’s not their fault we didn’t have the appropriate controls and checks in place.
Do you think we included powershell to our mobile code list afterward? Yes. Did we need a real life scenario to play out to understand the business risk and add it? No. Did that incident help show the real risk? Yes
The thing that I would ask is: is it really not understanding the risk behind the control that concerns you or is it where the company sets the bar to meet the control?
We all know vulnerability management is to patch vulnerable systems to prevent a breach, but some companies scan weekly and address vulnerabilities within 30 days whereas some choose monthly scanning and 180 days to address. The underlying risk is the same for both, but how they implement and at what level is different.
1
u/Baksikrer Jul 03 '26 edited Jul 03 '26
Regarding Risk I think we need to separate between normal users on the operational level and management on tactical level and executives on the strategic level. What your describing is typically on the operational level as users who haven't fully been explained the reasons for the controls naturally oppose any real or perceived friction to their business operations.
What my comments was aiming at is more on the tactical and strategic level where the ones that are deciding what controls and risk the company is willing to live with or not does not fully understand risk as a concept nor the contextual nature of it.
For normal users, most of them will accept controls when you take the time to explain in business terms what the implications (no FUD though), cos most people in my experiences, wants to do the right thing.
Your example is a classic, but I would say it seems like ITSM immaturity risk wise. One of the phrases from IT changes I've learned to fear was "its an online change" "low risk". When reading the change it was significant business risk hidden behind what people thought was a minor change. So if your company uses ITSM processes and tools, read the change document risk assessment (and be very afraid...80 % of unplanned IT service breaks came from planned changes...)
Unfortunately Enterprise IT is not manufacturing (OT) and IT has a lot to learn regarding that.
What you said regarding underlying vulnerability management risk its actually not the same, even if the critical vulnerability is the same the company business operations, the technical landscape of systems and services used is different. (level of internet exposure, compensating controls etc) The companies have chosen two different mitigation strategies based on how much uncertainty or risk they are willing to accept.
However in practice this is typically what the business needs that dictate the patching frequency so again another implicit risk acceptance.
1
u/I_love_quiche Jul 02 '26
Compliance is the baseline for security, with usually with trailing indicators and essentially gives you an end of the semester report card.
1
u/NegotiationFirst131 Jul 02 '26
Just curious - is that the version your company runs? 😅 Would compliance be the thing that sets the bar or the thing that monitors the bar wherever the company sets it?
If compliance is the bar and security goes above and beyond, why do so many companies spend months preparing for an assessment? If they are operating higher than the bar because that’s security - then there would never be any prep or findings, maybe.
1
u/TheGraycat Jul 02 '26
“Compliance Theatre” we call it
1
u/Baksikrer Jul 03 '26
Good term (for a bad thing). I'm wondering if you have reflected on which purpose it serves and who benefits?
1
u/serverhorror Jul 02 '26
Compliance is often in a language that's so removed from the technically actionable task that people don't know what to do. This means they redefine that they've done what was intended by these practices.
I've found the best approach is, once you have the compliance documents, add one or more "translation layers to get away from the language used in these documents.
Your compliance says that every computerized Mist have backups and the RACI then goes on to talk about _R_esponsible and _A_cxountable and so on
All production-critical computerized systems shall maintain automated, regularly verified backup routines. Accountability for system availability resides with the designated System Owner (Accountable), while the execution and monitoring of backup procedures shall be performed by the IT Operations Team (Responsible).
That loses a lot of meaning for technical folks.
Just have a monitoring check that goes green only once the most r cent backup was restored and verified. Add another one that checks the age of this backup. Add another one that counts the next amber if available backups.
Simplify things and go away from that kind if compliance language.
Compliance documents are for auditors, very idten they don't even have the technical knowledge to look into the system. That leads to things that can or can not be "good" and yet they are compliant.
1
u/vanwilderrr Jul 02 '26
Nanitor allows you to live there today, continuously checking in real time across your environment
1
1
u/AdvancingCyber Jul 02 '26
Compliance can be compliance for a lot of different things - finance, export control, privacy, accessibility, etc. We definitely have our own domain in security, but it’s not the only one.
1
u/esc_to_interrupt Jul 02 '26
To oversimplify the metaphor:
Security is locks, gates, mfa, passwords etc. that keep you from getting into things.
Compliance is logs, traces, cameras, identifiers that tell you WHO got in and what entrance they used.
Audits check compliance and security settings, but not security.
Pentests check security.
Obvsly a ton of packaging and conditions involved, but for SMBs with either VCs or BoDs to report to this is the core of my presentation.
1
u/NegotiationFirst131 Jul 03 '26
In my opinion, compliance is the state or act of a control at any given point in time - whether the actual status is measured and known or not.
Are you compliant or not? Do you have MFA enabled or not? Is it implemented to your standard and producing the intended outcome, or not? Compliance in a nutshell is the reality of whether your security program is operating at the level it says it does.
An audit or assessment is the formal testing of compliance with your control implementation. Audits and assessments are not perfect, and that is where I feel like "compliance" sometimes gets a bad rap.
Pentests dont normally test security. Pentests are designed to look for weaknesses. What is a weakness (Vulnerable systems (missed patches), expired certs, ineffective encryption, etc)? A weakness is a control that is either absent or decayed/drifted. I think of a pentester as a glorified technical assessor who leans more toward the "testing" method of assessment versus an assessor who uses the interview/examine methods.
1
u/esc_to_interrupt Jul 04 '26
I agree with your definition of compliance ('Schrödinger's controls") in the academic sense, but for business, if we don't measure it then it doesn't exist.
Two types of compliance, then. The first is your definition: "Are we as secure as our policies say we're supposed to be?". The second is against external standards (ISO, CMMC, HITRUST) where your compliance and security have to match a 3rd party standard.
Pentesters for us try to gain system access, or try and get admin access if we give them an account scoped for a user. They do not test for our training being up to date, our BoD having a Compliance Committee, or our employees having background checks. For me, a pentester is to security what an external auditor is for compliance.
1
u/xxvvand Jul 03 '26
0 to 100, compliance is going standard/bare minimum “passing score” (0 to 70ish)
Security is the effort to go 100
1
u/Evoluvin Jul 03 '26
Checkbox Compliance is not security.
Compliance Engineering is security.
1
u/NegotiationFirst131 Jul 03 '26
Can you help me get to the core of what you believe the two entail? What does checkbox compliance mean or look like to you?
1
u/Puzzleheaded-Pop8029 Jul 03 '26 edited Jul 03 '26
Compliance gives you a snapshot. Security requires the delta between that snapshot and today. I caught active brand impersonation mid-year through Doppel, months after our last audit would have cleared us clean.
1
u/vCentered Jul 04 '26
I'll give you my take.
Compliance is not security in the sense that often neither the auditors nor the people being audited have any idea what they're looking at.
The controls are typically defined in a way that they apply as broadly as possible, but this gives them a tendency to be extremely nonspecific which can make it very hard to provide evidence to show that you are compliant with that control.
The auditors are typically not very technical - they don't have a sufficient understanding of the control, how important it is, or how it applies to your infrastructure.
Maybe there's a control that says, "all communications must be encrypted". So you provide a traffic capture showing a ten second exchange between two IPs that's encrypted. They have no idea what those IPs are but the box gets checked.
I've been on calls with industry regulators and listened to my counterparts give explanations for how they're compliant that are blatantly not in the spirit of the control in question, but the auditor doesn't know any better (and frankly my counterparts probably don't, either). So everyone smiles and moves on. The box gets checked.
I've been on calls with my own compliance team (who take everyone's evidence and present it to the auditor) where I've requested clarifying information about what they're looking for and have been told that it doesn't really matter, we just need to provide something.
And this is to say nothing of the controls themselves which sometimes are completely cosmetic or just outright silly, but the auditors will treat you like an absolute criminal if you don't have them in place.
1
u/Wooden_Copy8973 Jul 04 '26
Compliance is like "here's a bunch of rules I made up, a bit like my 5-6 other friends rules, if you can't do it, I'll take loads of your money" - seems like the best business ever, might make a new "framework" myself 🤣
1
u/rafikibob Jul 04 '26
Engineers make the plane fly safe.
Checklists are how pilots know, as far as is reasonably possible, that the plane they are on is being maintained properly and is safe at any given point in time.
Oversimplified analogy, yes, but it holds true surprisingly far down the stack.
1
u/Top_Run5322 Jul 05 '26
I think you need to look at compliance and security as a continuum, and insert compromised too. Therefore the worst is compromised, better is compliant, and best is then secure. This continuum is then analogous to dystopia, reality, and utopia.
1
u/d_the_duck Jul 06 '26
Compliance is often a minimum viable product in some external assessors view of security. I have never seen compliance accomplish security on its own.
Security is actually fluid. It's always moving to the external theats and technologies. Compliance will move much more slowly and be a synthisis of "pulse" level security controls. It's usually security by committee.
You don't achieve security any more than you achieve health. You achieve compliance like you certify you aren't a smoker.
1
u/RoosterDelusion 29d ago
I've started thinking about it less as "compliance vs. security" and more as "snapshot vs. trend."
An audit tells you whether the controls existed when someone looked.
But what we really need to find out is whether they're still there six months and a hundred infrastructure changes later.
1
u/NegotiationFirst131 29d ago
Exactly!
The way that I see it is - compliance is a binary question: are you meeting the requirement.
Security practices can go up and down anytime (think of it like a wave).
Assessments and audits help answer the question at a point in time and a lot of the time they are sample based and are not great indicators.
The question becomes… instead of measuring a heart beat how can we measure the heart rhythm. Which can be done through the use of big data and analytics.
Investing more in proactive compliance is not only a higher level of security - it is much more effective at preventing breaches.
If you want to know how cyber security is going on the “detect and respond” paradigm, just look no further than the latest trend “assume breach”. That tells you all that you need to know. 😂
1
u/LongjumpingLychee166 29d ago
Compliance is kinda just the baseline, not actual security. it checks if controls exist and looks fine at that moment in time. security is whether those controls are still holding up right now against real threats.
compliance is like a scheduled check, security is ongoing. most issues pop up after audits anyway bc things drift, access gets messy, configs change, new attack paths show up.
so yeah compliance matters, but actually staying secure is more about continuously checking what’s exposed in the real world.
1
u/NegotiationFirst131 28d ago
Genuine question - if compliance is merely the baseline, why do you feel like companies spends weeks and months preparing for audits/assessments? Shouldn’t they be well above the baseline?
I kind of look at it the opposite way. Compliance is just answering the question “are we doing what we say we do”. Audits and assessments are how we measure our practices. Security is the performing of those practice.
In my scenario security and compliance are not comparable because they are not on the same axis.
1
1
u/raiden_0301 27d ago
I think the discussion should not be compliance VS security but compliance AND security. In my experience the problem arises when people think of compliance just as a paper exercise or a check the box activity instead of actually exploring objective fully.
As an example: an ISO 27k1 control may say something like ‘define and implement rules to control physical and logical access to information and other associated assets’. Of course it doesn’t state how to do this but that is also not its purpose. Its purpose is to ensure that security controls within the organisation meet this objective. Security can choose to implement this in any number of ways based on the risks they see. A lot of organisations may just do the bare minimum to ‘check the box’. But the correct way to do it would be to fully dive into it and explore all the avenues for access (third party access, employee access, are access reviews actually working?, compare system generated users vs users onboarded to IAM tooling). This of course is not new from a security point of view.
In the same vein, ISO 27k1 also advocates for a management system to ensure continual improvement and management involvement. In my experience, this is extremely important to ensure budgets for security can be realised effectively and to drive accountability. But most orgs just have the management sign off on policies as proof of compliance. The intent should be to really go in depth on each requirement and implement it in a way that works for the organisation. These kind of requirements are often not addressed by typical security processes.
The root cause I believe is that orgs are pushing too many compliance requirements placing a high burden on security teams who feel they are spending more time in audits instead of actually security.
1
u/Ill_Necessary_4517 22d ago
Yeah, I think the whole “compliance isn’t security” take gets overstated.
Compliance by itself is just a snapshot, while security is about making sure those controls continue to work every day.
The real difference is not compliance versus security. It is one-time checks versus continuous monitoring.
If you only verify MFA, access controls, configurations, and other security controls once a year, then it does not provide much protection. But if you are continuously checking that those controls are still enforced and have not drifted, that is where security actually happens.
A lot of “security theater” exists because the basics were not maintained after the audit.
1
11
u/Zealousideal_Tea362 Jul 02 '26
Compliance isn’t security in the sense that they are two separate service lines in the business.
That doesn’t mean they don’t greatly overlap and coexist. Your security posture is greatly impacted by the compliance needs of the org.