By now, most firms know the FTC’s 30-day clock: unencrypted data, 500 consumers, thirty days from discovery, no extensions for a still-open investigation. What almost no firm has actually done is rehearse what happens in the room when that clock starts. A tabletop exercise is a discussion-only walkthrough of a specific breach scenario, run with your actual team, before a real incident forces everyone to improvise for the first time during a busy time of the year. Here’s how to run one.
Key takeaways
- A tabletop exercise is entirely discussion-based. No live systems, no real alerts, just a facilitator walking the team through a scenario out loud.
- Pick one specific, realistic scenario and stick to it. A stolen laptop and a ransomware-locked file server force completely different decisions.
- Assign roles before the exercise starts: who leads, who talks to the client, who contacts counsel, who’s actually filing the FTC report.
- The facilitator’s real job is introducing complications mid-exercise, not reading a script. That’s where a plan’s gaps actually show up.
- Debrief immediately afterward and update your WISP’s incident response section while what didn’t work is still fresh, not weeks later.
Table of Contents
What a tabletop exercise actually is
A tabletop exercise is a discussion-based walkthrough of one specific incident, run in a conference room with no live systems involved. A facilitator presents a scenario, and the team talks through, out loud, exactly what they’d do and in what order.
That’s a different thing from having a written incident response plan, and it tests a different question. A written plan proves the steps exist on paper. A tabletop exercise proves the people who’d actually execute those steps understand them the same way, under time pressure, before the moment they’d need to. Plenty of firms have a plan nobody’s ever actually walked through, and the gap between those two things usually isn’t visible until the first real incident makes it visible the hard way.
Picking a scenario worth running
The scenario that’s actually useful feels realistic, closely resembles what your firm could plausibly face, starts small, and escalates until it needs more than whoever’s in the room can handle alone.
For a tax firm, three scenarios do most of the work, and they force genuinely different decisions:
| Scenario | The decision it forces |
|---|---|
| A staff laptop with client files is stolen | Was the drive encrypted? That single fact decides whether this even triggers the FTC’s 30-day clock |
| A phishing email compromises a staff email account | You often don’t know what was actually accessed, only what the account could reach |
| Ransomware locks the file server mid-week | Do you pay, restore from backup, or do both fail because the backup was never tested |
Run one scenario per session, not all three. A tabletop exercise that tries to cover everything ends up rehearsing nothing specifically, and the value comes from working through one situation in enough depth that the team hits real decision points, not from surveying every possible incident in the abstract.
Assigning roles before you start
Roles get assigned before the exercise starts, not improvised once it’s underway. At minimum: someone leads the response, someone talks to the client, someone contacts counsel, and someone is responsible for actually filing the FTC report.
For a tax firm, most of these map directly onto roles the FTC Safeguards Rule already assumes exist. The qualified individual named in your WISP is a natural fit for incident lead. Whoever handles client relationships is the obvious choice for client communication, since that conversation has to happen whether or not the technical picture is fully clear yet. And someone specific needs to own the mechanics of the FTC filing itself, since the deadline runs from discovery regardless of how the investigation is going. Deciding this in the exercise, ahead of time, is the entire point. Deciding it during a real incident means it doesn’t get decided at all until someone finally asks.
Where the exercise actually earns its keep
The facilitator’s actual job is introducing new complications at intervals, called injects, not narrating a script from start to finish. A well-designed inject sequence keeps the group from solving the scenario too early and forces the same kind of pressure a real incident would.
For the stolen-laptop scenario, a useful inject sequence might look like: the laptop turns out not to have had full-disk encryption enabled after all, despite what the team assumed. A client calls on day three asking directly whether their return was affected, before anyone’s confirmed what data was actually on the device. The firm’s cyber insurance carrier asks for documentation of the incident response plan being followed, not just that one existed. Each of those is a moment where a real firm would have to make a decision on the spot, and running into it during a rehearsal is a much better place to discover a gap than running into it for real.
After the exercise: closing what you found
Debrief right after the exercise ends, while what didn’t work is still fresh, and feed it directly into your WISP’s incident response section. A tabletop exercise that doesn’t change the plan afterward was just a meeting.
Keep the debrief simple: what did the team get right, where did people hesitate or disagree about who owned a decision, and what did the exercise assume the firm had in place that it actually doesn’t. Every WISP built to IRS Pub 4557 and the FTC Safeguards Rule already needs a written incident response plan as one of its required sections. Running a tabletop exercise once or twice a year is what keeps that section describing how your firm would actually respond, rather than a version written once and never checked against reality.
Talk to us about building your firm’s incident response plan →
