How to run a cyber security tabletop exercise for a small IT team

A tabletop exercise is a structured conversation: participants sit around a table (or a video call), a facilitator describes an unfolding incident, and the team talks through what it would do. Nothing is touched in production. It is the cheapest way to find out whether your incident response plan works before an attacker tests it for you.

The Canadian Centre for Cyber Security (Cyber Centre) recommends testing your incident response plan with exercises and revising it at least once a year in its guide Developing your incident response plan (ITSAP.40.003). Its Ransomware playbook also lists tabletop exercises as part of recovery planning. This guide walks a small team through one.

Step 1: Set two or three objectives

Keep the scope narrow. Good objectives for a first exercise:

• Confirm who has authority to isolate systems and shut down services.
• Test whether the team can reach each other and outside contacts if email and Teams are down.
• Walk through the privacy breach assessment and reporting steps.

Step 2: Pick participants and a facilitator

1. Invite the IT lead and staff, a manager with decision authority, whoever handles communications, and the person responsible for privacy. If you use a managed service provider, invite it.
2. Choose a facilitator who will not be playing a role. It can be a colleague from another department, a peer from another organization or a consultant.
3. Choose a note-taker. Their notes become your after-action report.

Step 3: Use a ready-made package

The U.S. Cybersecurity and Infrastructure Security Agency publishes more than 100 free CISA Tabletop Exercise Packages (CTEPs), with scenarios including ransomware, insider threats and phishing, and sector versions for local government and health care. Each package includes customizable objectives, scenarios and discussion questions, role templates, an invitation, a slide deck, a feedback form and an after-action report template. Adapt the references to Canadian reporting bodies: the Cyber Centre, the Canadian Anti-Fraud Centre, police and the relevant privacy commissioner.

Step 4: Build the scenario in three injects

An inject is a new piece of information the facilitator reveals. A ransomware scenario for a small organization could run like this:

1. Inject 1, Monday 7:30 a.m.: Staff report that shared files will not open and have a strange extension. The help desk sees a ransom note on a file server. Questions: Who is called first? What gets disconnected, and who decides? How do you communicate if email is affected?
2. Inject 2, 11 a.m.: The EDR console shows the attacker used a VPN account belonging to a former contractor. Backups on the network share are also encrypted. Questions: Are offline backups intact? Which systems are restored first? Who calls the insurer, police and the Cyber Centre?
3. Inject 3, next day: The group posts samples of client files on its leak site and demands payment. A reporter calls. Questions: Does this trigger a report to the Office of the Privacy Commissioner or Quebec's Commission d'accès à l'information? Who decides on the ransom demand? What do you tell clients and staff?

Make the details match your environment: your real VPN, backup product and client types.

Step 5: Run the session

1. Open with ground rules: this is a no-fault discussion, there are no wrong answers, and the scenario is artificial.
2. Present each inject, then give the group 15 to 25 minutes to discuss. Ask participants to open the actual plan and contact list rather than answer from memory.
3. The facilitator probes with follow-up questions: Where is that written down? What if that person is on vacation? How long would that take?
4. Keep time. Two hours is enough for three injects and a debrief.

Step 6: Debrief immediately

Spend the last 20 minutes on three questions: what worked, what was missing or unclear, and what we will change. Hand out the feedback form while memories are fresh.

Step 7: Write the after-action report and fix the gaps

1. Within a week, write a short report using the CTEP template: objectives, what happened, strengths, gaps and recommendations.
2. Turn each gap into a tracked task with an owner and a due date. Typical findings include missing phone numbers, nobody knowing the insurer's breach line, unclear authority to shut down systems and untested offline backups.
3. Update the incident response plan and contact list.
4. Schedule the next exercise, with a different scenario, such as business email compromise or a supplier breach.

Questions worth asking in any scenario

• Where is the current copy of the incident response plan, and can we open it if the file server is encrypted?
• Who can authorize taking the whole network offline, and who is their backup?
• What is our insurer's breach hotline, and does the policy require us to call it before hiring outside help?
• Which records would we need to report to the Office of the Privacy Commissioner, and who would fill in the form?
• What would we tell clients on day one, and through which channel?
• How long would it take to restore our most important system from offline backup, and when did we last prove it?

Answers such as "I think so" or "probably" are findings in their own right. Write them down for the after-action report.

Tips for small teams

• Start small. A 60-minute exercise with one inject is better than none.
• Include management. Many of the hardest decisions in a real incident are business decisions, not technical ones.
• Do not grade individuals. The aim is to test the plan, not the people.
• Keep the reports. They show auditors, insurers and clients that you test your preparedness.

Sources

• Canadian Centre for Cyber Security: Developing your incident response plan (ITSAP.40.003)
• Canadian Centre for Cyber Security: Ransomware playbook (ITSM.00.099)
• CISA: CISA Tabletop Exercise Packages
• OPC: What you need to know about mandatory reporting of breaches of security safeguards