Most small businesses have some version of an incident response plan. Maybe a document a consultant wrote three years ago, a page in the handbook, or an unspoken understanding that somebody will call the IT company. On paper that looks like coverage. In practice, a plan you have never used is not a plan. It is a hypothesis.

A tabletop exercise tests that hypothesis cheaply. You put the right people in a room for about 90 minutes, describe a bad day out loud, and walk through what each person would actually do. No systems get touched. Nothing breaks. What you get is a list of the things nobody had thought about, found on a Tuesday afternoon instead of at 2 a.m. during a real outage. We run these with clients, and the useful discovery is almost never technical. It is that two people each assumed the other was calling the bank.

A Tabletop Is a Conversation, Not a Technical Test

The National Institute of Standards and Technology puts it plainly. In Special Publication 800-84, its guide to test, training, and exercise programs for IT plans, NIST describes tabletop exercises as “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.” The same publication notes a tabletop is “discussion-based only and does not involve deploying equipment or other resources.”

That distinction matters. When owners hear “exercise” they picture a penetration test on live systems. Different animal, much bigger invoice, and not where most businesses should start. A tabletop costs a conference room and everyone’s attention.

NIST Special Publication 800-84 puts senior-level tabletops at typically two to four hours. For a company of 20 to 200 people, we think 90 minutes is the right first dose: long enough to get past the easy answers, short enough that people show up. You do not have to build the scenario yourself, either. The Cybersecurity and Infrastructure Security Agency describes its free Tabletop Exercise Packages as “a comprehensive set of resources designed to assist stakeholders in conducting their own exercises,” each containing “template exercise objectives, scenarios, and discussion questions.”

Who Needs to Be in the Room

This is where most tabletops go wrong. Companies invite the technical people and nobody else, then congratulate themselves on a plan that only works if IT is awake, available, and not the department that got locked out. The decisions that stall a real response are business decisions.

  • The owner or a senior decision maker. Someone has to authorize spending money, taking systems offline, or telling clients. Without that person you are rehearsing a play without the lead.
  • Whoever runs finance. Payroll, wire approvals, and vendor payments are where an incident turns into a loss.
  • The person who talks to clients. They will be fielding questions within an hour of anything becoming public.
  • Operations or office management. They know what the front desk does when the phones and the CRM are both down.
  • Your IT provider. That is us, or whoever fills the role. We should be in the room, not reading a summary afterward.
  • One or two people who do the work. The dispatcher, the technician, the person in accounts payable. They surface the workaround nobody documented.

A Scenario You Can Run Next Month

A good scenario is boring and plausible. It should feel like a Monday. Read each step out loud, then let the room work it through. Do not supply the answers.

  1. 7:40 a.m. Your bookkeeper cannot open the accounting file. The office manager cannot open the shared drive. Both assume a network hiccup and keep trying.
  2. 8:15 a.m. A text file appears on two desktops with instructions and an email address. What happens in the next five minutes, and who makes that call?
  3. 9:00 a.m. A client asks why she received an invoice from you with different bank details. She has not paid it yet. Who responds, and what do they say?
  4. 11:00 a.m. Backups exist. Nobody can say when a restore was last tested or how long one takes. Payroll runs Wednesday.
  5. 2:00 p.m. Your insurance carrier wants a written timeline, and asks whether you engaged anyone before their approved vendor.

The Questions That Expose the Gaps

The scenario is just a delivery mechanism. These questions earn the 90 minutes. Write down every answer that starts with “I think” or “probably.”

  • Who declares an incident? Not who notices it. Who has authority to say “we are now in response mode,” and what happens if that person does not answer?
  • Who calls the insurance carrier, and with what policy number? Many cyber policies require prompt notice and have opinions about which vendors you may use. Calling the wrong firm first can create a coverage argument later.
  • Who talks to clients, and who does not? Silence is a decision. So is an employee posting a vague apology online. Name one spokesperson and tell everyone else what to say.
  • Where are the backups, and when did someone last restore from them? “We have backups” and “we have tested restores” are different sentences. Only one is comforting.
  • What if the person who knows is on vacation? Pick whoever everyone depends on. Remove them from the scenario. Watch what happens.
  • How do we communicate if email and the file server are down? CISA addresses this in its Incident Response Plan Basics guidance, advising organizations to “print these documents and the associated contact list and give a copy to everyone you expect to play a role in an incident,” because “your internal email, chat, and document storage services may be down.”

If those questions feel uncomfortable, the exercise is working. The alternative is finding the same gaps while the clock is running. We wrote more about why this planning work moved from optional to expected in why cybersecurity is no longer optional for mid-sized businesses.

Capture the Findings, Then Do It Again Next Year

A tabletop that produces good conversation and no follow-up is entertainment. NIST Special Publication 800-84 calls for an after action report capturing “comments that surface during the debrief, along with lessons learned.” You do not need a formal document. You need a list that survives the week ahead.

  • Write findings as sentences, not topics. “Backups” is not a finding. “Nobody can state our restore time for accounting” is a finding.
  • Give every action exactly one owner. Two owners means no owner. Use a name, not a department.
  • Put a date on it. Most tabletop items are 30-day items, not projects.
  • Separate cheap fixes from real projects. Printing a contact card takes an afternoon. Rebuilding backup architecture is a budget conversation. Do not let the second block the first.
  • Read last year’s list first. This habit does more for follow-through than any tracking software.

Annual is the right cadence. Staff changes, systems change, and the plan drifts out of date quietly. Tie the exercise to insurance renewal or budget season and it stops being an event you keep postponing.

The Bottom Line

A tabletop is the cheapest security work you will do all year, because it costs almost nothing and it tells you the truth. It will not stop an attack. It will shorten the gap between “something is wrong” and “here is what we are doing,” and that gap is where most of the damage accumulates. Ninety minutes, once a year, with the non-technical people in the room. Incidents at large, well-resourced companies keep proving the point, as we covered in what the Stryker cyberattack tells us about the threats facing every business.

If you want help facilitating one, we do this for Denton County businesses regularly. We build the scenario around your systems, run the room, ask the awkward questions so you do not have to, and hand you a findings list with owners and dates. Contact us today.


Sources:

Comments are closed

This website uses cookies and asks your personal data to enhance your browsing experience. We are committed to protecting your privacy and ensuring your data is handled in compliance with the General Data Protection Regulation (GDPR).