There is a particular kind of meeting that happens in large organizations after a major security incident hits the news. Not their incident -- someone else's. The CISO calls a meeting with their directors. The directors call meetings with their managers. Somewhere down the chain, someone is tasked with producing a document that explains why the same thing could not happen here.
That document, in many organizations, is a work of fiction. Not because the people writing it are dishonest, but because the incentive structure rewards demonstrating activity over demonstrating capability. The document lists tools deployed, playbooks written, tabletop exercises completed. It does not say: we tested whether any of this works against the specific technique that was used, and it does not.
This is security theater. It is the single largest drain on IR program effectiveness in enterprise environments, and it persists because it is organizationally useful even when it is operationally worthless.
What Security Theater Actually Is
The term comes from Bruce Schneier's writing about post-9/11 airport security -- the observation that making people take off their shoes creates a visible performance of security without meaningfully reducing the probability of an attack. The concept transfers directly to enterprise incident response.
Security theater is any action that creates the appearance of improved security without actually reducing risk. The appearance matters because security programs exist in an organizational context. They must justify budgets, satisfy auditors, and reassure boards. All of those audiences respond to visible activity. None of them are well-positioned to evaluate whether that activity changes outcomes.
The distinction between theater and substance is not always obvious. A tabletop exercise can be either one, depending entirely on how it is designed and what happens with the results. A playbook can be a lifeline or a prop. The difference is whether the thing in question has been tested against failure, updated in response to that testing, and integrated into the actual workflow of the people who will use it under pressure.
How IR Programs Become Theater
Nobody sets out to build a performative IR program. It happens incrementally, driven by organizational pressures that individually seem reasonable and collectively produce dysfunction.
Playbooks Nobody Follows
The IR playbook is the canonical example of security theater in incident response. Most organizations have them. Most organizations spent significant effort writing them. And in most organizations, when an actual incident happens, the analysts do not open the playbook.
This is not because the analysts are lazy or undisciplined. It is because the playbook was written to satisfy an audit requirement, not to guide an analyst under pressure. Audit-driven playbooks tend to be comprehensive, generic, and procedurally correct. They describe what should happen in theory. They do not account for the specific tooling the team actually uses, the actual escalation paths that work at 2 AM, or the reality that half the steps require access that only one person has and that person is on vacation.
A playbook becomes theater the moment it diverges from how the team actually operates. That divergence is usually present on the day the playbook is published, because the people who wrote it (often a GRC analyst or a consultant) are not the people who will use it (the SOC analysts and IR leads who do the actual work).
The fix is not to write better playbooks. It is to treat playbooks as living operational documents that are tested, broken, and rewritten on a regular cadence. If your playbook has not been updated based on a real incident or a realistic exercise in the last six months, it is a prop.
Tabletop Exercises That Rehearse Success
The tabletop exercise is the second most common form of IR theater. In theory, a tabletop is a low-cost way to test your team's decision-making and communication under simulated incident conditions. In practice, most tabletops are designed to make everyone in the room feel good about the program.
A theatrical tabletop has several recognizable features. The scenario is vague enough that no specific control failure is exposed. The injects are predictable and come at regular intervals. The participants know roughly what is expected of them. The exercise ends with everyone agreeing that the response went well and that a few minor improvements could be made. Nobody leaves the room feeling uncomfortable.
A substantive tabletop is the opposite. The scenario is based on a real attack chain that targets your specific environment. The injects include things going wrong -- the SIEM is down, the IR lead is unreachable, legal disagrees with your containment plan, the CEO is about to make a public statement that contradicts your findings. The exercise is designed to find the places where your response breaks. Participants leave the room with a clear list of things that do not work.
The reason most organizations run theatrical tabletops is simple: the people sponsoring the exercise do not want to look bad. If the CISO's program is evaluated based on the appearance of readiness, a tabletop that reveals serious gaps is a political liability. A tabletop that demonstrates smooth coordination is a success story for the next board presentation.
Metrics That Measure Activity, Not Outcomes
IR programs that report on the number of incidents handled, the number of playbooks written, or the number of tabletop exercises conducted are measuring activity. These metrics tell you nothing about whether the program can actually stop an attacker.
Consider the difference between these two statements:
"We conducted 12 tabletop exercises this year and updated 8 playbooks."
"Our mean time to detect lateral movement decreased from 72 hours to 18 hours, validated by quarterly purple team exercises. We still cannot reliably detect credential dumping from memory -- that gap is documented and has a mitigation plan with a delivery date."
The first statement describes activity. The second describes capability and known gaps. Most board reports contain the first kind of statement because the second kind requires admitting things you cannot do.
Post-Incident Reports Nobody Reads
The post-incident report -- sometimes called the after-action review or lessons-learned document -- should be the most operationally valuable artifact your IR program produces. It is a record of what actually happened, what worked, what did not, and what needs to change.
In most organizations, it is a compliance artifact. It gets written because policy requires it, filed in a SharePoint folder, and never referenced again. The action items from the report are tracked for a few weeks and then quietly deprioritized when the next project deadline hits.
This is theater because the entire purpose of the post-incident process is to improve future response. If the output is not read, the action items are not completed, and the findings do not change how the team operates, then the time spent writing the report was wasted. It existed to satisfy a process requirement, not to make the organization better at responding to incidents.
The Compliance Trap
Compliance frameworks are not the enemy. PCI DSS, SOC 2, ISO 27001, NIST CSF -- these frameworks exist because organizations need a structured approach to security, and most organizations will not build one without external pressure. The frameworks provide that pressure, and the better ones provide genuinely useful guidance.
The trap is when compliance becomes the objective rather than a byproduct of good security. When the question shifts from "can we detect and respond to this threat" to "can we show the auditor that we have a process for this," the program has lost its operational focus.
This shift happens because compliance has a clear, measurable definition of success: pass the audit. Operational security does not. You can have a perfect audit and still get breached. You can have a mediocre audit score and be genuinely good at detecting and responding to attacks. The audit measures the presence of controls, not their effectiveness.
The most dangerous version of the compliance trap is when the IR team starts optimizing for audit evidence. Instead of building detection rules that find attackers, they build detection rules that produce log entries the auditor expects to see. Instead of running realistic exercises, they run exercises that produce the documentation artifacts the framework requires. The program looks better on paper with each passing audit cycle while its actual capability stagnates or declines.
The Auditor Relationship
Good auditors know the difference between a compliant program and an effective one. They are constrained by the framework they are auditing against, but experienced auditors will tell you -- often off the record -- when they see a program that checks all the boxes but would fall apart under real pressure.
The problem is that organizations frequently treat the audit relationship as adversarial. They prepare for audits the way students cram for exams: optimize for the test, not for the underlying competency. This creates a perverse dynamic where the audit consumes weeks of the IR team's time -- time that could be spent on actual detection engineering or response preparation -- and produces an artifact that confirms the program looks good rather than confirming it works.
If you find your team spending more time preparing for audits than preparing for incidents, that imbalance is itself a form of theater.
Performative Escalation
When a significant incident occurs, there is enormous pressure to demonstrate that the organization is taking it seriously. In many enterprises, "taking it seriously" means activating the incident command structure, opening a war room (physical or virtual), pulling in senior leadership, and scheduling hourly status calls.
Sometimes this is the right response. A confirmed breach affecting customer data, a ransomware deployment spreading across the network, a supply chain compromise with unknown scope -- these warrant full mobilization.
But in many organizations, the threshold for full escalation is set by political calculus, not operational need. The war room opens because a VP heard about the alert and asked "what are we doing about this." The hourly status calls happen because senior leadership wants to be seen managing the situation. The incident command structure activates because not activating it would raise questions about whether the team took it seriously.
The operational cost of performative escalation is real. Every analyst pulled into a status call is an analyst who is not investigating. Every hour spent preparing a leadership briefing is an hour not spent on containment. The war room becomes a performance venue where the team narrates their investigation for an audience of stakeholders who cannot contribute to the technical work but whose presence demands constant updates.
The particularly damaging version of this is when the escalation itself creates confusion. Analysts who were working the investigation independently now have to coordinate through a command structure that was not designed for the specific situation. Communication channels multiply. People start working on the same leads without knowing it. The response gets slower, not faster, despite the additional resources.
The Vendor Theater Problem
After every major public breach, boards ask their CISOs the same question: "Could this happen to us?" The honest answer is usually "yes, possibly, and here is what it would take to reduce that probability." The career-preserving answer is "we are evaluating tools to address this risk."
This dynamic drives a significant portion of security spending. The board is afraid. The CISO needs to demonstrate action. A vendor has a product that addresses the specific threat in the news. A purchase order is signed. A tool is deployed. The board is reassured.
Whether the tool actually works in the organization's environment, whether the team has the capacity to operate it, whether it integrates with the existing detection pipeline, whether it addresses the specific variant of the threat that is relevant -- these questions are secondary to the political function of the purchase. The tool exists to answer the question "what are we doing about X" with something more concrete than "we are working on it."
The result is tool sprawl: a collection of security products, each purchased to address a specific fear, none of them fully integrated, many of them generating alerts that nobody has time to investigate. The median enterprise SOC has somewhere between 25 and 75 security tools. The median enterprise SOC also has an analyst-to-alert ratio that makes thorough investigation of every alert mathematically impossible. These two facts are related.
The Incentive Problem
Security theater persists because the incentive structure in most organizations rewards it. Understanding those incentives is the first step toward changing them.
Nobody Gets Fired for Buying Another Tool
This is the security version of the old IBM sales adage. When a breach occurs and the board asks what went wrong, "we deployed the industry-leading solution but the attacker found a way around it" is a survivable answer. "We decided the tool was not worth the cost and invested in training our analysts instead" is a career-ending answer, even if the second decision was operationally correct.
The asymmetry is stark. Buying a tool that does not work is forgivable because you tried. Choosing not to buy a tool and then getting breached is negligent because you did not try hard enough. The fact that "trying" in the first case produced no security value while "not trying" in the second case might have produced better outcomes is irrelevant to the organizational judgment.
This asymmetry drives rational actors toward theater. If the downside of purchasing an ineffective tool is zero and the downside of not purchasing is career risk, every CISO will buy the tool. The waste is distributed across the security budget where it is invisible. The career risk is concentrated on one person where it is very visible.
People Get Fired for Admitting Gaps
The second incentive problem is that honesty about capability gaps is punished. Telling the board "we cannot detect this category of attack and here is the investment required to change that" requires the CISO to admit weakness. In a culture that evaluates security leaders on the absence of incidents rather than the quality of response, admitting a gap feels like inviting accountability for the next breach.
The result is that gap analysis -- arguably the most valuable activity an IR program can perform -- is either not done, done superficially, or done honestly but not communicated upward. The board receives a sanitized version that emphasizes progress and minimizes remaining risk. The actual state of detection coverage remains unknown to the people who allocate resources.
This is not a personal failing. It is a structural problem. Organizations that want honest security assessments must create conditions where honesty is rewarded rather than punished. That means evaluating security leaders on how quickly gaps are identified and addressed, not on whether gaps exist.
Detecting Theater in Your Own Program
If you run an IR program, or work in one, you should assume that some portion of your activity is theater. Not because your team is incompetent, but because the organizational forces that produce theater are present in every enterprise. The question is how much theater you have and where it is hiding.
The "Would This Have Mattered" Test
Take any activity your IR program performs regularly -- a playbook update, a tabletop exercise, an alert triage workflow, a post-incident report. Ask one question: if we had not done this, would our ability to detect or respond to an actual attack be measurably different?
If the answer is no, or if nobody can articulate a specific way the activity improves response capability, it is probably theater. It may still be necessary for compliance or organizational reasons, but you should be honest with yourself about what it is.
Apply this test systematically across your program and you will find that a surprising amount of activity falls into the "would not have mattered" category. That is not a reason to panic. It is a reason to reallocate.
The Last-Incident Retrospective
Another diagnostic: look at your last real incident. Not a drill, not a tabletop, not a false positive that got escalated -- a real security event that required actual response.
Now compare what happened during that incident with what your program says should happen. How closely did reality match the plan? Which playbooks were actually opened? Which communication channels were actually used? Which tools provided actionable data versus which ones were bypassed in favor of direct log queries?
The gaps between plan and reality are your theater. Every place where the documented process was ignored in favor of something that actually works is a place where your documentation exists for an audience (the auditor, the CISO, the board) rather than for the practitioners.
Replacing Theater with Substance
Eliminating theater entirely is not realistic in most organizations. The political and compliance pressures that produce theater are real constraints. What is realistic is reducing the proportion of theater relative to substance, and being honest about which is which.
Measurable Detection Coverage
The single most valuable artifact an IR program can produce is a detection coverage map: a matrix that shows, for each relevant attack technique, whether you have a detection rule, whether that rule has been tested against a realistic simulation of the technique, and what the false positive rate is.
This is substance because it is falsifiable. You can test whether a detection rule fires when it should. You can measure the false positive rate. You can compare your coverage map against the techniques used in incidents affecting your industry. You can identify gaps and prioritize them based on actual threat intelligence rather than vendor marketing.
Most organizations do not have this artifact because producing it requires admitting that large portions of the MITRE ATT&CK matrix are uncovered. The detection coverage map is the anti-theater: it shows exactly what you can and cannot do, with evidence.
Tested Response Procedures
Replace untested playbooks with procedures that have been validated under realistic conditions. This does not mean running a tabletop once a year. It means regularly executing response procedures against simulated incidents that are designed to break the process.
The testing cadence matters. A procedure tested annually is a procedure that is current for about one month after the test and then begins drifting as the environment changes, staff turns over, and tools are updated. Quarterly testing is a reasonable minimum for high-priority response scenarios. Monthly is better if you can sustain it.
Document not just the procedure but the test results. "We ran the ransomware containment procedure on March 15. The network isolation step failed because the firewall rule syntax had changed in the last update. We fixed the procedure and retested on March 22. The updated procedure works." That documentation has operational value. A playbook that was written once and never tested has none.
Honest Gap Analysis
The hardest and most valuable thing an IR program can do is produce an honest assessment of what it cannot do. This requires organizational air cover -- the CISO must be willing to present gaps to the board, and the board must be willing to hear them without treating the presentation as an admission of failure.
An honest gap analysis includes: detection techniques you cannot currently detect, with an estimate of the effort required to close each gap. Response scenarios where your current staffing, tooling, or process would fail, with specific failure modes. Dependencies on external parties (MSSP, vendors, law enforcement) where the dependency has not been tested under realistic time pressure.
This document is the opposite of the compliance audit. The audit says "here is what we have." The gap analysis says "here is what we lack." Both are necessary. The gap analysis is the one that drives improvement.
The Political Cost of Honesty
Everything in this article leads to the same uncomfortable conclusion: the primary obstacle to effective IR programs is not technical. It is political.
Telling the board "we cannot detect lateral movement via pass-the-hash in our environment" is a statement of fact that has career implications. It invites the question "why not" and the follow-up "what have you been spending money on." The CISO who makes that statement is betting that the board values honesty over the appearance of competence. That bet does not always pay off.
But the alternative -- maintaining the fiction that the program is more capable than it is -- has its own costs. Those costs are just deferred to the moment when an actual incident reveals the gap. At that point, the question is no longer "why can you not detect this" but "why did you tell us you could."
The organizations with the strongest IR programs are the ones where security leadership has enough credibility and organizational trust to be honest about capability gaps without that honesty being treated as incompetence. Building that trust takes years. It requires a track record of identifying gaps, presenting plans to address them, and following through on those plans.
It also requires a board that understands that perfect security is not achievable and that the goal is not the absence of risk but the deliberate management of it. Boards that expect their CISO to guarantee no breaches will get CISOs who maintain that fiction. Boards that expect their CISO to identify risks and present options for managing them will get honest assessments.
The First Step
If you recognize theater in your IR program -- and if you have been reading this honestly, you do -- the first step is not to tear everything down. It is to start measuring what matters.
Pick one attack technique that is relevant to your environment. Test whether your detection rules fire when that technique is executed. Measure the time from execution to detection. Measure the time from detection to containment. Document what works and what does not. Fix what does not work. Retest.
That single exercise -- testing one technique end to end -- will teach you more about your program's actual capability than a year of tabletop exercises and playbook updates. It will probably also be uncomfortable, because it will reveal gaps that your program's documentation does not mention.
That discomfort is the feeling of theater giving way to substance. It is the beginning of an IR program that does what it claims to do.
The work is not glamorous. There are no ribbon-cutting ceremonies for detection rules that actually fire. Nobody gives a conference talk about the playbook that was tested, found wanting, and quietly fixed. The vendor will not write a case study about the tool you chose not to buy because your team's manual process was more effective.
But when the next incident comes -- and it will -- the program built on substance will perform. The one built on theater will produce a very impressive-looking post-incident report explaining why it did not.