How to Run a Ransomware Tabletop Exercise for a Small Business in 90 Minutes

Most small businesses have some kind of incident response plan. Far fewer have ever said it out loud with the people who would actually use it. A tabletop exercise fixes that. You get the owner, the office manager, whoever handles IT (in-house or MSP) and the person who talks to customers into one room, read them a realistic ransomware story one piece at a time, and write down every place where they hesitate.

You don't need a consultant, a lab or a full afternoon. This guide shows you how to run one in 90 minutes, and it includes a complete sample scenario you can use as-is.

What a tabletop is (and what it isn't)

A tabletop exercise is a facilitated discussion. Nobody touches production systems. The facilitator presents an "inject", a new development in the story, and the group talks through what they would do, who decides, and how they would know.

It is:

• A safe, no-blame way to test plans, decision rights and contact lists
• Cheap evidence that you practice, which insurers, auditors and larger customers increasingly ask about
• A source of a short, prioritized list of fixes

It isn't:

• A test of individuals or a performance review
• A penetration test or a live restore
• Finished when the meeting ends. The fixes are the point.

Before the session: 30 minutes of prep

1. Pick a sponsor. The owner or a senior manager opens the session and receives the findings. Without a sponsor, people skip it or treat it as an IT meeting.

2. Pick 5 to 8 participants. For a small business that usually means:

• Owner or general manager (business decisions, payments, legal contact)
• IT lead or MSP contact (technical response)
• Finance or bookkeeping (payroll, invoicing, bank contacts)
• Office or operations manager (staff communication, phones, facilities)
• Whoever handles customers or marketing (external messages)

3. Assign three roles that aren't players:

• Facilitator: reads injects, asks questions, keeps time. Ideally someone who won't be answering.
• Scribe: records decisions, owners, open questions and gaps.
• Timekeeper: can be the facilitator, but a visible timer helps.

4. Gather what people would really reach for: the incident response plan (even if it's two pages), the cyber insurance policy and its claims hotline, the list of critical systems, backup details, and the staff and vendor contact list. Print them. If something doesn't exist, that's your first finding.

5. Tailor the scenario. Replace the bracketed names below with your real systems. A scenario that says "the file server" lands better when it says "the Q: drive on SRV-01".

The 90-minute agenda

Read these ground rules aloud at the start:

1. No fault, no blame. We are testing the plan, not people.
2. Answer with the tools, people and authority you have today, not what you wish you had.
3. Decisions don't have to be perfect. Make a call and say why.
4. Don't fight the scenario. If a detail doesn't fit, we'll adjust it and move on.
5. Findings are reported without names attached.

Free sample scenario: "The Friday Invoice"

This scenario is written for a 10 to 50 person business using a cloud email suite, a shared file server or NAS, and an accounting system. Adjust the details to fit.

Starting assumptions (read aloud): It's an ordinary Friday. The office closes at 5 p.m. Backups run nightly. The IT person or MSP is reachable by phone. Nobody has reported anything unusual this week.

Inject 1: Friday, 4:40 p.m.

The bookkeeper mentions that an "invoice" email from a regular supplier had a link that opened a page asking her to sign in again. She did, then the page went blank. She shrugged and went back to work. Ten minutes later, two staff report that files on the shared drive have strange extensions and won't open.

Discussion questions:

• Who is the first person told, and how? Who is told second?
• What is the very first technical action? Who is allowed to take it?
• Do we disconnect anything right now? What exactly, and who decides?
• The bookkeeper's account may be compromised. What do we do with it in the next 15 minutes?

What good looks like: someone clearly owns the call to isolate affected machines. The suspected account gets its password reset and its sessions revoked. Somebody starts a written timeline. The IT contact is reached by phone, not email.

Inject 2: Friday, 6:15 p.m.

A ransom note appears on the file server and on three desktops. It claims the attackers copied "all finance and HR data" and will publish it in 72 hours unless paid. The office is closed and most staff have gone home.

Discussion questions:

• Who do we call now: the insurer's hotline, a breach coach, an incident response firm, the police? In what order? Where are those numbers written down?
• Does anyone have the authority to engage outside help that costs money tonight?
• Who decides whether paying is even on the table, and who must be consulted first?
• What do we tell staff who will arrive on Monday?

What good looks like: the insurer is contacted early, because many policies require notice and sometimes require using approved vendors. Nobody contacts the attackers without legal and insurer guidance. Evidence is preserved rather than wiped in a rush to rebuild.

Inject 3: Saturday, 10:00 a.m.

The IT lead reports that last night's backup job ran at 11 p.m., after the encryption started, and the backup target was a network share that is now encrypted too. The cloud backup has a copy from Thursday night, but nobody has ever restored more than a single file from it.

Discussion questions:

• How long would a full restore from the Thursday copy take? Has anyone ever measured it?
• What do we restore first? Who decided that order, and is it written down?
• Which systems can the business live without for a week? Which ones for a day?
• How do we make sure we aren't restoring onto machines the attacker still controls?

What good looks like: the group agrees on a recovery order based on business impact, such as accounting, email and then file shares. Someone notes that restore time is unknown and adds a test restore to the action list. Rebuilding is held until the entry point is understood.

Inject 4: Monday, 8:30 a.m.

A customer calls the front desk. They received an email from your bookkeeper's address asking them to update the bank details for your invoices. A local reporter has also emailed asking for comment about "a data leak".

Discussion questions:

• Who speaks for the company, and what do they say? Is a holding statement ready?
• How do we warn customers about the fraudulent bank-details request without causing panic?
• Who checks whether any payments were already redirected?
• Do we have notification obligations to customers, employees or regulators? Who would know?

What good looks like: one spokesperson. A short holding statement that says only what is known and avoids claims you can't support yet, such as "no data was accessed". A call to the bank. A plan to contact legal counsel about notification duties.

Sample holding statement (adapt it and have counsel approve before use):

"[Company] is responding to a cybersecurity incident affecting some of our systems. We acted quickly to contain it and are working with specialists to restore services safely. If you receive any request to change our payment details, please call us on a number you already have before acting. We will contact anyone directly affected."

Facilitation tips that make the difference

• Read, then wait. Silence is uncomfortable. Let it work. Don't answer your own questions.
• Push for specifics. "Who exactly? How would you reach them at 9 p.m. on a Friday? Where is that number written?"
• Add friction if it's too easy. "The IT person is on a flight." "The owner's phone is the compromised device."
• Bring quiet people in. Ask finance and the front desk directly. The best findings often come from them.
• Park rabbit holes. Write deep technical debates on a parking-lot list and move on.

The hot wash (15 minutes)

Ask these five questions and have the scribe capture the answers:

1. What worked well that we should keep?
2. Where did we hesitate, and why?
3. What information did we need but couldn't find?
4. Which decisions had no clear owner?
5. If this happened tomorrow, what one thing would we want fixed first?

Turning findings into action

The exercise is only worth the fixes it produces. Within a week, write a one-page after-action summary:

• Date, scenario and participants (roles, not names, if you prefer)
• Top 3 to 5 findings, each written as a gap: "No one knew the insurer's claims hotline number."
• One action per finding, with an owner and a due date
• When you'll check progress, for example at 30 and 90 days

Typical first-exercise actions for small businesses:

• [ ] Print an emergency contact sheet (IT, MSP, insurer hotline, bank, counsel) and store it offline Before the exercise, confirm that you can still sign in if your admin accounts are locked or compromised. A documented break-glass account procedure makes that scenario quick to test.
• [ ] Do a full test restore of one critical system and time it
• [ ] Keep at least one backup copy that is offline or immutable, not just a network share
• [ ] Write down who can approve emergency spending and engage outside responders
• [ ] Prepare a holding statement and name one spokesperson
• [ ] Add a "call to confirm" rule for any change to payment details
• [ ] Turn on multi-factor authentication for every email account, starting with finance and admins

Run another exercise in six months with a different scenario, such as a compromised cloud account or a supplier outage. Compare your scores. Getting better is the evidence.

Resources: Free M365 + Google Workspace hardening checklist · Full kit with 3 scenarios, a slide deck and an after-action template: Ransomware Tabletop Exercise Template ($49; code LAUNCH30 takes 30% off paid kits through Oct 31, 2026). I make these templates.

Drafted with AI assistance and reviewed for accuracy.

Not affiliated with Microsoft or Google.