Why is everyone selling Compliance?

Dissecting Security Sales Call

---

Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer.

---

Sales guy: “Hey there! I've been looking at your company, and I think we could really help streamline your compliance journey. We are runtime protection platform for your workloads. Our platform has an amazing track record with SOC 2, PCI DSS, HIPAA - we've never had a client fail an audit!”
Me: “That's interesting - compliance is definitely important for us. But I'm curious about the actual security aspects. How does your solution help protect our applications? Are you agentless or will be deploy agents?”
Sales guy: “We are definitely agentless, but the most valuable part is we have a comprehensive control mapping system. Everything's organized in easy-to-follow checklists. Your auditors will be impressed with how well-documented everything is. Plus, it gives your customers confidence that you're secure!”
Me: “I get the documentation part, but what about actual security features?”
Sales guy: “Happy to jump on a call and demo you. I can invite the technical folks”

At that point it was pretty clear the conversation would be revolving around compliance. This snippet captures a scenario we run into all the time. It's interesting to see how the security vendor landscape has evolved. I've noticed a pattern where many solutions now lead with compliance. And let's be honest—compliance is a major driver in security spending. Yet, from a practitioner's standpoint, I keep thinking: "Are we focusing on the wrong part of the story here?"

I decided to run an interesting experiment last week. Instead of dodging those endless sales calls, I actually started picking them up. Results were Ironic. In just one week, I had conversations with more than a dozen security vendors - we're talking the full spectrum here: SOC automation platforms, penetration testing services, SAST tools, NHI security... you name it.

I had two main goals: First, I wanted to dissect their elevator pitches - you know, see how they're positioning their solutions. But more importantly, I was curious about how they all got my contact info in the first place.

Turns out, it's exactly what I suspected. Our information was being passed around through platforms like Zoominfo, Apollo.io, and Seamless.ai. The irony isn't lost on me - here are companies selling security solutions, but they're perfectly fine getting their leads from platforms that play pretty loose with privacy and user consent. It really makes you think about the state of our industry when privacy-invasive data brokers are powering the sales engines for security companies.

Back to our first point - elevator pitch - almost every vendor led with compliance, not security. ‘Guaranteed PCI DSS compliance!’ It was always about checking boxes and passing audits. The pattern was clear: they're selling peace of mind through paperwork.

Compliance Sales Pitch

Before we get critical, let’s be fair. Regulatory frameworks like SOC 2, PCI DSS, HIPAA, GDPR, and other international or industry-specific standards do serve a purpose. Many of these guidelines arose out of frequent, real security breaches. They aim to protect sensitive information, enforce basic best practices, and create accountability. The concept is solid: if an organization has compliance requirements, that same organization will typically allocate budget, time, and people to ensure it meets those mandates.

For many security leaders, compliance is a lifeline for budget. Executive and board-level stakeholders often don’t open up the cheque book unless they see regulatory or contractual obligations that absolutely must be addressed. So, in that sense, compliance’s ability to secure a budget is a net positive. Without it, many security teams might never get the funds they need to deploy new tools, train staff, or build fancy dashboards.

Here's what's interesting: many of these tools that we use actually have solid security capabilities. They can detect threats, and provide valuable security insights. But for some reason, their sales pitch leads with compliance every single time.

Take that runtime security platform. It probably has sophisticated capabilities for detecting abnormal behavior, probably go deep into ebpf to perform some runtime SCA. But instead of showcasing these features, the sales pitch revolves around checking PCI boxes and making audits easier.

Why does this happen? Because compliance sells.

Compliance is a guaranteed pain point. Every organization needs to meet regulatory requirements, and executives understand the concrete risk of failing an audit. It's an easy conversation to have with decision-makers: "Buy our tool, pass your audit."

The Tension Between “Checklists” and Actual Security

If you’ve been in security long enough, you’re probably aware of a timeless tension: compliance says ‘do X’, while actual security asks ‘are we protected against the risk of Y?’. The difference between the two is that compliance might not require the nuance, creativity, or depth needed to address evolving attacks. It often gives you a list of controls: implement strong passwords, deploy a firewall, monitor your logs, etc. However, it doesn’t necessarily demand you investigate how advanced attackers might bypass these controls—or how quickly you can spot them if they do. For instance consider this:

1. Vulnerability Scanning vs Patching:

   A compliance framework may say, “Conduct regular vulnerability scans.” That’s good as a baseline. But does it actually solve the real challenge of analyzing and patching vulnerabilities in a timely manner across your cloud infrastructure, container images, or on-prem workloads? The only thing that compliance requires is the “documented” SLAs around it.

2. Logging and Alerting
   Many regulations require that security-relevant events be logged and retained (e.g., for 90 days, 1 year, etc.), and that alerts be generated for suspicious activity. A compliance-oriented logging tool might offer a one-size-fits-all logging platform that keeps a record of events, thus checking the “logging” box. However, if it doesn’t perform meaningful correlation, real-time anomaly detection, or even alerting (yeah, they exist), it provides only superficial coverage. You end up with thousands of log entries that satisfy an audit trail but do little to help a security analyst quickly isolate or respond to intrusions.

Why Vendors Push the “Compliance Card”

It’s tempting to vilify vendors, but the root problem is that compliance—and the fear of being non-compliant—sells. Business leaders fear fines, legal action, or losing customers if an audit fails. So, it’s easier for a salesperson to say, “Buy our solution and you’ll pass SOC 2!” than it is to discuss more complex architectural changes that truly reduce risk.

Additionally, compliance frameworks act as a common denominator that everyone in the market recognizes. They represent a clear, universal pain point: if you're a vendor, it’s often simpler to align with these frameworks than to explain the myriad of specialized security challenges out there. After all, as the saying goes, “Sell the pain-killer, not the vitamins.” In most organizations, the 'pain'—and thus the immediate need—is getting compliance to drive sales. This dynamic can push deeper security considerations to the sidelines, overshadowed by the checklist-driven demands of compliance.

Image src - https://shorturl.at/ntq2v

“Fear, Uncertainty, and Doubt (FUD)” also plays a role. The pitch often goes: “If you don’t address these compliance gaps, you’re at risk of failing your next audit or incurring heavy fines.” That can be enough to secure a sale, even if the actual improvement in security posture is minimal.

The Baseline Value of Compliance

Don’t get me wrong—compliance is still necessary. I respect it, every single control. It does force organizations to establish minimum security hygiene. Some ways compliance actually helps:

• Executive Commitment and Accountability:
  When leadership signs off on meeting frameworks like SOC 2 or ISO 27001, there’s an official recognition that security is part of the business. That accountability can help drive cultural shifts toward better security practices.

• Documentation and Repeatability:
  Compliance is all about documentation. It typically demands policies, procedures, and evidence of consistency. For instance, you might be required to show incident response runbooks. This documentation encourages a more disciplined approach to security operations.

• Baseline Controls:
  Compliance frameworks bring organizations up to a basic level: using MFA (Multi-Factor Authentication), encrypting data at rest, restricting admin privileges, etc. Even if we security engineers consider these fundamental, many organizations might not implement them unless compelled by compliance.

• Budget Justification:
  Perhaps the biggest advantage is the ability to secure budget, as mentioned before. When a CFO sees that compliance must be addressed to avoid regulatory fines or lost business, they’ll approve the necessary expenditure. That can pave the way for subsequent investments in more advanced security measures.

Now as the list continues, over time, its hard to justify or show proof for the investments made for security improvements which is beyond compliance and the leadership often expect security investments to produce a clear-cut ROI, much like any other business expenditure. This creates a tension: security teams can’t promise zero breaches, yet they’re asked to justify every dollar spent. As mentioned by Ross Halleliuk in his post -

The amount of infrastructure that needs to be protected is enormous, and it’s practically impossible to get everything right. Something will be missed, something will be forgotten, and something will fail, leading to a security breach. This reality doesn’t spark a lot of confidence from executives who are used to getting a clear answer about the return on investment (ROI) of every business investment.

— Ross Halleliuk

The reality is that security investments function more like an insurance policy or risk mitigation strategy than a straightforward “profit center.”

The Impact on Security Discussions

This compliance-first messaging creates some interesting challenges in security discussions:

When I talk to executives from different companies about a new security problem or a tool, they immediately ask about what are its compliance benefits because that's what vendors have been pitching this to them. The actual security improvements become secondary in the conversation.

During product evaluations or renewal of existing tools, we spend too much time discussing compliance required tools or reporting features and not enough time analyzing threat detection capabilities or incident response workflows to understand how quickly, some tool will be helpful at the time of crisis, not just for ticking compliance checkboxes. I divide the security tools into 3 specific categories -

1. Compliance-Focused Tools
   Compliance-focused tools are designed first and foremost to help companies adhere to specific regulatory frameworks such as GDPR, HIPAA, or PCI-DSS. They typically come with comprehensive reporting, automated checks, and streamlined dashboards for managing policies across an organization. By generating evidence and logs that demonstrate alignment with standards, these tools make the audit process far less painful. For instance, platforms like Vanta or Drata automate much of the SOC 2 or ISO 27001 evidence collection, while vulnerability scanners like Nessus include compliance checks for vulnerability scanning against various benchmarks. The real value here is in highlighting security gaps that, if left unaddressed, might lead to genuine risks. Even if the immediate goal is to pass an audit, these tools can offer insight into areas where security practices must be strengthened.

2. Security-Specific Threat-Focused Tools
   In contrast, security-specific threat-focused solutions dig deep into identifying and mitigating active threats. They are often categorized as “We’ll buy this after we pass SOC2” tools. The emphasis here is on real-time detection, threat intelligence, and rapid incident response. Tools like CrowdStrike Falcon or SentinelOne use advanced endpoint detection and response (EDR) to catch suspicious behavior before it escalates. SIEM platforms such as Splunk or Elastic Security aggregate and correlate logs from across your environment, making it easier to spot stealthy attacks. AI-driven tools, like Darktrace (many others now), learn your network’s “normal” patterns and alert you when anomalies occur. While these solutions might include features that help with compliance, their real strength is in actively defending against evolving threats. This proactive stance is vital for organizations that need a robust shield against cyberattacks, rather than a simple checklist for regulators.

3. Operation & Automation-Focused Tools
   Finally, as infrastructures become more complex and distributed, the need for streamlined operations and automation has grown exponentially. Operation and automation-focused tools aim to reduce manual tasks, centralize security oversight, and maintain efficiency as your environment scales. Security Orchestration, Automation, and Response (SOAR) platforms like Palo Alto Networks Cortex XSOAR or Splunk Phantom enable coordinated responses across multiple systems—think automated playbooks that isolate infected hosts or block malicious IP addresses within seconds. Other automation solutions, like Ansible, can be extended to handle security policy updates and configuration management, ensuring consistent enforcement across thousands of endpoints. By taking repetitive tasks out of human hands, these tools decrease the likelihood of errors, speed up response times, and free security teams to focus on strategic priorities.

Ultimately, understanding where a solution falls in these categories—and educating decision-makers on each type’s true value—can lead to more balanced security conversations. Rather than letting compliance overshadow the broader security picture.

Value Beyond Compliance

Let’s pause the critique for a moment. Not all vendors are created equal. Some do build tools that solve genuine security challenges—detecting novel threats, stopping zero-day exploits, or automating incident response. But even these vendors often bury their best features under layers of compliance jargon. Why? Because they’ve learned the hard truth: compliance opens doors.

Take runtime application security platforms, for example. Many leverage eBPF (extended Berkeley Packet Filter) to monitor system calls in real time, detect malicious behavior, and block exploits before they escalate. But they might pitch on CIS benchmarks.

SCA tools exist to solve a critical, modern problem: supply chain vulnerabilities. They analyze dependencies in the codebase, flagging outdated libraries, risky open-source components. In an era where 80% of codebases are built on third-party components, SCA isn’t just useful – it’s essential. We get it. But selling it for legal and compliance purposes is not fair to the technology thats behind it. Thats not wrong — but its like selling Ferrari because it has great cupholders.

The Role of Regulatory Bodies in the Compliance-First Mentality

It’s not just vendors who push compliance to the forefront—regulatory bodies have their own part to play in making compliance such a hot commodity. When agencies like PCI DSS, the European Commission (GDPR), or healthcare regulators (HIPAA) create frameworks and standards, organizations have little choice but to meet those rules to avoid hefty fines or losing the ability to do business. Many compliance frameworks lay out broad security controls—for instance, requiring the use of “firewalls,” “secure configurations,” or “access controls.” While these statements aim to future-proof the guidelines, they often lack specificity on how to implement these controls in today’s complex environments. This gap leaves room for interpretation by auditors who might be unfamiliar with modern cloud setup. As a result, compliance assessments can devolve into a check-the-box exercise where the true effectiveness of a security control isn’t rigorously validated.

Consider how PCI DSS 4.0 addresses segmentation and monitoring in cloud-native architectures. In principle, the standard calls for isolating sensitive systems and logging access. However, many DevOps teams now rely on ephemeral containers that spin up and down rapidly. The standard doesn’t explicitly cover ephemeral environments or ephemeral services.

• Interpretation Challenge: One auditor may insist that each container be treated as its own “system,” requiring log collection at the container level, weekly patch verification, and strict segmentation rules—mechanisms that can be extremely difficult in a DevOps pipeline. Another auditor may view containers simply as part of a broader microservice environment, logging only at the host level.

• Security Oversight: Neither approach fully addresses advanced threats specific to containerized workloads—like privilege escalation inside a container or misconfigurations in the underlying Kubernetes cluster. Even if the organization “passes” the PCI audit, the environment could remain vulnerable to a real lateral movement attack that pivots across containers.

Often, frameworks don’t capture rapidly evolving best practices—using eBPF-based runtime detection, or implementing zero-trust network policies for microservices. These techniques go well beyond “install a firewall,” yet they’re critical in defending against modern attacks. Because the frameworks are slow to update, organizations can end up doing the minimum spelled out by the regulation instead of truly securing their container or serverless environments.

What qualifies as “compliant” becomes subjective, hinging on an auditor’s individual knowledge of container security or cloud-native operations. An auditor might pass a setup that fulfills the letter of the standard—logging events, having some form of segmentation—yet the organization could still be exposed to attacks that exploit container misconfigurations, image vulnerabilities, or mismanaged secrets in a CI/CD workflow.

Regulators—and the compliance documents they publish—are frequently out of touch with the relentless pace of technological innovation. By offering only broad, outdated requirements that fail to address emerging paradigms they force organizations to rely on auditor interpretation rather than truly secure practices. The result? Plenty of companies “pass” audits while leaving gaping holes in their modern infrastructure—holes attackers can easily exploit. This requires regulatory bodies to step up, provide more implementation details and focus more on the outcomes of these security controls.

(Special thanks to Sergej Epp for the insightful discussion on how regulatory bodies shape compliance-focused security strategies.)

Some Straight Talk

If you are reading this, by the time you would have got the insight — Yes, compliance matters. It’s the floor beneath our feet—the minimum that keeps organizations from collapsing under the weight of negligence. But floors don’t stop hurricanes. Yes, it creates a baseline, and yes, it secures budgets. But an organization seeking genuine risk reduction must see compliance as one layer—NOT the entire security program. Compliance should be the natural outcome of the security practices.

Security is about understanding your systems, data, and threats, then layering defenses that adapt to evolving attack patterns. Compliance can be your guiding force in obtaining executive buy-in, but once you’ve got that buy-in, push further. Demand substance from vendors. Look for solutions that offer continuous visibility, threat intelligence, automated response capabilities, and integration with your overall security architecture.

There are great security products and amazing things for security. We know compliance is important, and we appreciate that the tools help with it. But please, can we talk about the actual security capabilities first, and then compliance?

Security—real security—is a layered, ongoing process. Compliance is just the entry ticket. Let’s not mistake it for the entire show.