How to Run a BCP/IR Tabletop
(Without Losing the Room)

// 01 — SCOPE

Know what kind of tabletop you're actually running

This sounds obvious, but a lot of tabletops fail before they even start because nobody defined the scope. An Incident Response tabletop and a Business Continuity tabletop are testing two different things, and mixing them up without realizing it is how you end up with a room full of confused people.

IR tabletops are technical. You're testing detection, containment, eradication, and recovery from a security incident — ransomware, a breach, an insider threat, whatever fits your risk profile. The audience is usually IT, security, and maybe legal and comms.

BC tabletops are operational. You're testing how the business keeps functioning, or recovers, when something takes out a location, a system, a vendor, or a critical process. The audience is much wider, and that's exactly why BC tabletops are harder to run. You're not just talking to security anymore — you're talking to facilities, HR, finance, ops, and department heads who've never heard the word "RTO" in their life.

A combo scenario, where a cyber incident triggers a business continuity response, is honestly one of the more realistic exercises you can run, because that's how most real-world incidents actually play out. Just know going in that it takes more coordination.

// 02 — OBJECTIVES

Define your objectives before you touch a scenario

Don't start by writing a scenario. Start by asking what you're actually trying to test. Are you validating an IR plan that hasn't been touched in two years? Are you testing whether your BC plan's RTOs are realistic? Are you checking if people even know their role during a crisis? Write this down. Your objectives are what determine everything else — your scenario, your injects, who needs to be in the room, and what "success" looks like when this is over.

If you skip this step, you'll end up with a tabletop that feels like a story time session instead of an actual exercise. Fun, maybe, but useless when it comes to producing real data.

// 03 — SCENARIO

Build a scenario that's actually relevant to your org

Generic scenarios are the fastest way to lose the room. If you hand a manufacturing company a scenario about a cloud SaaS outage, don't be surprised when engagement tanks — nobody in the room can relate to it. The best scenarios are grounded in your actual environment: your systems, your locations, your vendors, your industry's threat landscape.

This is also where a lot of facilitators get stuck, because building a good scenario from scratch takes real research. You need to understand what's actually threatening your industry right now, not what was relevant a few years ago when the last template was written. If you don't have the bandwidth to build this out yourself, industry-standard templates like CISA's Cybersecurity Tabletop Exercise Package (CTEP) library are a solid starting point you can adapt instead of starting from a blank page.

// 04 — INJECTS

Write injects that force decisions, not just discussion

An inject is basically a new piece of information you drop into the exercise to move the scenario forward: a new system going down, a reporter calling for comment, a vendor confirming they were also breached. Good injects force participants to make a decision under pressure. Bad injects just give people more to talk about without actually testing anything.

A good rule of thumb: if your participants can respond to an inject with "yeah, we'd probably just wait and see," that inject isn't doing its job. Rewrite it so it forces action.

// 05 — PARTICIPANTS

Get the right people in the room

This is where BC tabletops especially tend to fall apart. If you're testing a business continuity plan and only IT shows up, you're not actually testing anything. You need representation from every function the scenario touches, and more importantly, you need people who actually have decision-making authority — not just someone sent to take notes.

Send out a pre-read before the exercise. Give people just enough context to show up prepared without spoiling the scenario. Cold-opening a tabletop on a room full of people who have no idea what's about to happen is a great way to get silence instead of participation.

// 06 — FACILITATION

Run the exercise and actually facilitate it

Facilitating is a skill, and it's different from just reading a script out loud. Your job during the exercise is to keep momentum going, pull quieter departments into the conversation, and stop any one person or team from dominating the room. If you notice a department going quiet, that's usually not because they don't care — it's because the scenario hasn't touched their world yet, or they're not sure their input is welcome. Call on them directly.

Keep time. Tabletops that run long lose energy fast, and by the end you're getting rushed, low-quality responses just so people can leave. Better to run a tight 90 minutes with good engagement than a bloated three hours where everyone checks out halfway through.

// 07 — CAPTURE

Capture everything, not just what you remember

This is the step everyone underestimates. If you're not capturing responses, decisions, and gaps in real time, you're relying on your memory and some scattered notes to write up the after-action report later — and that report is going to be worse for it. Track who said what, what gaps came up, what assumptions got challenged, and what decisions took longer than they should have.

This is the actual value of the exercise. The conversation in the room is temporary; the data you capture from it is not.

// 08 — FOLLOW-UP

Turn it into lessons learned, not just a filed report

The exercise isn't done when the room clears out. The real value comes from what happens next: turning your notes into concrete lessons learned, assigning action items to actual owners, and setting a timeline to follow up. If your "lessons learned" document is really just a summary that gets emailed out and never opened again, you haven't closed the loop.

Track it somewhere visible — a kanban board, a shared tracker, whatever keeps it in front of people — and revisit it before your next exercise so you're not solving the same gap twice.

// 09 — AUDIT TRAIL

Keep an audit trail

If you're in a regulated industry or working toward SOC 2, PCI DSS, or similar frameworks, your auditors are going to want proof this actually happened and wasn't just a checkbox. That means sign-in sheets, tracked responses, and a documented lessons learned process — ideally all in one place so you're not scrambling to piece it together from three different tools when audit season hits. See our compliance overview for how exercise reports map to common frameworks.