I recently had a discussion with a few colleagues about incident response. It started the way these conversations often do, with someone asking what “good” incident response really looks like and some of the incidents that I’ve worked on. That question sounds simple, but it is not. Before long, we were debating playbooks, tabletop exercises, automation, detection tooling, how many logs or alerts are right, escalation paths, and executive communication. And somewhere in the middle of it, someone mentioned, “There really isn’t a one size fits all approach, is there?” I let that thought hang in the air for a second, because it is true. Incident response is not a standardized fast food combo. You cannot just order the number three, swap the fries, and expect it to work for every organization in every scenario.
Yet if you look at how many companies approach incident response, you would think there is a universal recipe. Write the plan…assign the roles…run a tabletop…have a few shiny detection tools…put together a communications template and check the compliance box. Then after all that we tend to just declare we’re ready. I get it…It feels organized, responsible and mature and it looks great in a board deck. Yet without situational awareness, all of that structure can quickly turn into something that looks impressive but accomplishes very little.
That is when incident response becomes theater.
Theater is not inherently bad, I enjoy a good production, I volunteered my time to a theater company for years. You can see the work put into the productions, the lighting is perfect, actors know their lines, timing is rehearsed, everyone understands their cues and the audience leaves believing something meaningful happened on stage. The problem arises when incident response begins to resemble a performance rather than a capability. When teams are more focused on following the script than understanding the environment and the current attack. When the goal becomes executing the playbook instead of responding to reality.
I was able to relay a story from earlier in my career, from an experience that I was asked to help on (not a company I worked directly for). The organization had a well documented incident response plan, their roles were clearly defined, their legal team knew when to engage, they already had their communications team pre-written statements, just waiting for minor tweaks. The security team even ran quarterly tabletop exercises with everyone to prepare. On paper, it was textbook. Then the inevitable happens, and a real incident occurred. Alerts started firing, but not in a neat, linear way. They were scattered. Some looked benign. Some were ambiguous. Some did not map cleanly to any of the predefined scenarios in the playbook. The team did what they were trained to do. They followed the documented steps. They escalated according to the matrix. They updated the ticket. They scheduled status calls.
What they did not immediately do was step back and ask a more fundamental question. What is actually happening in our environment right now?
Situational awareness is the ability to perceive what is going on, understand what it means, and anticipate what might happen next. It is not the same as having logs. It is not the same as having alerts. It is not the same as having a binder labeled Incident Response Plan on a shared drive. It is the difference between reacting to isolated signals and seeing the full picture.
Think about every disaster movie ever made, I’m sure you’ve seen at least a few (guilt pleasure of mine). There is always a control room filled with blinking lights and people confidently announcing that systems are stable. Then someone notices a small anomaly. A temperature reading that is slightly off. A radar blip that does not fit the pattern. The people who save the day are rarely the ones reciting procedures. They are the ones who connect the dots.
In cybersecurity, those dots are often subtle. A login from a new geography that is technically allowed. A service account accessing a system it has never touched before. A spike in outbound traffic that does not cross a predefined threshold. None of these, on their own, necessarily trigger a crisis. But together, they might tell a very different story.
Leaders sometimes assume that incident response maturity is about speed. We track this metrics…”Mean time to detect” (MTTD), “Mean time to respond” (MTTR), “Mean time to contain” (MTTC), they’re in most of our metrics we hold or present…and those metrics have value. They provide insight into operational efficiency, but speed without understanding can create false confidence and you can respond very quickly to the wrong problem.
I have seen teams isolate a single compromised workstation with impressive efficiency, only to discover days later that the attacker had already established persistence elsewhere and now the attacker knew the jig was up. The playbook was followed and the infected device was re-imaged..even the report was written. Everyone moved on. Yet, unbeknownst to them the real story was unfolding in the background.
This is where situational awareness intersects with asset management, architecture, and governance. You cannot understand what is happening during an incident if you do not know what you own. You cannot assess impact if you do not understand data flows and system dependencies. You cannot make informed containment decisions if you do not know which systems are critical to the business. Incident response does not live in isolation. It is deeply connected to the foundational disciplines that often receive less attention because they are not as dramatic.
It makes me think of a tabletop another story I was told about that perfectly captured this tension. The scenario involved ransomware spreading across a portion of the network. The team walked through their documented steps. Disconnect affected systems. Notify leadership. Engage forensics. Draft external communications. Everything progressed smoothly in the simulation. At the end, someone asked a simple question. “Which business processes would actually stop if these servers went down?” Silence. The technical response was polished. The business impact was unclear. That is not a tooling issue, there is no software that you can buy to solve this…this is a situational awareness gap.
Situational awareness also requires psychological safety for the responders…teams must feel comfortable saying, “I do not think this fits the script.” If your organizational culture rewards strict adherence to process over critical thinking, your incident response will default to just theater. Your team will follow the checklist even when the checklist does not align with reality. Don’t forget that leaders (on every level) set the tone here. Do you encourage curiosity and challenge during an incident, or do you prioritize order and predictability above all else?
The uncomfortable truth is that no incident response plan survives first contact with a real adversary unchanged. It shouldn’t survive any real test and not change after you go over lessons learned. That is not a failure of planning, it is a reflection of complexity, adversaries always adapt, your environments evolve constantly and cloud architectures shift. Even your remote or hybrid work expands and changes attack your surfaces. The idea that a static document can anticipate every variation is optimistic at best (and I’m being generous).
This is why continuous improvement is not optional. After action reviews should not be box checking exercises…they should be honest conversations about what was not seen, what assumptions were made, and what blind spots were revealed. The most valuable question after an incident is often not, “Did we follow the plan?” but “What did we miss?”
Leaders should also resist the temptation to equate heavy investment in tools with strong situational awareness. Detection platforms, endpoint protection, and security information systems are powerful, but they are only as effective as the context around them. Logs without understanding are noise and alerts without prioritization are distractions I always tell people that data without interpretation is just the same as those blinking lights in a control room in disaster movies.
The real maturity indicator is whether your team can articulate how systems connect, where sensitive data resides, what normal behavior looks like, and how anomalies are identified in context. That requires cross functional alignment. It requires collaboration between security, IT, operations, and business units. It requires leadership that values clarity over comfort.
Incident response without situational awareness is theater because it prioritizes performance over perception. It rewards visible action over informed decision making. It creates the appearance of control without necessarily reducing uncertainty.
As leaders, our responsibility is to ensure that incident response is not just a script, but a living capability grounded in understanding. That means investing in foundational visibility. It means challenging metrics that emphasize speed over insight. It means fostering a culture where people are encouraged to connect dots rather than simply check boxes.
The next time you review your incident response program, do not just ask whether the plan exists. Ask whether your team truly understands the environment it is meant to protect. Ask whether they can describe not just how to respond, but what they are responding to. Ask whether your dashboards reflect context or just activity.
Because when the real incident arrives, no one in the room will care how clean the script looked. They will care whether you saw what was happening clearly enough to act wisely.
The difference between theater and resilience is situational awareness. And that difference is ultimately a leadership decision.