Every year, we witness organizations with certifications and clean audit reports fall victim to security breaches. Vulnerability Scans? Check. Patch Management? Check. Encryption? Check. The list goes on; they checked every box in every one of their compliance frameworks, and yet, they were still breached. Compliance does not measure whether you are actually secure; it creates a dangerous illusion and a false sense of security.

One of the biggest issues with compliance-driven security is that the frameworks are largely static, or if they are evolving, it's damned slow. All the while, they are attempting to defend against dynamic, rapidly evolving threats. Most standards are updated reactively in response to major incidents or trends, rather than proactively, as new threats and attack vectors emerge. This lag creates opportunities for attackers who aren’t constrained by annual reviews or administrative processes.

Let’s face it: attackers don’t pause their campaigns while you undergo your latest audit or self-assessment, and zero-day vulnerabilities don’t wave a warning flag or wait for the next framework update. I know… shocking. 

We often say “assume breach,” which requires recognizing that nothing is immune to compromise and that, in turn, requires building an environment with prevention in mind. But it also requires the ability to detect and contain threats quickly, even when an adversary is present. We should also recognize that attacks are always happening and any connected system is constantly probed for potential weakness. 

Compliance does not prevent any of this, but rather documents that you followed the minimum guidelines set forth for whatever type of system or data you are protecting.

Compliance frameworks and audits are amazing at driving documentation creation. Meanwhile, security and engineering teams find themselves drowning in a sea of requirements, data, and findings from various scans, aiming to satisfy auditors, but not providing much actionable intelligence about real threats.

Debates ensue between the Compliance, Security, and Engineering teams on what to fix, if something even needs fixing, or how we can simply explain something away. New administrative processes get built, which increase overhead without mitigating much, if any, risk, but hey, it meets the compliance requirements so we can move on.

These situations can create a dangerous false sense of security and preparedness. Rather than focusing on implementing effective measures that maximize risk mitigation, teams focus on doing enough to meet the compliance requirement and move on. For areas like change control or access control, this can leave risks that lie dormant until a threat actor discovers the gap. A compliance requirement doesn’t call attention to that risk. A proper threat model would.

Having detailed documentation is great. But it’s important to focus on going beyond the intent of compliance controls, which is often to ensure at least some foundational safeguards are in place. This way, the aim is to effectively mitigate applicable risks rather than simply doing the bare minimum to satisfy the requirement language.

Compliance requirements often assume that humans are going to behave perfectly according to policy and their once-a-year security training. The requirements demand that we have policies, training, and change control processes, and if we do, we pass. The reality is, humans (even annually trained ones) are the biggest weakness!

Humans make mistakes and machines make mistakes because they got bad instructions from, you guessed it, humans! To be clear, I’m not advocating for the rise of the machines and the subjugation of the human race, but you get the point. These mistakes lead to misconfigurations or leaked or stolen credentials, which remain the leading causes of breaches.

The 2019 Capital One breach will forever be a reminder of this. Despite a regulated financial institution maintaining compliance, a single configuration error exposed over 100 million customer records. They checked all the boxes, passed all the audits, and aimed to do all the right things, but being compliant cannot prevent misconfigurations stemming from human error. This is just one high-profile example, but in almost every case, if there’s been a major breach, it involves a human element.

So how do we protect against human error? There is no one clear answer, and there are numerous measures that can be put in place to limit impact and contain threats. Continuous testing and monitoring, threat hunting, and practiced incident response are standouts here.

There is a common misconception that compliant means secure, which is obviously not the case. Most of the time, compliance confirms a control is met or implemented, but not necessarily that the control is effective. This is not true of every framework. FedRAMP and Australia’s InfoSec Registered Assessor’s Program (IRAP), which are some of the strictest standards only a small subset of organizations pursue, aim to also verify effectiveness, while most others still fall short.

Security teams are also forced to increasingly invest time and resources (which come at a premium) into administering compliance with so many frameworks to satisfy or provide evidence for. This can take away from making material improvements, leaving solutions half-baked, all in the name of simply checking the boxes rather than creating a fully fleshed-out, effective implementation to address a more comprehensive set of risks. The intent of most compliance requirements is great, but the reality is, they don’t always drive measurable reductions in risk. 

Worse, compliance drives the reactive approach. Teams deprioritize security work unless it's mandated by compliance requirements, making changes only when an auditor demands them. This means teams are responding to threats after they're present, sometimes for long periods of time, rather than preventing them before they emerge. 

A perfect example is vulnerability management. When a critical flaw is disclosed, security teams immediately generate tickets and push for remediation. But engineering and operations teams, already stretched thin and juggling conflicting priorities, often delay the work or pursue exceptions. The vulnerability lingers until someone points to a compliance requirement with a defined service-level agreement (SLA). Suddenly, the same issue that sat idle for weeks becomes a must-fix item in the current sprint, not because the risk increased, but because the checklist now requires it. 

Security, Engineering, and Operations teams must move beyond this approach and patch these issues in short order; not because compliance requires patching within a generous time frame, but because it’s crucial to protecting against very real, fast-moving threats.

The financial impact of checkbox security goes well beyond audit fees and compliance staff. Organizations routinely spend time and money implementing controls without asking whether those controls meaningfully improve their security posture. The result? They achieve a compliant status while quietly accumulating gaps, misaligned priorities, or worse, dangerous blind spots.

Security teams, on the other hand, are trained to hunt actual weaknesses in an environment that changes daily. They track critical systems, emerging threats, and a constant stream of vulnerabilities, undocumented assets, and configuration drift, often in sprawling, overly complex infrastructures. But while they sift through this noise, compliance frameworks insist on uniform standards that rarely match an organization’s unique risk landscape. What truly matters can get buried under the pressure to simply “pass the audit.”

Real security means understanding which vulnerabilities pose genuine threats to your environment, not just proving you can run scans and provide point-in-time evidence that you met control language. 

To be clear, compliance is not the enemy. It provides a baseline, ensures basic hygiene, and creates accountability. The problem arises when organizations treat it as the destination rather than the starting point.

Compliance is the minimum bar. True security requires going above and beyond those requirements with context-aware decisions tailored to your specific needs and environment. It demands continuous monitoring and evolution, not annual assessments. It needs a security culture where teams do things securely because it's the right thing to do, not because it makes them compliant.

So how do we build secure systems and organizations that are also compliant? By inverting the priority:

• Start with risk. Identify your actual threats, your critical assets, and your realistic attack surfaces. Let risk drive your security investments, and let compliance follow.
• Monitor continuously. Security isn't a point-in-time achievement. Implement continuous monitoring and validation of controls, not just during audit season.
• Prevent proactively. Hunt for threats before they find you. Challenge assumptions about what's protected. Continuously assess for risk, carry out penetration tests, and do some red teaming.
• Build a security culture. Make security everyone's responsibility, not just the compliance team's problem. When people understand why security matters and not just that the auditor requires it, they make better decisions. 

Compliance will always have its place in security programs. But when we let it drive our strategy, we get checkbox security: documented, auditable, and fundamentally inadequate against real threats.

This article is a guest contribution from Kurt Hendle. 

If you’d like to share your perspective or submit your own story, reach out to us through our contact form. We’re always looking for sharp voices with insights to share. 
 

1. Cloud Security Alliance Top Threats to Cloud Computing 2025
2. Verizon Data Breach Investigation Report 2025
3. Fidelis Security: Understanding the Role of Misconfigurations in Data Breaches in Cloud Environments