Passing a compliance audit is important, but it doesn't necessarily mean you're secure. One of the most common things I see when assessing companies is that the issue isn't a lack of security investment. In many cases, they've bought the right tools, written the policies, implemented MFA, deployed endpoint security, configured backups, and completed the audit. On paper, the program looks good. The problem starts when you look at how those controls are actually being operated day to day.
This is where compliance becomes security theater: the appearance of protection without proof it's still working. The control exists, there's documentation supporting it, and someone was able to provide evidence to an auditor. But that doesn't necessarily tell you whether the control is working today. Compliance frameworks are useful because they establish what should exist. What they can't tell you on their own is whether those controls remain effective as the environment changes.
Pass the Audit, Fail the Pentest
An audit and a penetration test are answering two different questions. A company can score well on one and still fail the other — and both results can be accurate at the same time.
What an Audit Checks
"Does the control exist, and can you prove it?"
- Required controls are documented
- Evidence exists for each control (screenshots, logs, tickets, policies)
- Controls were in place during the review period
- Policies are written and formally approved
What a Pentest Checks
"Can I get in, move around, and reach something that matters?"
- Whether documented controls actually stop an attacker
- Gaps between systems that individually "pass"
- Privilege escalation and lateral movement paths
- Whether small, unrelated weaknesses can be chained together
Having the Control Isn't the Same as Testing It
Backups are probably the easiest example. Most companies I assess have backups, and many can show successful backup jobs. The more important question is when they last restored something and proved they could recover. I've seen organizations where everyone assumed backups were working because the dashboard was green, but very little recovery testing had actually been done. You don't want to find out during an incident that the backup you thought you had can't restore the system you need.
The same pattern shows up across the security stack. MFA may be enabled but not consistently enforced across every application. EDR may be deployed but have systems that haven't checked in for months. A vulnerability management platform may be scanning the environment, but nobody owns remediation. A SIEM may be collecting logs, but important systems were never onboarded or alerts aren't being reviewed consistently.
This is especially common with security tools. Companies spend a lot of money buying technology and understandably feel like they've addressed the risk once it's deployed. But buying the tool isn't the same as operating the control. Someone still has to configure it, maintain it, monitor it, respond to it, and periodically test whether it's working. Across assessments, this is one of the biggest gaps I see — the technology is there, but the operational discipline around it isn't. This is exactly the gap our Security-as-a-Service model is built to close — ongoing ownership of the controls you already bought, not another tool to manage.
Compliance Debt Builds Over Time
I think of another part of this problem as Compliance Debt. A control can be completely accurate when it is tested during an audit, but the environment doesn't stop changing once the audit is over. New employees join, applications get deployed, cloud configurations change, acquisitions happen, exceptions are made, and security tools get modified. Six or twelve months later, the documentation may still describe a compliant control even though the environment no longer matches what was originally assessed.
I've seen this happen in completely normal ways. A company rolls out MFA and considers the project complete, then adds several SaaS applications that aren't integrated with SSO. An EDR deployment starts with nearly complete coverage, but laptops get replaced and servers get added until coverage starts slipping. A vulnerability scan identifies an issue, a ticket gets created, and months later it's still open because nobody was accountable for getting it fixed. Backups run successfully every night, but a newly deployed application was never added to the recovery plan.
None of these are unusual failures. They're what happens when security controls are implemented as projects instead of operated as part of an ongoing security program.
This is why the conversation around continuous compliance vs. point-in-time audits matters. An annual audit gives you an important snapshot, but security isn't a snapshot. Your environment changes every day. If you're only validating controls when an auditor asks for evidence, there can be a long period where something isn't working and nobody knows it.
How Compliance Debt Accumulates
A control can be completely accurate the day it's audited. The environment doesn't stop changing once the auditor leaves.
Day 1 — Audit Passed
MFA enforced, backups tested, EDR at full coverage
Every control matches the documentation. The environment and the paperwork agree.
Month 3
New SaaS tools roll out
A few of them never get connected to SSO. Nobody flags it — they weren't in scope when MFA was originally rolled out.
Month 6
Hardware refresh and headcount growth
New laptops and servers get provisioned faster than EDR coverage keeps up. Agent coverage quietly drops below 100%.
Month 9
A vulnerability scan finds an issue
A ticket gets opened. No one owns remediation, so it sits open with no deadline and no owner.
Next Audit Cycle
Documentation still says "compliant"
The environment no longer matches what was assessed. Nobody decided this would happen — it's just what happens when controls are treated as a project instead of an ongoing program.
The fix isn't a bigger audit. It's a defined owner and testing cadence for each control, so drift gets caught in month 3 — not at the next audit.
Pass the Audit, Fail the Pentest
There's another version of this that I call Pass the Audit, Fail the Pentest. A company can have a successful compliance audit and still have a penetration test uncover a clear path through the environment. That doesn't necessarily mean the auditor did something wrong — the audit and the penetration test are answering different questions.
An audit is generally trying to determine whether required controls exist and whether the company can demonstrate that they're being followed. A penetration tester approaches the environment differently. They're looking for ways around those controls — testing whether they can gain access, escalate privileges, move through the environment, reach sensitive systems, or combine several smaller weaknesses into something more significant.
This isn't a theoretical gap. In seven years of investigating payment card breaches, Verizon's forensics team never found a single organization that was fully PCI DSS compliant at the time it was breached (Dark Reading). Passing the framework and surviving the attack are not the same test.
This is also why seemingly small gaps matter. A penetration test may find an old application that isn't covered by MFA, a service account with more privileges than it needs, an internal system that was never patched, or a cloud service configured differently from the company's standard. Individually, each issue may look manageable. An attacker gets to combine them. The old application provides initial access, the overprivileged account provides the next step, and the unpatched system provides a path deeper into the environment.
Every major control may technically exist while the path between them remains open.
That's the distinction between cybersecurity compliance vs. security that companies need to understand. Compliance is an important part of a security program, but it isn't proof that the program will hold up against an actual attack.
The Better Question: When Was It Last Tested?
When I'm trying to understand security controls effectiveness, I care less about whether a company can tell me it has a control and more about what happens after that. Who owns it? When was it last tested? What happens if it fails? Who is responsible for fixing the problem? How does management know the issue was actually resolved?
Those questions tend to tell you much more about the maturity of a security program than whether a particular product has been purchased. A backup control should include recovery testing. Vulnerability management should include remediation and accountability. Endpoint security should include monitoring for coverage gaps. Incident response should include exercises. Access management should include periodic reviews. Logging should include someone actually looking at the alerts that matter.
None of this requires turning security into a constant audit exercise. It requires establishing a reasonable testing cadence based on the importance of the control. Some things should be checked continuously, some monthly or quarterly, and others annually. The important part is that someone owns the control and there is a defined process for proving that it still works. Our Compliance, Privacy, and Resilience services are built around exactly this — establishing ownership and a testing cadence, not just passing the next audit.
AI Will Have the Same Problem
We're already starting to see the same issue with AI governance. Companies are developing AI policies, approving certain platforms, restricting others, and establishing requirements around how company data can be used. As AI compliance audit requirements evolve, there will naturally be more pressure to document these controls and demonstrate compliance.
But an AI policy won't be any different from a security policy if nobody validates what's actually happening. A company can have an approved list of AI tools while employees use others. It can prohibit sensitive data from being entered into AI platforms without having a way to identify when it happens. The technology is different, but the governance problem is the same. Writing the control is the easy part. Operating it is what matters.
What Real Security Looks Like
The strongest security programs I've seen don't necessarily have more tools. They tend to do a better job operating what they already have. There is clear ownership, controls are tested on a defined cadence, gaps are tracked, and someone is accountable for getting them fixed. When the environment changes, the security program changes with it.
That's ultimately the difference between compliance and security. Compliance gives you a framework and a baseline. Real security comes from continuously proving that the controls behind that framework are working in the environment you have today, not the environment you had when the last audit was completed.
If you want to know whether your company is actually secure, I wouldn't start by asking when the last audit was completed. I'd ask a simpler question: when was the last time we tested the controls we're relying on?
If SOC 2 is the audit on your calendar, our free SOC 2 Readiness Assessment scores you across the same categories a real auditor checks.
Frequently Asked Questions
What is security theater in cybersecurity?
Security theater is when an organization has security policies, tools, or controls that create the appearance of security without regularly validating whether those controls are actually effective.
Why can a company be compliant and still get breached?
Compliance establishes a baseline of required controls, but environments change and controls can fail, drift, or be implemented inconsistently. An organization can meet compliance requirements while still having exploitable security gaps.
What is the difference between continuous compliance and a point-in-time audit?
A point-in-time audit evaluates controls during a defined period. Continuous compliance focuses on regularly validating those controls as the business, technology, users, and risks change.
What does a real security program require beyond passing an audit?
Clear ownership of every control, a defined testing cadence based on how critical the control is, and accountability for fixing gaps once they're found — not just documentation that the control exists.
.webp)
