A cyber tabletop exercise is a facilitated, discussion-based walkthrough of a realistic cyber incident — your team talks through how they’d respond, step by step, while a facilitator throws in complications. No real systems are touched, no production data is at risk. For the price of a couple of hours in a room, it’s the cheapest, highest-value security exercise an SME can run.
Most businesses buy controls and assume they’d cope on the day. A tabletop tests the assumption before an actual attacker does. It exposes the awkward gaps — who decides whether to pay a ransom, where the offline contacts list lives, whether anyone has actually read the cyber insurance policy — while the cost of finding out is a meeting, not a disaster.
What a tabletop exercise actually is
The format is deliberately low-tech. You gather the right people in a room, present a plausible incident, and walk through the response as a guided conversation. The facilitator describes the scenario, reveals new information at intervals (“injects”), and asks decision questions at each turn: What do we do now? Who makes that call? Who do we have to notify, and by when?
Nothing is simulated technically. You’re not unplugging servers or launching a fake phishing campaign — that’s a live or red-team exercise, a different and more expensive thing. A tabletop tests your decisions, your roles, your communications and your documentation. It answers the question that controls alone never do: when something goes wrong at 4:45pm on a Friday, does this team actually know what to do?
That’s why it sits at the top of the value-for-money list. A penetration test tells you whether attackers can get in. A tabletop tells you whether you can respond once they have. We cover the testing side in our piece on penetration testing; this is the other half of the picture.
Why it’s the best-value exercise you can run
Three reasons. First, cost: the only real input is people’s time, usually 90 minutes once or twice a year. No tooling, no consultants required for a first pass. Second, breadth: in one session you stress-test your incident plan, your decision-making, your notification obligations and your backups all at once. Third, it surfaces the failures that genuinely sink SMEs — not technical zero-days, but the human and process gaps. Nobody knew who could authorise a payment hold. The disaster recovery plan referenced a staff member who left in 2022. The “current” backup hadn’t been test-restored in eighteen months.
Those are the things that turn a manageable incident into a week of chaos, and a tabletop finds them in an afternoon.
Who should be in the room
The single biggest mistake is treating a cyber incident as an IT problem and inviting only IT. A real incident is a business event with legal, financial, operational and reputational consequences. The people who’ll actually make the decisions on the day need to be the people in the exercise.
- Owner or managing director — the person who ultimately decides whether to pay, to go public, to pull systems offline. Their absence is the most common reason a tabletop is toothless.
- Operations — they understand what the business can and can’t run without, and what “down for a day” actually costs.
- Finance — for ransom and fraud scenarios especially. They hold the payment controls and know the bank relationships.
- IT or your MSP — to speak to containment, recovery, what’s logged and what can realistically be restored, and how fast.
- Communications or whoever fronts customers — staff, clients, suppliers and possibly media all need handling, and silence is its own decision.
For a small business these might be five people wearing seven hats, and that’s fine. The point is to have every function represented, not to fill seats.
How to run one
1. Pick a realistic scenario
Choose something that could plausibly happen to your business, not a Hollywood cyber-war. The four that matter most for Australian SMEs:
- Ransomware — files encrypted, a ransom note, operations halted.
- Business email compromise (BEC) payment fraud — a supplier’s “updated bank details” email that diverts a real payment.
- A stolen or lost laptop — a device with mailbox and file access gone from a cafe or car.
- Microsoft 365 account takeover — a phished login giving an attacker access to mail, files and Teams.
Rotate the scenario each time. Don’t run ransomware every year and call it covered.
2. Inject complications
The scenario shouldn’t unfold cleanly. Part-way through, the facilitator reveals a twist: the backups are also encrypted; the one person who knows the firewall is on a plane; a journalist has already called. Injects are where comfortable plans fall apart and the real learning happens.
3. Ask decision questions and capture gaps
At each stage, push for specifics. Who makes this call? Who do we legally have to notify, and within what window? Where’s our offline list of contacts if email and Teams are down? The facilitator’s job is to record every “we’re not sure” and “we’d have to check” — those uncertainties are the output. A scribe writing down each gap and unanswered question is what turns the session into something actionable.
A sample 90-minute agenda
| Time | Segment | What happens |
|---|---|---|
| 0–10 min | Set-up and ground rules | No blame, no “right” answers, phones down. Confirm everyone’s role for the day. |
| 10–25 min | Scenario reveal | Facilitator presents the incident. Initial reactions and first moves discussed. |
| 25–55 min | Injects and decisions | Two or three complications introduced. Group works through containment, notification, recovery and communications. |
| 55–75 min | Recovery and aftermath | How do we get back to normal? Notifications, insurer, customers, lessons. |
| 75–90 min | Debrief and gaps | Walk the captured list. Agree owners and dates for each fix. |
A sample scenario you can run
Here’s one a real Melbourne SME could use verbatim. A manufacturing business in Dandenong arrives Monday to find production-planning files won’t open and a ransom note demanding payment in cryptocurrency sits on the shared drive. Staff can’t process orders.
Work through it: Who’s leading the response? Do we shut down the network to contain it? Inject one — IT reports the most recent backup ran successfully but has never been test-restored, so nobody can confirm it works. Inject two — a production supervisor mentions they reused their work password on a personal site that was breached last year. Inject three — a key customer rings asking why their order is late, and a second emails asking if their data is safe.
Now the hard questions. Do we engage our cyber insurer before doing anything, given the policy may require it? Does this trigger the Notifiable Data Breaches scheme, and who assesses that? Who tells staff what they can and can’t say? You’ll likely find at least three things nobody had a confident answer for — which is exactly the point.
Turning findings into actions
A tabletop that ends with a nice discussion and no follow-up was a waste of an afternoon. Before everyone leaves, every gap on the list needs an owner and a date. “Build an offline contact sheet — Ops, two weeks.” “Test-restore the backups quarterly — MSP, ongoing.” “Add a verbal-confirmation rule for any bank-detail change over $5,000 — Finance, this week.” We feed these straight into a remediation plan, and the most valuable ones usually point at controls: multi-factor authentication everywhere, conditional access, tested backups. Those tie into the work we describe in our guides on conditional access in Microsoft 365 and recovery time and recovery point objectives.
The second run, six to twelve months later, should open by checking off the previous list. That closed loop — find, fix, verify — is what separates a business that’s genuinely ready from one that merely owns an incident response plan.
How often to run one
Annually as a baseline, and again after any major change: a new core system, a merger or acquisition, a shift to a new cloud platform, or significant staff turnover in the key roles. A plan written around last year’s team and last year’s systems quietly goes stale. An annual rhythm keeps it current and keeps the muscle memory warm.
How it satisfies insurers and Essential Eight expectations
This isn’t only good practice — it increasingly maps to what insurers and frameworks expect. Cyber insurance applications and renewals now routinely ask whether you have an incident response plan and whether you test it. “Yes, and we run a tabletop annually” is a materially stronger answer than a dusty document, and it can shape both whether you’re covered and what you pay. We unpack this in our cyber insurance guide for Australian SMEs.
On the framework side, the Australian Cyber Security Centre (ACSC) builds the Essential Eight around technical mitigations, but the higher maturity levels and the broader ACSC guidance assume you can actually respond to and recover from an incident — tested backups, a workable plan, and people who know their roles. A tabletop is how you prove the human side of that holds together, not just the technical controls. It’s the rehearsal that makes the documentation real.
Frequently asked questions
How long should a tabletop exercise take?
90 minutes to two hours is the sweet spot for an SME. Long enough to work through a scenario and a few injects properly, short enough that busy decision-makers will actually commit the time. Anything under an hour rarely gets past the obvious; anything over half a day usually means too many people or too broad a scope.
Do we need an external facilitator?
Not for your first one. A capable internal lead or your MSP can run it from a prepared scenario. An independent facilitator earns their keep later, because they ask the uncomfortable questions an internal person might smooth over, and they can play injects without the group seeing them coming.
What’s the difference between a tabletop and a real simulation?
A tabletop is a discussion — you talk through decisions, nothing technical happens. A live simulation or red-team exercise actually executes attacks or recovery steps against real systems. Tabletops are cheaper, lower-risk and where every business should start; simulations come later, once the basics are solid.
Who should facilitate if the MD needs to be a participant?
Whoever facilitates should stay neutral and not be a decision-maker in the scenario, so the MD participates rather than runs the session. That’s a common reason businesses bring in their MSP or an external facilitator — it frees the leadership team to actually make the calls.
Where to start
You don’t need a budget or a consultant to begin. Pick one scenario from this post, block 90 minutes, get the right five people in a room, and walk it through. Capture every gap and assign an owner before you leave. That single session will tell you more about your real readiness than any amount of policy documentation.
If you’d rather have it facilitated properly — a tailored scenario, sharp injects, and a remediation plan you can actually action — that’s part of what we do. TechAssist is a Melbourne-based MSP founded in 2014, with 13 Australian-employed engineers and a 24/7 NOC in Tecoma, and we run tabletop exercises as part of our cybersecurity services. Get in touch and we’ll help you rehearse the bad day before it arrives.