Security theater is expensive

Every hour my team spends on theater is an hour we’re not spending on work that actually reduces risk, unblocks another team, or helps the business move faster.

There’s a hundred things to do and we’re staffed to do ten. Every activity is a prioritization decision, whether we call it that or not.

The pattern that separates the work that matters from the work that doesn’t is the same across categories. Continuous instead of periodic. Automated instead of manual. Behavior instead of signature. Theater fails on all three. The work that actually changes the risk picture passes on all three.

The shape of theater

It’s point-in-time. An annual review, a quarterly attestation, an exercise that happens once and then doesn’t. Reality changes between the events, but the artifact does not.

It’s low-signal. GRC tools like Vanta, Drata, and similar automation platforms pull a lot of the evidence from source systems automatically these days, so this isn’t really about humans doing the collecting anymore. It’s about what gets collected: screenshots, attestations, and signoffs that don’t actually show the control is working. The collection got automated, but the signal didn’t.

It’s comprehension-free. We track signatures and completion, not understanding or behavior change. The artifact says the work was done, but whether it actually did what it was supposed to do is a separate question, and one we don’t ask often enough.

And it’s disconnected from reality. The policy says one thing while the system does another, and the auditor only checks that the policy exists, not that the system matches it.

Most theater I’ve seen hits at least three of those four. Some hits all four.

What this actually looks like

A short list of theater I’ve either inherited, run, or seen up close. None are inherently useless, but most are typically overdone or misapplied.

Annual security training that gets clicked through. Forgotten the next day because it was so boring. No measurable change in behavior.

Annual risk assessment as a point-in-time spreadsheet. Stale within weeks. Includes a fraud risk indicator in our implementation because the auditor reads SOC 2 that way, not because anyone uses it.

Quarterly access reviews where the manager gets a giant spreadsheet, glances at it, and signs. The signature is the control.

Risk acceptances renewed annually without revalidation. A year passes, the renewal goes through. Nobody checks whether the original justification still holds.

Vulnerability triage on findings where reachable risk is already known to be negligible. A “high” on a host slated for decommission. Half a day spent confirming what the team already knew.

Evidence screenshots manually collected from systems that actually have APIs. A human opens the console, captures the screen, drops it in a folder for the auditor. Same data the API would return in structured form.

Approval workflows where the ticket goes in after the work is done. The decision happened in Slack last Tuesday… the approval is a formality filed for the audit.

Most of these, in my experience, started as reasonable controls that turned into rituals over time. The shape stuck around. The risk reduction didn’t.

Why we keep doing it

I think most of it comes down to compliance pressure. And most of the time, that pressure isn’t really about the auditor. It’s about getting a clean report sales can hand a prospect when a deal depends on it. The controls we build for that work fine for audit purposes. Real risk reduction is a separate goal. Those controls don’t always produce it.

Theater is also easy to measure. Tickets closed. Trainings completed. Reviews filed. All things you can put on a slide. The work that actually reduces risk… an early design conversation that steered a feature away from a risk, a risky or untested dependency flagged before it landed in main, an engineer pulling us in early enough to weigh in before the call got made… is harder to count. The work that gets measured is the work that gets done.

“This is how it’s always been done” is a real argument, even when nobody can defend why.

The real cost

The obvious cost is engineering time we’ve redirected away from product work. The quieter cost is on my team. Time spent reconciling vulnerability state, chasing acknowledgments, and shepherding evidence is time we’re not spending on threat modeling, detection coverage, or any of the work I want us to focus on.

When the rituals fill the calendar, the impactful work doesn’t happen. Or it happens half-done, late, and only on the things that screamed loudest.

There’s also a credibility cost. When other teams see us spending capacity on things they can tell don’t matter, we burn credibility. The next time we ask for their attention on something that does matter, there’s less of it to give us.

An idea I’m working with

This isn’t my official playbook yet, but it’s the frame I’ve been using as I look at our list. Three buckets for any given piece of theater. The reason I like it is that it forces a call on each one. No “we’ll get to it.” Pick a bucket and move.

Kill it. If a control doesn’t reduce real risk and isn’t required by anything we have to comply with, then just get rid of it. No replacement needed. Why keep doing something that doesn’t provide any value?

Shrink it. If the control has some value but we’re overdoing it, scope it down. The marketing team onboarding a vendor where the only interface is a shared Slack Connect channel doesn’t really need a full third-party assessment. A lighter review and a documented rationale gets you the same risk posture and a fraction of the burden.

Automate it. If a control is required for compliance but doesn’t need human judgment, fully automate it. No human in the loop on the routine cases. Evidence pulled from source systems on a schedule, exception handling triggered when something breaks, and the human only involved when something genuinely needs a decision.

There’s no permanent “tolerate it” bucket for theater that still has a human in the loop. Tolerated theater turns into the kind of work that lives forever, fills the calendar, and uses up the capacity we need for the work that matters.

Fully automated theater is the exception. Once it runs without us, it stops competing for capacity, and it can stay as long as the compliance requirement stays. The goal is to get everything that has to exist into that bucket so the team can focus on work that actually reduces risk.

The shift to continuous

A lot of the theater above wasn’t theater on purpose. It built up because the tools to do better didn’t exist, the knowledge wasn’t widespread, and trying something different was expensive enough that nobody bothered. We didn’t have a way to continuously check whether policy matched reality, so we settled for an annual review. We didn’t have a way to verify comprehension, so we settled for a signature. We didn’t have a way to surface only the exceptions, so we made humans review everything.

AI lowers the barrier on all three. The work itself is cheaper, the knowledge to do it is easier to get, and we’ll try approaches we used to skip because the cost of experimenting is low enough to be worth it.

Cheaper doesn’t mean free. Bad automation makes theater faster, and continuous controls without signal tuning just become continuous noise. The work shifts from running the ritual to tuning the signal.

Every one of these is a point-in-time control becoming a continuous one.

Point-in-time fails in a predictable way. You audit something today and sign it off. Tomorrow a permission gets added. A system drifts from policy. A new threat lands that the last tabletop didn’t cover. The artifact says it was true on the day of the check. Reality moves the next day.

What we need is something that continually watches for the patterns that matter and triggers action when it sees them. Continuous controls aren’t new. AI lowers the cost enough that a small team can actually build them.

The pattern applies almost everywhere we do point-in-time work today. Continuous access reviews. Continuous evidence generation. Continuous coaching. Continuous policy-to-reality checks. Continuous tabletops. Continuous red teaming. Etc. Several already have real vendor entries: AI-driven IR, BC/DR, and crisis-comms tabletops generated from current threat intel; continuous control monitoring on the GRC side. Others are where AI is just starting to make the work realistic.

Every one of these is capacity my team currently spends on the ritual version of the same work.

Two examples to make it concrete.

Continuous access reviews. Today, managers get a spreadsheet of every permission every direct report has, and they sign. The direction is AI evaluating access against role, usage, and risk continuously, with the manager only seeing the small set flagged as anomalous instead of five hundred lines of “looks fine.” Same pattern works for vulnerability triage, vendor reviews, and policy attestations.

The hard parts of the access review case don’t go away. Authoritative role and identity context, audit acceptance of the new control shape, handling cases where legitimate intent isn’t observable from usage alone. AI doesn’t solve those. It lowers the cost of the new control shape enough to make the work of getting there worth it.

Continuous evidence generation. Even with a GRC tool handling some of the lift, our SOC and ISO evidence still goes through a lot of human curation before the auditor arrives. The direction is closing that gap. Evidence generated from source systems on a schedule, with the auditor pulling from a single endpoint.

The prep work doesn’t disappear. Control mapping, source reliability, scoping, and exception handling all still need to be done. What goes away is the humans curating it every audit window.

A quick note on coaching, because the framing matters. The continuous version of annual training is in-the-moment intervention. An existing email security or DLP tool already does the narrow version. Flag a risky outbound message before it’s sent, give the sender context, log the interaction. AI extends the pattern across more of the surfaces where risky actions happen. I’m intentionally narrow here. Anything that veers into broader employee monitoring is a different program with different governance, and not what I’m describing.

Without AI, the playbook stays “do the annual ritual and hope it’s enough.”

Where I’m headed

Honest version: we’re just getting started. Starting to research, starting to investigate how AI can actually help transform these items.

Like most engineering orgs, we use a PR template. It captures intent, links to tickets, calls out test coverage. It also has a “security” checkbox the author is supposed to check if the change has security implications. The intent is to surface the PRs that need a security look before they land.

In practice, engineers don’t always know what counts as a security impact. The box gets missed on changes that do affect security and checked on changes that don’t. The control assumes accurate self-classification, and it mostly doesn’t work.

The fix is AI-assisted security review tied to the actual diff. No self-attestation, every PR evaluated against what changed in the code. Findings land inline on the PR, gating merge when something real shows up and routing the rest to the right reviewer, not piling up in another dashboard nobody reads. Until that ships, the checkbox is still there. It satisfies a compliance requirement… it doesn’t actually surface the PRs that need a security review, which is what the control is supposed to do.

Vendor questionnaires are next. We’re rebuilding the intake to lean on what’s verifiable… SOC 2 reports, ISO certs, runtime behavior we can observe… and only escalate to a human when the signals don’t add up.

The intake is only part of the problem, though. Most of the VRM programs I’ve seen spend too much time on the vendor and not enough on how the org is actually using them. Same vendor, same posture, very different exposure depending on what data you send them and how you’ve integrated. Reviewing the vendor once at purchase and then again at renewal doesn’t catch any of that, and it doesn’t catch new vulnerabilities, breaches, or posture changes between those points either.

The short version: same continuous pattern, applied to both the vendor’s posture and how we’re using them.

SOC and ISO evidence is the longest project on the list. Even with our GRC tool handling part of the lift, audit prep is still a lot of people work: chasing teams, capturing screenshots, filling gaps the tool can’t reach. The direction is continuous evidence pulled from source systems on a schedule, with humans only in the loop when something actually deviates from what the auditor expects.

The rest of the list… access reviews, tabletops, policy review, awareness training, risk assessment… lands in the same place. None of them are shipped. All of them follow the same continuous pattern, just applied to different work.

I’ll break down each area in future posts. AI-assisted security review, vendor questionnaires, SOC and ISO evidence, access reviews, tabletops, the rest. Each is a different problem, and the detail matters.

Closing

Theater is expensive. Every piece of it on the list takes time away from the more impactful work. The call on each piece is the same. Kill it, shrink it, or automate it.

What replaces it is continuous. Continuous reviews, continuous evidence, continuous coaching, continuous policy checks. None of that is new… AI is what brings it into reach for a small team.

The value isn’t the automation. It’s the capacity we get back, and what we do with it.