Walk into most security programs and you will find culture rendered as decoration. A poster by the coffee machine. An annual training module with a completion bar. A line in the all-hands deck that says we take security seriously. When an examiner or an enterprise customer's diligence team asks how you know that culture is actually working, the honest answer most teams can produce is a training-completion percentage — which measures attendance, not behavior, and proves nothing about what anyone does at 4:55 on a Friday.
I want to make an uncomfortable argument to the people who own security programs, myself included. Culture is a control. Not a soft complement to your controls. A control. And the reason it fails silently — the reason it is the one part of the program nobody can actually audit — is that we refuse to treat it like the others.
Every other thing you call a control has four things: an objective it serves, a defined behavior it requires, evidence that the behavior is happening, and a failure mode you monitor for. Firewalls have all four. Access reviews have all four. Culture, in most programs, has none of them. Give it the same four and it stops being a mood and starts being auditable.
A control has four parts. Culture usually has none of them.
Start with what makes something a control at all. A control has an objective — the risk it exists to reduce. It has a defined behavior — a specific, observable thing that either happens or doesn't. It has evidence — an artifact that shows the behavior happened, one you can hand to someone who has no reason to trust you. And it has a failure mode — a named way it breaks, which you monitor for so the failure surfaces before the loss does.
Now hold security culture against that bar. "Employees care about security" is not an objective; it is a wish. "We foster a culture of security" names no behavior — you cannot observe caring, and you certainly cannot evidence it. A survey that comes back 82% favorable is not evidence a behavior happened; it is evidence that people know which answer sounds right. And almost nobody has written down how this control fails, so when it fails it arrives as an incident instead of as a metric that moved last month.
The frameworks already told us this belongs. SOC 2's common criteria open at CC1, the control environment, which is lifted straight from COSO — and COSO's first principle is a demonstrated commitment to integrity and ethical values. The FFIEC examination handbooks talk about management setting a security culture and a tone at the top. The intent is right there in the standard. We just satisfy it with a policy PDF and a signed acknowledgment, which is the paperwork of a control without the control underneath.
The behaviors worth writing down, not the values
You cannot audit an attitude. You can audit a behavior. So the first real work of treating culture as a control is refusing to write down values and writing down behaviors instead — each specific enough that two reasonable people would agree whether one happened.
Here are the behaviors I actually depend on, each tied to the risk it reduces. Notice that none of them are beliefs. Every one is something a person does or doesn't do, and every one leaves a trace.
- People report, and they report fast. Suspected phishing, a lost laptop, a file sent to the wrong recipient. The objective is dwell-time reduction, and the honest measure is report rate and time-to-report — not click rate.
- People report their own mistakes. The near-miss and the self-inflicted error surface without a manager having to drag them into the light. The objective is catching failures while they are still cheap. The enemy is silence.
- People take the least access that lets them work. They request just-in-time and let it expire, rather than hoarding standing entitlements "just in case." The objective is blast-radius reduction, and the behavior is visible in every access request you approve.
- People use the paved road. The secure default is the easy default, and engineers actually pick it rather than routing around it because the workaround shipped faster. The objective is keeping shadow IT — and now shadow AI — from quietly becoming the real architecture.
- People treat exceptions as debt, not as a lifestyle. An exception gets requested, dated, and closed, instead of renewed forever until "temporary" turns load-bearing. The objective is stopping risk from accreting one signature at a time.
- Leaders model it under deadline. Tone at the top is only real if it survives a shipping date. The executive who asks for the security step to be skipped "just this once" is the loudest culture signal in the building, and everyone hears it.
Evidence you already generate, not a survey
Here is the part that surprises people. You are already generating almost all of the evidence a culture control needs, and it is not in a survey. It is in your identity provider, your ticketing system, your phishing-simulation platform, your DLP logs, and your change record. Culture evidence is a query, not a questionnaire.
The trick is measuring the right edge of each behavior. Take the phishing simulation, the ritual everyone runs. Most programs report click rate and treat a low number as success. Click rate is close to a vanity metric — it mostly tracks how obvious the lure was that quarter. The number that measures the control is the report rate, the fraction of people who saw it and told you, together with time-to-first-report, because the first report is what lets you pull the real message before it spreads. A program where clicks are low but reports are near zero is not a healthy culture. It is a quiet one, and quiet is worse, because it means the reporting muscle has atrophied while the dashboard looks green.
Two more that matter. Self-reported incidents trending up is usually a good sign, not a bad one — it means people trust you enough to raise a hand, a lesson the safety-critical industries learned decades ago and codified as a "just culture," where you separate honest error from recklessness so people stop hiding the honest error. And the shape of your access and exception requests tells you whether people are working with the program or around it: standing-access growth, exception renewals that never close, emergency-change volume creeping upward. None of this needs a new tool. It needs someone to decide these numbers are culture telemetry and put them on the same page as the rest of your control evidence.
I have argued before that technical control evidence should be generated as code, straight out of the systems of record. This is the behavioral half of the same idea — the evidence a pipeline cannot emit, because it is about what people chose to do, but that your systems recorded anyway.
Failure modes you name before the breach names them
The last thing a real control has is a named failure mode. Reliability engineers do this deliberately with a failure mode and effects analysis: you write down how a component can fail before it fails, so you can instrument for the early signal instead of learning from the wreckage. Culture deserves the same list, because it fails in boringly predictable ways. Name them, and map each one to the objective it violates.
- Silent near-misses. People make errors and quietly fix them, so you never learn the control almost failed. This is the dog that does not bark. It defeats your detection objective, and it is invisible by definition — which is exactly why report rate, not click rate, is the metric that matters.
- Exception normalization. The temporary exception renews until the risky state becomes the default. It defeats least privilege and change discipline, one signature at a time, and its leading indicator is the age of your open exceptions.
- Rubber-stamp oversight. Access reviews and approvals performed as a formality — everything approved, nothing questioned. It defeats the very control the review was supposed to be. Approval fatigue turns a gate into a turnstile, and the tell is an approval rate that never dips.
- Shadow adoption. Work routes around the secure path because the secure path is slower — shadow SaaS yesterday, shadow AI today. It defeats your data-handling objective and grows fastest exactly where the paved road has the most friction.
- Tone-at-the-top erosion. A leader visibly trades the control away under deadline, and the behavior propagates faster than any training can counter it. It defeats the control environment itself — the one sitting at
CC1that the whole program rests on.
Every one of these has a leading indicator sitting in data you already keep. A named failure mode with a leading indicator you watch is the entire difference between a control you operate and a poster you hang.
Report it as a control, or it stays decoration
A control you cannot report is a control you cannot defend. At a company serving 1,500+ financial institutions, my customers' examiners effectively examine me — and "we have a strong security culture" is not a sentence that survives that room. What survives is a behavior, its objective, its current evidence, and its named failure mode with the indicator you watch. That is the same shape as every other control in the package, which is the whole point: culture stops getting a special, softer standard than the firewall rules two tabs over.
The frontier here moves faster than the poster. When we built AgentOS, our governed internal agent platform, the culture control had to grow a new behavior almost overnight — how people use internal AI, what they paste into it, whether they reach for the governed tool or route around it to an ungoverned one. That is a behavior. It has an objective, and it leaves a trace, which means it is auditable the same way the rest are. Every new capability you hand your people adds a row to the behavior catalog. The programs that treat culture as a control add the row and instrument it. The ones that treat it as a value repaint the poster.
Start with three behaviors
You do not need a culture program to start. Pick three behaviors you genuinely depend on and write them down as behaviors, not values. Find the evidence you already generate for each — the report rate, the exception age, the access-request shape — and move it onto the same page as the rest of your control evidence. Name the failure mode for each, with the leading indicator you will watch. Then report all three the way you report any other control, to your leadership and to whoever audits you.
Do that, and culture stops being the part of the program you hope is working and becomes the part you can prove is.
I am curious which behavior you would put first. Report rate is where I would start, but I have heard a good case for exception hygiene as the earliest tell that a culture is slipping. Tell me what you audit — and what you have watched fail silently — in the comments.
