Compliance is what happens when security gets translated into paperwork.
That sentence is not an insult. Paperwork has a job. Organizations are large, forgetful animals. If you don’t write down controls, assign owners, review evidence, and make people prove they followed the process, plenty of them will do almost nothing. Frameworks like SOC 2, ISO 27001, and PCI DSS drag a baseline into existence.
The floor matters.
What drives me crazy is when people confuse the floor for the building.
Audit Passed. Breach Happened Anyway.
A company gets SOC 2 Type II certified. Three months later, an attacker walks in through an unpatched VPN appliance. The audit report sits in a drawer — 80 pages of controls that were all technically “in place” while the actual vulnerability wasn’t in scope.
This happens constantly. And somehow, every time, everyone acts surprised.
Anyone who has worked in incident response has seen the pattern. Fully audited, fully certified, maybe even proud of the binder on the shelf, and then breached in a completely ordinary way. Phishing. Stolen session tokens. An exposed admin panel. Over-permissioned cloud roles. A third-party dependency nobody thought counted as “the system” until the day it very obviously did.
The breach doesn’t disprove compliance. It proves compliance was answering a different question.
What Compliance Actually Measures
Compliance checks that controls exist and that you follow your own policies. SOC 2 Type II specifically verifies that you followed those policies over a period — usually 6-12 months. If your policies are weak, you pass with weak security. The audit doesn’t evaluate whether your policies are good. It evaluates whether you followed them.
ISO 27001 certifies that you have an Information Security Management System. Not that the system is strong. That it exists, is documented, and is reviewed periodically. You can pass ISO 27001 with a security program that a determined teenager could bypass — as long as it’s well-documented and regularly reviewed.
PCI DSS comes closest to prescriptive security because it mandates specific technical controls for cardholder data. But even PCI compliance doesn’t mean you’re secure. It means you met the standard’s requirements at the time of assessment. The time-of-assessment part matters more than people admit.
The Checkbox Problem
Once a framework defines what gets checked, organizations optimize for exactly that — and nothing else.
The auditor asks: “Do you have a password policy?” Yes, here it is. Does the policy require 12 characters? Yes. Do employees follow it? Here’s the evidence. Checkbox: passed.
The auditor doesn’t ask: “Is your password policy actually effective against the credential attacks you face?” That’s a security question, not a compliance question. The audit checks that the lock exists, not whether a real thief can pick it.
This is Goodhart’s Law again — the same dynamic that plagues security scores. When the measure becomes the target, it ceases to be a good measure. Organizations spend enormous effort on what auditors check and residual effort on what attackers exploit. Those are frequently different things.
I’ve watched teams spend weeks taking screenshots of AWS configurations and arguing about the definition of “continuous monitoring” — while an exposed admin panel sat untouched because it wasn’t in scope.
The Vendor Trust Chain
The most corrosive effect of compliance culture is how it substitutes for real security assessment between organizations.
“Are you secure?” “We have SOC 2.” “Great.”
That exchange happens thousands of times a day in vendor evaluations. The SOC 2 report becomes a proxy for due diligence. Nobody reads the exceptions. Nobody asks what’s out of scope. Nobody checks whether the controls described in the report actually address the risks relevant to the specific integration.
The compliance report becomes a trust token — passed from vendor to customer to board, each party assuming the previous one validated the substance. Often nobody did.
What Compliance Is Good For
I’m not anti-compliance. I’m anti-complacency.
Compliance forces organizations that would otherwise do nothing to implement basic controls. Access reviews happen because the audit requires them. Encryption at rest gets enabled because PCI demands it. Incident response plans get written because SOC 2 asks to see them.
Without these frameworks, the baseline would be lower. Significantly lower. The frameworks aren’t the problem. Treating them as sufficient is the problem.
Compliance is the minimum you have to do. Security is what you should do. The gap between those two is where most breaches live.
The Honest Conversation
If a vendor hands you a SOC 2 report, read the scope section. Read the exceptions. Ask what systems were excluded. Ask what changed since the observation period ended.
If your own organization just passed an audit, resist the urge to call it a security win. Ask instead: what’s the next thing an attacker would try that this audit didn’t test? That’s the question the framework can’t answer. That’s where the real work starts.
A compliance certificate on the wall means someone did the paperwork. It says nothing about whether the building is actually safe.