The Incident Isn’t the Emergency. The Next 30 Minutes Are.
Every incident response plan looks great in the binder. Then something actually happens at 2 a.m., the person who wrote the plan is on vacation, nobody can find the conference bridge, and the CEO is texting the CTO directly asking if “we’ve been hacked.” That gap — between the plan and the panic — is where incidents go from bad to catastrophic. I’ve been in that room. The binder does not save you. What saves you is what people already know how to do before anyone opens it.
The incident itself is rarely what sinks you. It’s the first thirty minutes of confusion: who’s in charge, what do we actually know versus what are we guessing, who do we tell, and what do we very much not say yet. I’ve watched a minor, containable event become a company-defining crisis purely because nobody knew who was allowed to make a decision — so nobody made one, and the window to contain it quietly closed while smart people waited for permission.
Name the incident commander before you need one
The single most important control in those first minutes isn’t technical. It’s a clear answer to “who is running this?” One person, empowered to make calls, whose job for the duration is to hold the whole picture and decide — not to do forensics, not to write the customer email, just to command. Everyone else has a lane. Without that, you get the worst possible pattern: five senior people all half-leading, all deferring to each other, all assuming someone else has the thing that’s actually on fire.
And critically, the incident commander is a role, not a person — because the actual person will be asleep, on a plane, or already underwater on something else. I want three people who can step into that seat and a dead-simple way to hand it off. The teams that handle 2 a.m. well are the ones where the answer to “who’s in charge?” takes zero seconds, at any hour, on any day.
Separate what you know from what you fear
Early in an incident, information is garbage. Half of what comes in during the first twenty minutes turns out to be wrong — the “confirmed breach” that was a misconfigured alert, the “we’re fine” that wasn’t. The discipline I try to enforce is a hard line between confirmed facts, working theories, and pure fear, and never letting the third category drive irreversible decisions. Announcing a breach you haven’t confirmed, wiping a system you needed for forensics, calling customers about a problem that turns out to be nothing — those are the mistakes made in the fog, and they’re expensive to walk back.
Practice the argument before you have it
This is why I’m relentless about tabletop exercises — not the box-checking kind, the uncomfortable kind. Put the actual executives in a room, hit them with a realistic scenario, and watch what breaks. Something always breaks. The legal team and the security team disagree about disclosure. Nobody’s sure who signs off on paying a ransom. The comms lead and the CISO have opposite instincts about what to tell customers and when. Far better all of that surfaces in a conference room than in production, with the clock running and a reporter already calling.
The teams that handle incidents well aren’t the ones with the thickest binder. They’re the ones who already had the hard conversations — about disclosure, about legal exposure, about who talks to the press — before the pressure was real. When it’s live, they execute muscle memory instead of inventing a process and re-litigating old disagreements under the worst possible conditions.
Decide the disclosure questions on a calm day
Some of the highest-stakes calls in an incident aren’t technical at all — they’re about who you tell and when. Regulators, customers, partners, law enforcement, the board, the public. Those decisions have legal and regulatory clocks attached, and they’re miserable to reason about for the first time at 3 a.m. with adrenaline running. So I want the framework decided in advance: what triggers notification, who owns each conversation, what our default posture is. You’ll still tailor it to the real event, but you’re adjusting a plan instead of writing one from scratch while the building is metaphorically on fire.
Calm is a control
The most underrated incident capability is a leader who stays calm and makes the room calm. Panic is contagious, and it makes people do dumb, irreversible things — wiping the systems you needed for forensics, tipping off the attacker that you’ve seen them, telling customers something you’ll have to retract next week. Honestly, half my job during a live incident is just lowering the temperature so people can think clearly, because clear thinking is the scarcest resource in the room and the easiest one to lose.
None of this makes incidents pleasant. They’re still bad days. But the difference between a bad day and a company-defining catastrophe is almost never the sophistication of the attack. It’s whether, in those first thirty minutes, someone was clearly in charge, the team knew the difference between what they knew and what they feared, and the hard conversations had already happened. Build that, drill it, and you turn the worst nights into something your team can actually execute — instead of something that executes them.