Business Continuity Tabletop Exercise: A 90-Minute SMB Test

A continuity plan on paper tells you very little. What matters is whether people can make sound decisions when they only have half the facts. A tabletop exercise is a cheap way to find out before an internet outage, a cyber incident, or a vendor failure does it for you.

Nobody has to configure a firewall under pressure. You're all sitting around a table (or a video call) talking through who decides, what work carries on, what stops, how people communicate, and what has to be true before things go back to normal.

For a Toronto or GTA small business, 90 minutes is usually enough to turn up missing contacts, unclear authority, manual processes that don't work, and dependencies nobody knew about.

Pick One Scenario With a Real Business Consequence

Don't try to test every possible failure in one sitting. Choose one situation that would interrupt an important workflow on an ordinary workday. Some starting points:

• The office loses its main internet connection during a busy period
• A suspicious sign-in or compromised mailbox needs immediate containment
• Your phone provider or a key cloud application is down
• A ransomware alert hits a shared file location
• Nobody can get into the building because of a power or building problem

Describe it in business terms. "What if the firewall fails?" leads to a technical debate. "How do customers reach us, how do we process orders, and who can approve a change to the usual process?" gets you the decisions you came for.

Invite the People Who Own Decisions

IT alone isn't enough. Bring a small group who can speak for the work that would be affected:

• A business lead who can set recovery priorities
• The IT owner or managed service provider who knows the systems and escalation paths
• Owners of customer service, finance, operations, or other critical workflows
• Someone who can approve staff and customer updates
• A note-taker to record decisions, assumptions, and follow-ups

If one person wears several hats, say so at the start. The point is to settle who has authority before someone has to use it in a hurry.

A 90-Minute Agenda

Keep the pace brisk enough to show gaps, without drifting into a theory workshop.

1. Set the scene (10 minutes)

State the scenario, the time of day, the affected service, and what is known. Separate what's confirmed from what's only suspected. Name a facilitator and make it clear that no production systems will be touched.

2. Walk the first decisions (25 minutes)

Ask the group:

• Who declares the incident or outage?
• What's the first safe action?
• Which work continues, and which pauses?
• Who can approve an alternate process or an outside message?
• Which contacts, accounts, documents, and channels do we need right now?

The useful moments are usually the awkward pauses. A phone number stored only in a system that's now locked. A vendor portal that depends on one person's MFA device. A workaround that creates double entry or exposes sensitive information.

3. Add one realistic complication (20 minutes)

Change one thing to test an assumption. The outage drags on. The usual decision-maker can't be reached. The backup internet works, but only at limited capacity. A customer wants an update before you know the cause. The vendor's support line is swamped.

One complication is enough. If you pile on surprises it turns into a game.

4. Plan the return to normal (15 minutes)

Recovery deserves as much attention as the response. Discuss:

• What shows that the service is safe to restore?
• Who approves going back to normal?
• How will work done by hand be reconciled?
• What update do staff or customers need?
• What should be kept for follow-up?

A fast return isn't automatically a controlled one. Know what has to be checked before systems, access, or transactions resume.

5. Turn findings into owned actions (20 minutes)

Finish with a short action list. Each item gets an owner and a date. Good examples: update the offline contact list, write down an approval limit, confirm a vendor's escalation details, test a call-routing change.

"Improve the continuity plan" isn't an action. If a finding can't be assigned to someone, it probably won't get fixed before the next disruption.

Questions That Show Whether the Plan Is Usable

Listen for answers that rely on memory, on one person, or on something nobody has tested. A few questions bring those out:

• Can the team reach critical contacts and instructions if email and collaboration tools are down?
• Does everyone agree which services and customers come first?
• Are there approved manual processes, and do they protect privacy and accuracy?
• Can two authorized people get to the systems and vendors needed to respond?
• Does the customer-update process avoid promising a cause or recovery time before either is confirmed?
• Is there a clear point where you call the insurer, a specialist, the bank, a carrier, or a software vendor?
• Can you explain how work done during degraded operations will be reconciled?

A "no" is a good result. It's much better to find the problem in a meeting.

Keep It Constructive

This isn't a performance review. People should feel free to say they're unsure, ask for help, and point out dependencies without anyone being blamed. Use plain language, write down assumptions, and distinguish a known gap from a decision that needs leadership input. If the group spots technical fixes, assess those separately afterwards, so the session doesn't turn into an uncontrolled implementation meeting.

Run a focused scenario again after big changes such as a new cloud application, an office move, a phone-system change, a merger, or a shift in who's responsible for what. Over time, short exercises make it more likely that the business can act deliberately when something it depends on fails.

Related Reading

This builds on our business continuity planning article. That one maps the dependencies and operating modes. This one tests the people, decisions, and handoffs behind them.