Compliant Is Not Secure, and It Never Was

There is a framed certificate on a wall somewhere in your building right now. It has a nice border, an auditor’s logo, and a date. Somebody spent six figures and four months of everyone’s sanity to earn it. And it is telling you a beautiful, expensive lie.

It is telling you that you are secure.

You are not secure. You are compliant. Those are two different things, and I have watched the industry pretend they are the same for twenty years now. So let me say the quiet part out loud, because no auditor is going to write it in the report you paid for: passing the audit is not the job. It was never the job. It is the receipt you show the board so everyone can stop asking uncomfortable questions.

The certificate on the wall did not stop anybody

Here is the thing about compliance frameworks. They describe a floor, not a ceiling. They tell you the bare minimum that a committee of people who have never responded to an incident could agree on. And they describe it as a snapshot. A SOC 2 Type II report attests that certain controls operated over a review window that ended, in most cases, several months before you read the report. It is a photograph of a moving car.

Do not take my word for it. Take the receipts.

Target was assessed compliant with the Payment Card Industry Data Security Standard shortly before attackers walked out with around 40 million payment card numbers over the 2013 holiday season. The certificate was current. The card data left anyway, through a third-party HVAC vendor account and network segmentation that existed on paper more than in the switches. Compliant. Breached. Same year.

Then there is Equifax, the breach that should be printed on the inside cover of every GRC handbook. In 2017, attackers exploited CVE-2017-5638, a remote code execution flaw in Apache Struts. A patch had been available for months. The vulnerability scanner missed it. The asset inventory did not know the vulnerable server existed. The certificate of good standing did not care. Roughly 147 million people had their data exposed, and the FTC settlement eventually reached as much as $700 million.

Every one of those organizations had a compliance program. Every one of them had audits, policies, and probably a certificate on a wall. None of it mattered on the day it counted, because the attacker did not consult the framework before choosing a target.

Why we keep confusing the checklist with the job

I am not against frameworks. PCI DSS, ISO 27001, SOC 2, the NIST catalogs. Used honestly, they are a decent starting inventory of things a grown-up organization should be doing. The problem is not the frameworks. The problem is what we do with them.

We treat the audit as the deliverable. And once the audit becomes the deliverable, everything downstream optimizes for passing it instead of for not getting breached. You get the annual scramble I have watched a hundred times: the two weeks before the assessor arrives, when logging suddenly gets turned on, dormant accounts finally get disabled, and someone writes a password policy nobody will follow the moment the auditor’s rental car leaves the lot.

That is compliance theater. Everyone knows it is theater. The auditor knows. The CISO knows. The board suspects but prefers not to ask, because the certificate lets them tell shareholders on the earnings call that security is “a top priority.” I have sat in those rooms. The certificate is not a security control. It is a liability shield.

But here is what nobody tells you in the sales enablement deck: a control that only operates during audit season is not a control. It is a costume you put on twice a year.

Things That Make Me Grumpy

  1. Scoping. Every breach I have ever cleaned up lived in the part of the network that was carefully declared “out of scope” so it would not blow the audit.
  2. Point-in-time evidence. A screenshot of a correctly configured firewall on audit day tells me nothing about the other 364 days.
  3. Compensating controls that compensate for nothing. If your justification is a paragraph of prose instead of a working mechanism, it is prose.
  4. Policies written to be read by auditors, not humans. If your staff cannot summarize the policy, the policy does not exist.
  5. The phrase “we are compliant, so we are covered.” No. You are covered until an attacker who has never read your Statement of Applicability shows up.

What the frameworks quietly assume you are already doing

Here is the part that should terrify you. The frameworks are not even the hard part. Read the actual requirements. PCI DSS 4.0 assumes you have a real, current asset inventory. It assumes you patch on a defined timeline. It assumes you monitor logs and that a human actually looks at them. It assumes network segmentation that a packet respects, not just a Visio diagram.

Those assumptions are the entire game. Equifax did not fall because it lacked a policy about patching. It fell because the policy was not connected to reality. The framework says “maintain an inventory of assets.” The framework does not, and cannot, make your inventory true. That gap between the words in the standard and the state of your actual network is exactly where every incident I have worked has lived.

Compliance measures whether you wrote down the right intentions. Security measures whether those intentions survive contact with a motivated adversary. The Verizon Data Breach Investigations Report has been telling us the same tired story for over a decade: the exploited vulnerabilities are old, the stolen credentials are reused, and the human error is boringly predictable. None of that is exotic. All of it passes audits every day.

Fine, here is what to actually do

Do the audit. You have to. I am not naive about how business works, and the certificate does open doors and close deals. Just stop mistaking the certificate for the outcome.

Treat the framework as the floor and then ask the only question that matters: if a competent attacker landed on one laptop in accounting this afternoon, how far could they get, and would anyone notice before Friday? Test that. Not with a questionnaire. With an actual exercise, run by people who are trying to win. If you want the honest version of what that kind of assessment involves, I already wrote it down in what a cyber security assessment actually involves, and none of it looks like a checklist.

Make your controls continuous instead of ceremonial. If logging only works in April, it does not work. If dormant accounts only get disabled before an assessor arrives, you have an identity problem the other eleven months. The whole point is that the control operates when nobody is watching, because that is precisely when the attacker is.

And keep your inventory honest, because that single unglamorous discipline is worth more than the entire certificate on your wall. I have been beating this drum since the days I was complaining about card data standards, back when I called 2007 the worst year for PCI security. Almost twenty years later, we keep doing the same stupid thing. We confuse the map for the territory, hang the map on the wall, and act surprised when the territory catches fire.

So by all means, frame the certificate. Just do not let anyone in that building believe it will stop a single packet. It will not. It never has. And if that sounds cynical, go read the last three breach reports and tell me I am wrong.