I have spent time recently with a few executive teams standing up their security programs. The words varied. The gist did not. "We need to achieve this certification to get to market."
I understand the instinct. Certifications, frameworks, and regulations are real infrastructure for our ecosystem. They give a buyer a fast way to trust a seller. It is far easier for a company to look for a SOC 2 or a PCI attestation than to run deep due diligence on every vendor it considers. The certificate is a shortcut for trust, and shortcuts for trust are valuable. I am not here to argue against them.
But sitting in those rooms, I kept seeing the same thing underneath the words. These teams were not building security. They were building enough security to pass. The certification was not the floor of the program. It was the ceiling. The goal was the certificate, and the security was whatever the certificate required, and no more.
Here is what I told them.
A good security program creates easy certification. A good certification program creates breaches.
That sounds like wordplay. It is not. It is the most important distinction in how you build a security function, and getting it backward is how compliant companies end up on the news.
The two directions
Start with the direction that works. A good security program produces certification as a byproduct. If you actually patch, actually manage identity, actually log and review, actually control access, actually test your response, the audit is easy. You walk in, you show the auditor what you were already doing, and you pass. The certificate falls out of the work like exhaust. You did not build for the audit. You built for the adversary, and the audit was satisfied by the same evidence.
Now the direction that fails. A good certification program, a program optimized to pass the audit, produces almost nothing about security. You can pass every audit on the calendar and remain trivially breachable, because compliance measures whether you did the named things, in the named way, on the day someone checked. It does not measure whether you are hard to attack. Those are different questions, and the gap between them is where breaches live.
Why they diverge
The reason they diverge is structural, not accidental.
Compliance frameworks are generic by design. A standard that applies to a hospital, a bank, and a SaaS startup cannot be specific to any of them. So it describes controls in the abstract, access should be restricted, changes should be reviewed, data should be encrypted, and leaves the implementation to you. The framework cannot see that the specific way your engineers ship to production bypasses the specific control you documented. It only knows you documented one.
Compliance is also lagging. Frameworks codify the consensus of a few years ago, updated on committee timelines. The threat you face this quarter is not in this year's standard. The standard that covers it will arrive after the breach that taught everyone it mattered.
And compliance is checkbox-shaped. It rewards the existence of a thing, not the efficacy of it. A policy document satisfies a control whether or not anyone reads it. A quarterly access review satisfies a control whether or not it catches the stale admin account that becomes the entry point. The auditor confirms the review happened. The auditor does not confirm it worked.
Controls that exist versus controls that work
This is the deepest gap, and it is worth naming on its own. Frameworks require that controls exist. They almost never require that controls work. You are asked to have monitoring, change control, incident response. You are not asked to prove that your detection actually fires when an adversary moves, that your response actually performs under load, that your recovery actually restores inside the window you promised. An inventory is a record, not a control. A documented procedure is a record, not a control. The control is the thing that holds when something real hits it, and compliance, almost universally, takes the record as proof of the control. So programs accumulate well-documented mechanisms that have never once been tested against an adversary, and discover on the worst day that the framework on paper and the system under attack were never the same thing. The fix is not more documentation. It is efficacy testing. Breach and attack simulation, purple teaming, fault injection, the deliberate practice of making your controls perform under adverse conditions before an attacker tests them for you.
This is the theater
This is the theater. Not the absence of security. Security built precisely to the height of the certificate and no higher. It passes honestly. It is also exactly as deep as the checklist and not one inch deeper, which means the moment an adversary does something the checklist did not anticipate, there is nothing underneath. And adversaries do that for a living.
I want to be careful, because this is where the argument usually overreaches. The answer is not to dismiss compliance. It is a floor, and floors matter. It forces a baseline on organizations that would otherwise have none. It gives buyers a common language to ask hard questions. The people who built these standards did real good. The failure is not that compliance exists. The failure is treating the floor as the ceiling.
Which program are you running?
You can see which program you are running by where it spends its attention. The theater program produces artifacts. Policies written to be shown. Reviews performed to be recorded. Diagrams that describe the architecture as designed rather than as deployed. It is busy, and almost none of the work makes the company harder to attack. It makes the company easier to audit.
The real program spends its time on the unglamorous mechanics that actually reduce risk. Patching that happens. Identity hygiene that holds. Logging that gets read. Response that works under load, not on paper. None of it photographs well. None of it impresses on a slide. All of it is what determines whether the certificate on the wall means anything.
Here is the test I would put to any program, including my own. If the auditor cancelled tomorrow and never came back, what would you stop doing? Whatever is on that list was theater. It existed for the audit and nothing else. The work that survives the auditor leaving is the work that was actually security.
Build the security, let the certificate fall out
So invert the relationship the execs in those rooms had it in. Do not build to the certificate and hope it makes you safe. Build the security, and let the certificate fall out of it. One direction gives you an easy audit and a hard target. The other gives you a clean certificate and a soft one.
A good security program creates easy certification. A good certification program creates breaches. Know which one you are building. Your customers cannot tell the difference from the outside. The adversary can.