Summary: What is “cybersecurity theater,” and how can a business tell if its security program is real or just performative?
Cybersecurity theater happens when a company treats security as something to finish rather than maintain — filing signed policies, passing point-in-time audits, and buying tools while the actual work behind those checkboxes quietly stops holding up. The tell is not whether a policy or certificate exists; it is whether the control behind it is still enforced and monitored today. This article breaks down real examples of theater, why it happens even in companies acting in good faith, and how to test whether a security program is a costume or the real thing.
A client once asked us for a set of security policies. We wrote them, sent them back about 90 percent finished, and told them the last 10 percent was theirs to close out. Not the formatting — the decisions. Retention windows, approval authority, how exceptions get handled, and the places where a generic template becomes the way one specific company runs. We told them we needed a short conversation to settle those points.
They approved the documents as written and called them official. That is the moment worth sitting with, because nothing about it looks negligent. They asked for policies. They got policies. They adopted them. Audit that company next week and the policies are right there, signed, dated, filed exactly where you would expect.
The word that did the damage was “official.”
Most companies are not insecure so much as performatively secure, and the performance usually is not a lie — which is what makes it hard to catch. It is the belief that security is something you finish. You write the policy, pass the audit, buy the tool, file the certificate, and now you are secure. Done.
Security does not work that way. You are not secure, full stop. You are secure only for a moment, and only if the work that made you secure yesterday is still holding up today. That is the whole argument. Everything below is what happens when an organization forgets it.
The Control That Stopped Tracking the Risk
Disaster recovery is the plan to bring systems back online after something knocks them down. One organization ran a full recovery data center and tested it every year. On paper, that is responsible.
Here is what the test looked like: someone drove to the recovery site, restored a few servers from backup, confirmed they came up, and logged the results. The company ran a few hundred servers; the test covered a handful. For email, instead of proving Microsoft Exchange could be recovered, the team stood up a separate mail server, pointed DNS at it, sent a message, received one back, then pointed DNS home again. Every year the test passed, but it proved almost nothing about whether the business could actually come back online.
Nobody faked anything — that is the key point. The test was real and the documentation was real. What failed was that the test measured the checkbox, not the organization’s actual recovery need.
The same pattern shows up in other frameworks. PCI, the standard for credit card data security, asks whether card systems are isolated from the rest of the network. Many companies place those systems in their own VLAN and answer yes.
But a VLAN is not the same as blocking access from a random workstation. Real segmentation means firewalled or air-gapped segments with limited outbound access. What we usually find instead is VLAN separation with nothing behind it — technically segmented, but only enough to satisfy the questionnaire.
That is the native language of compliance theater. The answers are not dishonest; they are accurate within the narrow scope of the question. Security does not live inside that scope. It lives along the path someone can legitimately take through the network, and that path rarely respects the line the question drew.
A Policy Is Not a Control
A company had a policy against storing customer information on local machines. A reasonable policy. During a ransomware attack, the data was still sitting on those machines. The interesting part is not that the policy got broken — policies get broken. It is that the company had no way to detect or prevent it: no scanning, no DLP, nothing built to find or stop the data. The policy was a statement of intent, not a control. A real control has three parts: a rule, a mechanism to enforce it, and monitoring to confirm it is still holding. Without the mechanism and the monitoring, there is no control. There is a sentence.
Money and Friction
Here is what gets pushback almost every time: anything that adds friction. Multi-factor authentication. VPNs. Tighter rules for remote work — the measures that make someone do one more step than they used to.
The loudest pushback is not even on the expensive controls. It is on security awareness training — teaching staff to spot a phishing email before they click it. It is cheap, and it is probably the best return on a security dollar available. A company can buy a firewall that costs as much as a car, and one person clicking one link walks straight past it.
Money and friction — that is the trade most companies make, and on its face, it is not unreasonable. A little friction and a little money usually prevent more than they cost. But the cost lands today and the prevention stays invisible, so the math feels backward in the moment.
The clearest sign that this is a trade rather than ignorance is repetition. We have seen a company get compromised, receive a list of issues to fix, address some, ignore others, and then get compromised again. The second attack is not a knowledge gap; they had the evidence and the list. What they lacked was the willingness to keep paying the continuous cost of security.
None of this makes the frameworks the villain. The annoying box is usually bolted to a real risk, and if a company is checking it anyway, it might as well capture the risk reduction that comes with it. The trouble is that anything built on a point-in-time answer rewards the snapshot: pass the audit, collect the attestation, lower the premium. PCI and SOX work this way, and cyber insurance rewards it hardest of all. The snapshot is exactly the thing that starts decaying the day after it is taken.
The Ones Who Get It Right Listen
The companies that are genuinely secure are not the ones with the biggest tooling budget or the newest platform — worth saying plainly, since it is the opposite of what people expect to hear. They listen: to the auditors, to the security team, to the recommendation they did not want, and to what the last incident was trying to tell them. Then they do the work that listening implies, including the parts that cost money and add friction.
They also price risk correctly. Most people size risk in dollars — fines, tooling, downtime. The companies that get it right also count reputation. A company that gets ransomed and has customer data exposed does not just pay to recover; it has to explain to every customer why their information sat on a machine a policy said it should never have touched. That cost never shows up on an invoice, and it can be the larger one.
None of what these companies do is dramatic. It is patching, monitoring, reviewing, training, and checking again next month. Boring work, done on a schedule.
Action Items
Do not start with a new framework or another policy. Start with the claims already being made.
Write down what the company says is true about its security, then read the list back as questions instead of statements. Is MFA required everywhere, or only mostly? Does sensitive data really stay off local machines, or is that just the rule on paper? Is the credit card environment segmented to stop an attacker, or only to answer the questionnaire? Is DR tested against the business, or only against a handful of servers?
Pick one and prove it is true today — not that the document exists, but that the control is running, and that someone would know the morning it quietly stopped. That is the line between security and its costume. Not whether the policy exists. Whether anyone would notice when it stops being true.
Whether a company was ever secure is beside the point. The only question that matters is whether it is secure today, and that answer changes every day.
Curious whether your own policies are controls or just paperwork? A Bridgehead Cyber Readiness assessment shows you exactly where the gap is — no pressure, just clarity.
