Before I built security programs, I was in the Army. Nobody in the military asks you to hope a mission goes well. You rehearse it. You assign a role to every person on the team. You know exactly what happens the moment the first plan doesn't hold. That's the discipline most incident response plans are missing.
I review a lot of these plans now, usually in a discovery call with a business owner who's never actually had someone sit down and look at what they've got. Most of what I find isn't a plan. It's a folder with a network diagram in it and a hope that nothing bad happens.
Preparation is a discipline, not a document. Here are the six things I actually check when I sit down with a client's plan, and where I usually find the gaps.
1. Who's actually in charge when something breaks
In the Army, everyone knows their lane before anything happens. Nobody's improvising who's in charge mid-crisis. The business version of that is just as simple: does everyone already know, without a debate, who makes the call, who talks to your team, who works with your IT provider, and who calls your customers and vendors?
- Who makes decisions when the person who'd normally decide isn't reachable
- Who communicates with employees so people hear one message, not three different guesses
- Who works with your IT provider so technical decisions don't wait on someone finding the right person
- Who communicates with customers and vendors so the outside world hears from you before they hear rumors
I've watched three well-meaning people email the same customers with three different messages, because nobody had actually decided who owns that job. That's not a technology failure. That's a planning failure, and it's the first thing I check.
2. A contact list that's actually current
This sounds too basic to matter, until it's late on a Saturday and nobody can put their hands on the number for your cyber insurance carrier or the vendor who manages your payment system.
- Internal leadership — the people who need to know first
- Your IT provider — not a general support line, a real point of contact
- Software vendors tied to the systems you can't operate without
- Your cyber insurance provider — most policies have notification windows, and missing one can affect a claim
- Legal counsel and key business partners who need to be looped in early, not last
A missing vendor number or an outdated contact doesn't sound like a big deal until it's the reason recovery stalls for an hour. I check whether this list actually gets updated, or whether it was accurate the day someone built it and hasn't been touched since.
3. A way to talk to each other when your usual tools are down
Email and chat are often the first things to go offline in an incident, which is exactly when you need to reach people the most.
- Internal communication that doesn't depend on the systems that might be affected
- Employee notification steps so your team hears from you directly, fast
- Customer communication expectations so people hear something accurate, even if it's just 'we're on it'
- Vendor communication so outside partners aren't left guessing either
Silence is what erodes trust fastest, both within a business and among the customers who depend on it. I'm less concerned with the specific tool you use as a backup and more concerned that you've actually picked one before you need it.
4. A ranked list of what actually needs to come back first
Not every system deserves the same amount of attention during recovery. For most of the businesses I work with, that's payment processing, email, and the website, not necessarily every internal tool in the building.
- Critical applications your business genuinely can't operate without
- Essential processes tied directly to revenue or customer service
- Recovery priorities in a specific, agreed-upon order
- Acceptable downtime for everything that isn't on that list
Without this, teams try to bring everything back at once, and that spreads people too thin to fix anything well. Ranking this ahead of time is one of the simplest things a business can do, and one of the most commonly skipped.
5. Steps your team can follow without calling me first
Under pressure, people need direction they can act on immediately, not a document written for someone else's job title.
- Initial response actions anyone on the team could follow
- Escalation steps that say exactly when and how to bring in outside help
- Recovery priorities that match what you ranked in the last step
- Decision-making steps for the calls that can't wait for a meeting
I write these for the person who'll actually be standing there when it happens, not for another IT professional. If a step needs a technical translator to be useful at 2 am, it's not ready yet.
6. A plan that gets tested, not just filed
A plan you've never tested is a theory. Systems change, vendors change, people change roles, and a plan built even a year ago can be quietly out of date without anyone noticing.
- Review procedures on a set schedule, not whenever someone remembers
- Update contact information every time something changes
- Test recovery steps for real, not just read them
- Evaluate what you learned after every test and every real incident
Testing is where I find the gaps that look fine on paper and fall apart the moment there's a real clock running. It's also the only way your team gets comfortable enough with the plan to actually use it.
Be ready before it happens.
The most effective incident response plans aren't built during a crisis. They're built ahead of time, by people willing to look honestly at what they don't have yet.
I won't quote you fixed-scope work on a plan I haven't actually seen. That's why every engagement starts with a real conversation about what you've got today, not a canned proposal built off a guess.
If you're not sure your incident response plan would hold up, let's find out together. Schedule a 15-minute discovery call, and I'll tell you straight where the gaps are.
Dean Lause | CEO, Argentum IT
Argentum IT — Veteran Owned and Run
