[DEMO] Everyone Thinks They Know Who's in Charge During an Incident. More Than Half Are Wrong.

There is a particular kind of chaos that only appears during a live incident.

Not the chaos of detection. Not the chaos of containment. The chaos that comes when four people are on a call, all of them qualified, and nobody is sure who gets to make the call.

That moment — quiet, awkward, expensive — is where most incident response breaks down.

Not at the technical layer. At the human one.

90% of senior cybersecurity leaders report feeling confident their teams know who's in charge during a crisis. Yet 54% of those same leaders say that who actually makes decisions frequently changes mid-incident.

That gap — between confidence before and reality during — is the defining leadership problem in incident response right now.

41% of senior cybersecurity leaders have delayed response actions during a crisis specifically because of uncertainty about who had final authority.

Delay is not a neutral outcome. Every hour of ambiguity is an hour the attacker retains access, lateral movement continues, and containment becomes harder.

The plan didn't fail. The leadership structure failed.

Most organisations have an incident response plan. Many of them are well-written.

They describe phases: detect, contain, eradicate, recover. They reference frameworks. They include contact lists and escalation thresholds.

What they rarely describe clearly is this: who has the authority to stop a system, override a business unit's objection, authorise external communications, or call in legal?

Without clear management and executive commitment, incident response teams are unable to fully commit to fighting cyberattacks — sometimes needing to forego day-to-day responsibilities in the process.

That executive commitment isn't just about budget. It's about pre-authorised decision rights. The difference between a team that acts and a team that waits for approval is whether approval has already been granted, in writing, before anything happens.

1. The technical-to-business handoff

Early in an incident, security operations owns the room. Detection, triage, initial containment — these are technical decisions.

At some point, the incident crosses a threshold and becomes a business decision. A system needs to be taken offline. A customer notification may be required. Legal and communications need to be pulled in.

Most plans don't define that threshold clearly. The handoff happens informally — usually when someone escalates loudly enough — and the team loses an hour working out who should be driving.

2. The executive who joins late

An executive joins the incident call two hours in. They have authority. They don't have context. They start asking questions that have already been answered.

Misalignment during incident response brings key players — including legal, communications, and executives — to the table too late, causing internal friction and delay.

The fix isn't keeping executives off calls. It's briefing them to a defined standard before they join. A one-page situation summary, updated every 30 minutes, that gets pushed to leadership regardless of whether they've asked for it.

3. Legal's arrival

When legal joins an incident, the tone of the room changes.

Suddenly, questions that were operational become questions of liability. Decisions slow down. People stop documenting things they were previously documenting.

Legal is an essential part of incident response. But their role needs to be defined in advance — what they're there to advise on, what they're not there to block, and how their input integrates with the response timeline rather than pausing it.

4. Communications under pressure

Companies are often judged less on the scope and impact of an incident and more on how they handle it.

External communications are often the last thing to get a clear owner. Internal updates to staff, external statements to customers, regulatory notifications, media — the who, what, and when of each type of communication needs to be clearly outlined in the response plan.

When it isn't, the default is silence. Silence reads as confusion. Confusion costs trust in ways that persist long after the technical incident is closed.

74% of CISOs plan to increase annual budgets for cyber crisis simulations in 2025, driven largely by watching real incidents expose the gaps that exercises were supposed to catch.

That's the right instinct. But most tabletops are designed to test the plan, not the leadership.

They run through the technical scenario. They tick the phases. They rarely put a senior leader in the room and ask them to make a real-time call with incomplete information while someone else in the room disagrees.

The most useful tabletops I've seen do three things differently:

1. They simulate information asymmetry. Different people in the room receive different information — just like in a real incident. Nobody has the full picture. Decisions still have to be made.
2. They test the handoff moments explicitly. Not just "what do you do when you detect ransomware?" but "at what point does this stop being a security decision and become a business decision, and who makes that transition call?"
3. They debrief on authority, not just actions. After the exercise, the most valuable questions are about hesitation: where did people wait instead of act, and why?

The answer is almost always the same. They weren't sure it was their call to make.

Here is the reframe that changes how this gets built.

Incident response is usually treated as a process design problem. Build the right phases, document the right contacts, run the right exercises.

Incident leadership is a structural design problem. It requires pre-assigned authority, defined handoff points, briefed executives, and a communication cascade that doesn't depend on whoever shouts first.

Incident response is no longer a contingency plan — it's a core business function. That shift in framing matters. Core business functions have owners. They have defined escalation paths. They get resourced accordingly.

A response plan that hasn't resolved the question of who gets to say stop is not a plan. It's a document that will be set aside the moment the pressure is real.

If your incident response program has one open problem worth closing before anything else, it's this:

Write down, in a single page, who has final authority at each phase of an incident — detect, contain, eradicate, recover, communicate. Name a person, not a role. Get that person's acknowledgment. Share it with everyone who might be on a call at 2am.

That page will do more work than most playbooks three times its length.

Because the technical response is almost never the reason incidents spiral.

It's the five minutes of silence when nobody moves, because nobody is sure the call is theirs to make.