Your Incident Response Plan Has Never Been Tested

An incident response plan isn't a compliance artifact, a binder, or a file in SharePoint that somebody wrote in 2021. Or rather, it can be all three - and if it is, it's a document, not a plan.

A tabletop exercise is a discussion-based rehearsal in which the people who would actually respond to an incident sit in a room, work through a realistic scenario out loud, and discover which parts of the plan don't survive contact with reality. Nobody touches a system. Nothing is simulated technically. It's a conversation, and it's the cheapest security control available to a small business.

NIST defines it the same way in SP 800-84, *Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities*: tabletop exercises are "discussion-based exercises where personnel meet in a classroom setting or in breakout groups to discuss their roles during an emergency and their responses to a particular emergency situation." NIST calls them "cost-effective tools to validate the content of IT plans, such as contingency plans and incident response plans, to ensure the plan content is viable and implementable in an emergency situation," and puts typical duration at two to eight hours.

You can get most of the value in forty-five minutes.

Why does an untested plan fail?

Because plans fail on the things nobody thought to write down, and only a rehearsal surfaces those.

The failure is never "the plan was wrong about the technical steps." It's smaller and more human than that. The plan names a role that no longer exists because that person left. It says "contact the insurance carrier" without a policy number or an after-hours claims line. It assumes the owner will decide, and the owner is on a plane. It lives on the file share that just got encrypted.

Every one of those is invisible on paper and obvious within ten minutes of a conversation. That's the whole mechanism: a tabletop doesn't test whether people know the plan. It tests whether the plan contains the things people will need, and it does it by asking a question and watching the room go quiet.

The silence is the finding. When you ask "who calls the insurance carrier, and what's the number" and five people look at each other, you've just learned something you'd otherwise learn at 8:40 on a Tuesday morning during the worst week of your year.

Do the rules require you to test it?

Less than you've probably been told, and I want to be precise about this because it gets overstated constantly in this industry.

The FTC Safeguards Rule does not require you to test your incident response plan. 16 CFR 314.4(h) requires a written plan addressing seven specified areas - goals, internal processes, roles and decision authority, communications, remediation requirements, documentation and reporting, and "the evaluation and revision as necessary of the incident response plan following a security event." That last item is reactive. It's a post-incident review, not a test. The testing obligation in the Safeguards Rule lives in (d)(1) and applies to safeguards generally, not to the IR plan. Anyone telling you the Safeguards Rule mandates an annual tabletop is overstating the text.

HIPAA's testing requirement is Addressable, not Required, and it attaches to the contingency plan. Under 45 CFR 164.308(a)(7), the data backup plan, disaster recovery plan, and emergency mode operation plan are Required. "Testing and revision procedures" is Addressable - you assess whether it's reasonable and appropriate, and if you conclude it isn't, you document that reasoning and implement an equivalent alternative. Note also that HIPAA handles security incident procedures separately, at 164.308(a)(6). So "HIPAA requires you to test your incident response plan" isn't accurate as usually stated.

There's a pending change worth tracking: HHS published a proposed rule on January 6, 2025 that would convert addressable specifications to required, including contingency plan testing. It has not been finalized. Don't plan around it as though it's in force.

Where the requirement actually bites is your insurance application. Chubb's cyber proposal form asks whether you have "a formal cyber-specific incident response plan that is tested at least annually." That's a yes-or-no question on an attestation, and "we have a plan" is not a yes to it. See our article on what cyber insurance carriers actually ask.

Which is the honest summary: the regulators mostly don't require a tabletop. Your carrier asks about one, your customers' security questionnaires ask about one, and reality will test it whether or not you do.

What does a tabletop actually look like?

Four rounds, escalating from mechanics to the questions people avoid.

Round one - the first fifteen minutes. Who has authority to declare an incident? What's the very first action? Who disconnects what? Who calls your IT provider, and what if they don't answer? What do you tell staff who can't work?

Round two - the calls you have to make. Who notifies the insurance carrier, with what policy number, on what line, and how fast does the policy require it? Do you have counsel, and do they do breach work? What do customers get told, by whom, and when? Can you verify your backups are intact and uninfected? Can you operate manually while systems are down, and for how long?

Round three - the hard ones. Who decides on ransom payment, and with whom in the room? What data was involved, and does that trigger a notification obligation? Who talks to the press or posts publicly? What's the plan at day five, day ten, day thirty?

Round four - write it down. Who attended. Which questions nobody could answer. Which phone numbers nobody had. Which assumptions turned out to be wrong. Then three corrective actions, each with an owner and a due date.

Round four is the one that gets skipped and the one that produces all the value. An exercise with no documented outputs is a good conversation. An exercise with three assigned actions is a control.

CISA publishes its own materials for this if you want more, including over a hundred Tabletop Exercise Packages with scenarios, discussion questions, slide decks, and after-action report templates - ransomware among them.

How often should you run one?

Often enough that the answers stay current, which for most small businesses means once a year plus after anything significant changes.

NIST's guidance in SP 800-84 is to conduct exercises "periodically; following organizational changes, updates to an IT plan, or the issuance of new TT&E guidance; or as otherwise needed." Notably, NIST does not specify an annual cadence, so I won't claim it does. The triggers that matter in practice are the ones in that list: someone in a named role leaves, you change IT providers, you move a major system, or you renew a policy with new attestations.

The second run is always faster and less useful than the first, which is the point. The first one finds a dozen gaps. The third one finds two, and that's what progress looks like.