Every fire gets a commander. Most breaches don't.

Command was built, not assumed

Walk up to a working structure fire and the chaos is real: multiple crews, mutual aid from other jurisdictions, an unclear building layout, live risk of collapse. Decades ago the fire service ran into that chaos without a shared structure, department by department, until multi-agency incidents made it clear that improvised command does not scale. What replaced it, the Incident Command System, is not a slogan. It is a small number of hard rules, applied the same way every time, regardless of how large the incident is or how many agencies show up.

Four of those rules matter here.

Unity of command.

One person is the Incident Commander. Not a committee, not whoever arrived first, not a rotating consensus. One name, on the record, until the incident ends or command is formally transferred to someone else.

Span of control.

A supervisor manages a small number of people directly, not the whole roster on scene. When an incident grows past what one person can track, the structure splits into sections instead of stretching one commander thinner.

Explicit role assignment.

Before anyone advances on the fire, someone is on search, someone is on ventilation, someone is on water supply, someone is outside the structure accounting for who is inside it. The roles exist whether or not this specific fire needs all of them, and everyone on scene knows which one they are holding.

A spoken situation report on a cadence.

Command gives and gets a status update at fixed intervals, not only when something breaks. The update states conditions, actions taken, and what is needed next, and it goes out whether or not there is dramatic news to report.

None of this is about heroics. It is about making sure that when the building is on fire, the answers to who decides, who is doing what, and what the current state is, never depend on who happens to be standing closest to the radio.

What the SOC has instead

A security operations center has alerts. It has a queue, a SIEM, a SOAR platform doing some of the correlation, and analysts working through whatever lands in front of them. What it usually does not have is a fireground.

There is no equivalent of unity of command inside a live incident. Escalation authority is implicit: whoever picked up the ticket decides how serious it is, and a decision to isolate a system or notify the business gets argued over in a chat thread until enough people agree, which is consensus wearing the costume of process. There is no enforced span of control: one analyst can be carrying a dozen open tickets of wildly different severity with no structural trigger that says this is too many, split the load. There is rarely explicit role assignment: the person doing containment, the person talking to legal, and the person keeping the timeline are often the same tired analyst, or nobody at all until someone remembers to ask. And there is no situation report cadence: incidents get updates when something changes, which means long silent stretches where nobody outside the SOC, including the people who will eventually have to explain the incident to the board, has any real idea what is happening.

None of this is because security people are less disciplined than firefighters. It is because the discipline was never built into the structure. The fire service treats command as an engineering problem with a designed answer. Security has largely treated it as a personality problem, solved by hiring calm people and hoping the process holds under pressure.

Four things to build, not four things to buy

The fix is not a new tool sitting on top of the SIEM. It is the same four rules, ported.

Name the incident commander before the incident, not during it.

Every declared security incident above a defined severity gets one named IC, decided by a rotation the team agreed on in advance, with the standing authority to make the call on containment and notification without waiting for a chat thread to reach agreement. The IC role is separate from the technical lead doing the actual work, exactly as it is on a fireground, because the person best placed to do the technical work is rarely the person who should be deciding whether to pull the plug.

Cap how much one person is allowed to run.

Decide, in writing, how many concurrent incidents or how much severity one on-call responder can carry before a second person is pulled in automatically. This is a structural trigger, not a judgment call made mid-incident by someone who is already stretched thin and poorly placed to notice it.

Write down the roles before the drill, not during the real thing.

Containment, communication to the business, evidence and timeline, and coordination with legal are four different jobs. They do not have to be four different people on a small incident, but they have to be four things someone consciously picked up, not four things that happened to get done, or didn't.

Put a sitrep cadence in the runbook and enforce it.

Every fifteen or thirty minutes, however the team decides, the IC states current status, actions taken, and what is needed next, whether or not there is news. The habit is what matters. A team that only reports up when something dramatic happens is a team the business hears from at the worst possible moment, with the worst possible framing.

None of this requires new headcount. It requires deciding, ahead of time, who holds authority and how information moves, so the first ten minutes of a real incident are spent executing a plan instead of negotiating one.

The building doesn't wait for consensus

Firefighters do not debate the org chart while the roof is failing. The structure was decided the day the department was built, and it activates the moment the alarm comes in. Security incidents run on the same kind of clock, whether anyone treats them that way or not. The difference is that most SOCs are still working out who is in charge after the alert has already been open for an hour, which is the one thing a fire commander never has to do on scene. Fix the command structure before the next incident, and the next incident gets shorter, because the first move is action instead of a search for a decision-maker. Fix it during the incident, and the timeline reads the way most breach timelines already do: hours lost not to the attacker, but to finding out who was supposed to be in charge.