Every incident response training says the same thing. Move fast. Contain the threat. Get ahead of the story before someone else tells it for you. All of that is correct. None of it explains why the calls I am proudest of during an active incident were the ones I made a beat slower than my instinct wanted.
Speed is not free
I move fast by default. I see a pattern and I want to act on it immediately. Early in my career that read as an advantage. Most of the time it was… until the moment it wasn’t.
I’ve made a call mid-incident that looked like containment on paper and still left a threat actor holding valid, unrotated credentials in the one place we assumed was covered. We’d changed the lock on the front door and left the side door on the original key.
That trade never makes it into the after-action report. Fast feels like control in the moment. Sometimes it’s just motion.
Build the pause into the process, not the person
You cannot fix this by telling people to have better instincts under pressure. Instincts do not improve at 2am during an active incident. What works is a forced checkpoint built into the playbook itself, a step that exists specifically to slow the fastest person in the room down before an irreversible action gets taken.
Confirm the scope before you isolate anything, and confirm the action cannot be undone before you take it. If a regulator needs to be notified, that decision gets a named second signer, not a solo call at 2am. Write the checkpoint down with an owner attached, not a line in a document nobody reopens after the tabletop.
I have run tabletop exercises where the entire team can recite the technical steps cold and still skips this exact checkpoint, because skipping it feels like progress, which is exactly the problem. That’s the same instinct that let “we rotated the password” pass for “the threat actor is out,” wearing a different incident number this time.
It shows up everywhere, not just at 2am
Once you notice this pattern in incident response, you see it in every rushed decision a security program makes. A board approves an AI tool the same week someone demoed it in a meeting. A bank signs a vendor contract on the strength of a SOC 2 report and a good sales call, because the alternative is a longer procurement cycle nobody wants to own.
The instinct behind both is the same one that isolates the wrong network segment during an incident: something looks like the right move, so take it now and figure out the guardrail later if there’s time.
There usually isn’t time later. A guardrail added after the decision is a lessons-learned document. A guardrail built before the decision is a control, and only the second one does anything the next time someone is moving fast.
The pause is a control
I still move fast. That hasn’t changed, and I don’t think it should. What changed is that I stopped treating the pause as a personal weakness to manage and started treating it as a control, the same as any other one I’d put in a security program on purpose. You write it down, you assign an owner, and you test it in the tabletop instead of skipping to the part everyone already knows how to do.
If your incident response plan or your vendor and AI approval process doesn’t have a forced pause written into it as a named step, fix that before your next decision gets made under pressure. Book a call if you want help building it in: https://cal.com/vaughn-cyber-group
