Can a small business run a tabletop exercise without a security team?

Yes. A tabletop is a structured conversation, not a technical test, so you need the people who would make decisions in a real incident rather than security specialists. The owner or manager, whoever handles finance, whoever looks after IT (in-house or your IT provider) and someone who deals with customers are enough. A ready-made scenario and 60 to 90 minutes will do the rest.

How often should a small business do a tabletop exercise?

Once a year is a sensible baseline for most small businesses, plus a short session whenever something significant changes: a new IT provider, a move to new systems, new staff in key roles or a near-miss such as a convincing fake invoice. If you handle card payments, PCI DSS expects your incident response plan to be tested at least every 12 months.

What is the best first scenario for a small business tabletop?

Business email compromise is usually the best starting point. It is common, it needs no technical background to discuss, and it tests the controls that matter most to small firms: how payments are approved, how bank details changes are verified and who to call at the bank when money has gone. Ransomware is a good second exercise once basic roles are clear.

Should our IT provider or MSP take part in the exercise?

Ideally yes, at least for part of it. Many small businesses discover in the exercise that they do not know what their IT provider actually covers out of hours, how quickly they respond or whether they restore from backups. Inviting them turns assumptions into facts. If they cannot attend, send them your questions beforehand and bring their answers.

Tabletop Exercise for Small Business: A Low-Budget Guide

A tabletop exercise for a small business is a 60 to 90 minute meeting where four to six people talk through a realistic cyber incident, step by step, and agree what they would do. You do not need a security team or special software: just the people who make decisions, a written scenario and someone to keep time.

The point is to find the gaps while it is cheap to fix them. Who rings the bank if a payment goes to a fraudster? Where is the IT provider's emergency number if email is down? Does the cyber insurance policy require you to call them before anyone else? A single morning answers questions like these, and it costs nothing but time.

Why small businesses benefit most

Larger organisations have incident-response teams, documented plans and people whose job is to think about this. Small businesses usually have a manager who also does finance, an IT provider on a support contract and a vague sense that "the backups are fine". That makes the handful of decisions in the first hours of an incident even more important, because there is nobody else to catch mistakes.

A tabletop also forces conversations that never happen otherwise. The owner learns what the IT provider does and does not cover. The bookkeeper learns that the bank has a fraud line that works on weekends. Everyone learns where the contact list is, or discovers there is not one.

Who plays what when people wear several hats

In a small business, one person often holds several roles. That is fine, but name the roles explicitly so the exercise shows where one person becomes a bottleneck. The roles guide goes into more depth; for a small business this is usually enough:

Role in the exercise	Who typically plays it	What they decide
Incident lead	Owner or general manager	Declares an incident, makes the big calls, keeps a log
Finance and banking	Owner, bookkeeper or office manager	Stops payments, calls the bank, contacts the insurer
IT and systems	In-house IT person or the MSP's account manager	What is affected, what can be switched off, restoring from backups
Customers and communications	Sales lead, office manager or owner	What to tell customers, suppliers and staff
Facilitator	A trusted outsider, an adviser or a manager who will not play	Reads the scenario, releases updates, keeps time
Note-taker	Anyone not playing a key role	Writes down decisions, questions and gaps

If the owner plays incident lead and finance at the same time, watch what happens when both jobs need doing at once. That is a finding in itself: perhaps someone else needs authority to call the bank.

Try not to let the owner facilitate. They are the person whose decisions you most need to test.

Using your IT provider, insurer and bank

Most small businesses rely on outside help in an incident, so the exercise should test those relationships as much as your own team.

Your IT provider or MSP. Before the exercise, ask them: what are your response hours and times? Do you handle security incidents or only IT support? Do you hold our backups, how often are they taken, and when did you last test a restore? Who is our named contact out of hours? Invite them to the session if possible. If not, bring their answers.

Your cyber insurer. If you have a cyber policy, read the claims section before the exercise. Many policies have an incident hotline and require you to notify them promptly, and some require you to use their approved response firms. Put the hotline number in the scenario packet and see whether anyone thinks to call it.

Your bank. Find the fraud reporting number for business accounts and check whether it is staffed out of hours. In a payment fraud scenario, speed matters, and a tabletop is the right place to learn that the number on the website goes to a general enquiries line.

Five scenarios that fit small businesses

Pick one for your first exercise. Each links to a full scenario you can simplify: keep the objectives and the key decision points, cut the injects to four or five, and replace names with your own systems and suppliers.

1. Business email compromise

A supplier's "new bank details" email looks genuine, and a payment has gone out. Or an email that appears to come from the owner asks the bookkeeper to pay an urgent invoice. This is the most practical first scenario for most firms. It tests payment approval, bank-detail verification and how quickly you can reach the bank. See the business email compromise scenario.

2. Ransomware

On Monday morning, nobody can open files on the shared drive and a ransom note appears on screen. It tests whether backups really work, who can tell staff to stop using computers, what the IT provider does first and how you keep trading. See the ransomware scenario and cut it down to the first four injects.

3. Lost or stolen laptop

A salesperson's laptop is taken from a car. Was it encrypted? What customer data was on it? Can it be wiped remotely? Do you have to report it under data-protection law? See the lost laptop scenario.

4. Email or account takeover

Someone's email account is taken over after a phishing message, and it starts sending invoices to customers. It tests password resets, multi-factor authentication, how you warn customers and who checks what else the attacker accessed. See the phishing and credential theft scenario.

5. Website or domain outage

Your website stops loading and email bounces, because a domain registration lapsed, a registrar account was hijacked or the site is under a flood of traffic. Who owns the registrar login? Is it tied to a former employee's personal email? How do customers reach you in the meantime? The DDoS scenario covers the traffic-flood variant; for the domain variant, write two or three injects of your own around losing control of the registrar account.

What to have ready before the exercise

Treat this checklist as both preparation and a first set of findings. Anything you cannot find now, you would not find during a real incident either.

An offline contact list. Printed or on a personal phone: staff, IT provider, insurer hotline, bank fraud line, accountant, solicitor, key customers and suppliers. If it only lives on the email system, it will not be there when email is down.
Cyber insurance details. Policy number, claims hotline and any requirement to notify before acting.
Bank fraud contact. The direct number for business account fraud, and who in your team is authorised to call.
Backup facts. What is backed up, where, how often, and when a restore was last tested. "The IT company does it" is not an answer yet.
Admin account list. Who holds the master logins for email, the domain registrar, the website, accounting software and banking.
Data you hold. A rough idea of what personal and payment data you keep, and where. You will need it to judge whether a breach must be reported. Under GDPR, notifiable personal-data breaches go to the supervisory authority within 72 hours of becoming aware, where feasible.
Any written plan. Even a single page. If there is nothing, the output of this exercise will become your first plan.

A one-page agenda for 90 minutes

This fits a business email compromise or ransomware scenario with four to six players. For a 60-minute version, drop inject 4 and shorten the wrap-up.

Time	Segment	What happens
0:00	Welcome	Why we are doing this; ground rules: no blame, no wrong answers, phones down
0:05	Roles	Confirm who plays which role and who is facilitating and taking notes
0:10	The situation	Facilitator reads the opening scenario aloud
0:15	Inject 1: First signs	Something odd is reported. Who hears about it, and what do they do?
0:30	Inject 2: It is real	The incident is confirmed. Who is in charge? Who do we call first?
0:45	Inject 3: Money or data at risk	Bank, insurer, IT provider decisions; do we need to tell anyone officially?
1:00	Inject 4: Customers notice	A customer calls; staff ask questions. What do we say?
1:10	Wrap-up	What went well, what surprised us, three things to fix
1:25	Actions	Each fix gets an owner and a date

If people are remote or you want a record without a dedicated note-taker, the free exercise runner lets the facilitator send each update to players' phones and collects their responses as you go.

Keeping it low-cost and useful

Use a ready-made scenario. Writing one from scratch is the part that takes longest. The scenario library and CISA's free exercise packages are good starting points. Adapt rather than invent.
Keep it short. Ninety minutes in a meeting room beats a full day that never gets scheduled.
Make it specific. Use your real supplier names, your real bank, your real IT provider. Generic scenarios produce generic answers.
Write down gaps, not grades. Nobody is being tested. The note-taker records what was unclear, who was missing and what information nobody could find.
Fix three things. Do not try to fix everything. Pick the three most important gaps, give each an owner and a date, and check them a month later.

What to do after the exercise

Within a week, write up a single page: what the scenario was, what went well, what gaps you found and the actions agreed. A full after-action report format exists if you want it, but one page is fine for a small business.

Typical first-exercise actions look like this:

Gap found	Action	Owner	Due
Bank fraud number not known	Add it to printed contact list and phones	Office manager	1 week
Nobody sure if IT provider handles security incidents	Ask provider in writing; update contract if needed	Owner	1 month
Supplier bank details changed by email with no check	Introduce call-back verification on a known number	Bookkeeper	2 weeks
Registrar login tied to former employee's email	Move to a shared company account with MFA	IT provider	2 weeks

Then book the next exercise. Once a year is a sensible baseline, with an extra session after big changes such as a new IT provider. If you take card payments, PCI DSS requirement 12.10.2 expects the incident response plan to be reviewed, updated and tested at least once every 12 months, and a documented tabletop is a common way to show that.