An incident response plan that nobody has rehearsed is a document, not a capability. The first time you discover that the person who can disable an integration is on leave, or that nobody knows who decides whether to tell customers, should not be during a real breach. A tabletop exercise lets you find those gaps with coffee instead of consequences.

What a tabletop is

It’s a facilitated discussion, not a technical drill. A small group sits together, a facilitator reads out a scenario in stages, and the participants say what they would do at each stage. Nobody touches a keyboard or disconnects anything. The point is to test decisions, communication and handoffs.

You can run a useful one in two to three hours with the people you already have. It complements your written playbook; if you haven’t written one, the exercise will show you what it needs.

Pick the right people

Include those who would actually be involved:

• The CRM administrator
• Someone from security or IT
• A sales leader and a support leader, who understand customer impact
• Legal, privacy or compliance, even if it’s an outside adviser on call
• Communications or whoever speaks to customers
• An executive with authority to make decisions

A common trap is inviting only technical staff. Real incidents stall on non-technical questions: who approves a customer notice, who talks to the press, who can authorise paying for outside help.

Build a realistic scenario

Start from something plausible for your business. For a CRM, good options include a salesperson’s account used to export the customer list, a connected app that was compromised, a mailbox rule diverting customer replies, or a departing employee who emailed themselves a report. Write the scenario in three or four “injects,” each adding a complication:

1. Detection. A manager reports that a rep’s account made a large export overnight.
2. Scope. The logs suggest the export included contact details and deal notes, but you can’t yet say how many records.
3. Pressure. A customer emails asking why they received a suspicious message that quotes details from a recent call.
4. Decision. A journalist or a customer asks for a statement, and a regulator may need to be told.

Keep the facts generic and clearly hypothetical. You are not trying to catch anyone out.

Run the session

Assign a facilitator who doesn’t play a role in the response, and a note-taker. Then:

• Read the first inject and ask each role what they do in the first thirty minutes.
• Press gently on specifics. “We’d contain it” isn’t an answer; “I would end the session and revoke the token, and I know where that setting is” is.
• Ask who decides, who is told, and where the contact details are.
• Introduce each next inject only after the current one is worked through.
• Allow disagreement. It shows you where the plan is ambiguous.

Keep the tone blameless. If people feel they’re being tested, they’ll say what sounds right rather than what would really happen.

What you’re listening for

Question	Good sign	Gap to fix
Who can contain the incident?	Named people with the access to act	Only one person, or nobody knows
Where are the logs?	Known location and retention	Logs roll off before anyone looks
Who decides on notifying customers or authorities?	Defined decision-maker and advisers	Debate with no owner
How do we talk without using the compromised system?	Alternate channel agreed	Everyone uses the affected email
How do we preserve evidence?	Step in the plan	Reset first, ask questions later
Who handles outside help?	Contacts and approval route ready	Searching for numbers in the moment

After the session

Within a few days, write up a short list of actions, each with an owner and a date. Resist producing a long report nobody reads. Typical outputs are: update the contact list, add a step to preserve logs before resetting accounts, agree a template holding statement, and confirm who holds the break-glass administrator account. Then schedule the next exercise, perhaps with a different scenario, and check that the previous actions were done.

A hypothetical example

A small company runs its first tabletop with six people. The scenario is a suspicious overnight export from a sales account. Within twenty minutes the group realises that only one person knows how to revoke API tokens, and she is on holiday next week; that the customer-notification decision has no owner; and that the logs available in the CRM go back a shorter period than anyone assumed. None of this required a breach to discover. Their action list has five items, including training a deputy admin, naming a decision-maker with a backup, and exporting logs to longer storage. They repeat the exercise six months later with a different scenario, and the answers come faster.

Frequently Asked Questions

How often should we run a tabletop? Once or twice a year is a common rhythm, and after major changes such as a new CRM, a merger or a significant integration. Pick a schedule you will keep.

Do we need an outside facilitator? Not for a first session. An internal person who isn’t involved in the scenario can run it. An outside facilitator can add experience and challenge once you have the basics down.

Should the scenario involve actual personal data? No. Use invented details. The exercise is about decisions and process, not real records.

What if we don’t have an incident response plan yet? Run the exercise anyway, with a one-page outline of roles and contacts. The gaps you find become the draft plan.

Do legal notification duties get decided in the exercise? You can discuss who decides and what questions to ask, but actual obligations vary by jurisdiction and circumstance. Involve qualified legal or privacy advisers to establish them.

Next Step

Put a three-hour slot in the diary for next month, invite the six roles above, and write just the first inject of a scenario. You can draft the other three in the week before the session.