Managed IT for offices across Auckland and Hamilton [email protected]
Free IT health check

Cyber security · 4 min read

How to run a cyber tabletop exercise for your business

A tabletop exercise is a guided discussion where your key people walk through a realistic cyber incident, step by step, to test the plan and find the gaps before a real attack does. For a small business it takes about an hour, needs no special tools and usually turns up several practical fixes.

What a tabletop is, and is not

A tabletop is a conversation around a table, or a video call, built on a scenario. A facilitator describes an unfolding incident in stages, and participants talk through what they would do, who they would call and what decisions they would make. Nothing is switched off and no systems are touched. It is not a test of individuals and it is not about catching people out. The point is to find weaknesses in the plan, the contacts and the assumptions. Saying we do not know is a useful result, because it shows where work is needed.

Who should attend

Invite the people who would make or carry out decisions in a real incident: the owner or managing director, the person responsible for finance, whoever manages IT or the IT provider, and someone who deals with customers. In a small firm that may be four to six people. Keep it small enough that everyone talks. If your insurer or broker offers a contact for incidents, consider inviting them to a later exercise so everyone understands how their process fits with yours. Choose a facilitator who is not also the incident lead, so the lead can concentrate on decisions. An IT provider, an outside adviser or a manager who knows the plan can facilitate. Ask someone to take notes throughout.

Choosing a scenario

Pick a scenario that is realistic for your business. Ransomware encrypting the file server on a Monday morning is common. So is a compromised mailbox used to send fake invoices to clients, or a supplier announcing it has been breached and your client data may be exposed. Base the details on your actual systems, suppliers and people so the discussion is concrete. For a first exercise, choose something straightforward. You can try harder scenarios later, such as an incident that starts on a public holiday, or one where the incident lead is overseas and unreachable.

Plan the injects

Break the scenario into three to five stages, called injects, each adding new information. For example: a staff member reports they cannot open files; IT finds ransom notes on the server; the backup system is also encrypted; a journalist calls asking about a leak; a client asks whether their data was taken. Each inject forces new decisions.

Prepare two or three questions for each stage. Who is told first? Who decides to disconnect? Which contact list do you use if email is down? Do we notify the Privacy Commissioner? What do we tell staff? Keep a little time for unplanned questions, which often produce the most useful findings.

Running the session

Start by setting the tone: this is a safe discussion, and the aim is learning. Introduce the scenario and the first inject, then let participants talk. The facilitator keeps things moving, prompts quieter people and gently challenges vague answers. If someone says IT would sort it, ask what exactly IT would do first and how long it would take.

Keep an eye on the plan and contact sheet as you go. Ask people to look up the insurer's incident number, the IT provider's after-hours contact or the bank's fraud line during the exercise. Missing or outdated details are among the most common findings. Time a few of these lookups. If it takes ten minutes and three people to find the insurer's number on a calm afternoon, it will take far longer in a real incident.

Capturing lessons

Spend the last fifteen minutes on a debrief. What went well? What was unclear? Which decisions could not be made because information or authority was missing? Which contacts were wrong or missing? Write each finding as an action with an owner and a due date. Typical actions include updating the contact list, clarifying who can authorise spending on outside help, printing the plan, testing a backup restore, confirming the insurer's requirements and adding a step for checking email forwarding rules. Small, specific actions get done; vague ones do not.

Making it a habit

Run a tabletop at least once a year, and after major changes such as a new IT provider, a new core system or a real incident. Rotate scenarios so the team builds confidence across different types of incident. Keep the notes and action list; insurers and clients increasingly ask whether your plan has been tested, and dated records show it has. Over time the exercises become quicker and the findings smaller, which is a good sign that the business would respond calmly and effectively when something real happens.

In short

  • A tabletop is a guided discussion of a realistic incident, not a technical test
  • Invite decision makers and use a separate facilitator and note taker
  • Build the scenario from your real systems and suppliers
  • Use staged injects with prepared questions
  • Turn findings into owned, dated actions and repeat yearly

Common questions

How long does a tabletop take?

For a small business, about an hour, including a fifteen-minute debrief. Longer exercises suit larger organisations.

Do we need an outside facilitator?

Not necessarily. An outside facilitator brings fresh questions, but a well-prepared manager or your IT provider can run it.

What if we do not have an incident plan yet?

Run the exercise anyway. The discussion will show what the plan needs, and you can write it from the notes.

More on cyber security

When IT breaks, work stops.
Let's keep it running.

Start with a free IT health check. We'll show you what is working, what is at risk and what it would cost to fix.

Book a free IT health check