A ransomware message on the finance server at 08:15 is not the moment to discover who can authorise system isolation, contact customers, speak to insurers or restore the latest clean backup. A cyber attack tabletop exercise lets your team practise those decisions before a hostile actor turns uncertainty into downtime, lost revenue and damaged trust.
For small businesses, the value is not in staging a dramatic IT test. It is in exposing the gaps between having a policy and being able to operate under pressure. Attackers do not wait for the right person to return from holiday, for a director to find a password, or for an IT supplier to answer the phone. Your response arrangements must work with the people, systems and information available at the time.
What a cyber attack tabletop exercise actually tests
A tabletop exercise is a structured, discussion-led simulation of a security incident. A facilitator presents a realistic scenario in stages, asking participants what they would do as new intelligence emerges. There is no need to take live systems offline or deploy malware. The focus is decision-making, communication, escalation and recovery.
The scenario should reflect a threat that could genuinely affect the organisation. For many UK businesses, that means ransomware following a stolen Microsoft 365 credential, a convincing invoice fraud attempt, malware on a workstation with access to shared files, or signs that customer data has been copied out of the business.
A useful exercise tests more than the technical team. A compromised account may begin as an IT alert, but it rapidly becomes a leadership, legal, financial and customer-service problem. Participants should be clear about who has authority to contain an incident, who keeps essential services running, who records decisions and who communicates externally.
The aim is not to catch people out. It is to find uncertainty while it is safe to fix it. A productive session should leave the team with specific actions, named owners and realistic timescales.
Why paperwork alone fails during an incident
Many organisations have an incident response document saved in a shared folder. Fewer have checked whether the contact numbers are current, whether decision-makers can be reached out of hours, or whether the stated recovery steps match the systems actually in use.
Under pressure, people fall back on assumptions. Someone may assume the cloud provider retains a recoverable version of every file. A manager may delay isolating an affected device because they need access to an important spreadsheet. A member of staff may try to delete suspicious emails or restart a machine, destroying evidence that could help identify the intrusion route.
A tabletop exercise brings those assumptions into the open. It also highlights trade-offs. Isolating a suspected infected computer quickly can protect the wider network, but it can interrupt a critical process. Waiting for complete certainty may preserve short-term productivity, but it gives an attacker more time to move laterally, steal credentials or encrypt shared data. There is rarely a cost-free choice, which is why authority and escalation thresholds need to be agreed beforehand.
Build a scenario around your real business risk
Generic scenarios produce generic lessons. Start with the business services that would cause the greatest harm if they were unavailable or compromised. That might be access to bookings, stock control, payroll, customer records, email, design files or online payments.
Then map the likely attack path. For example, an employee receives a convincing phishing email and enters their password into a fake login page. An attacker signs in from an unfamiliar location, creates an inbox rule, accesses shared documents and attempts to enrol a new device. The first alert may be a customer reporting a suspicious email rather than a security notification.
Good scenarios unfold in injects. At first, the team may receive an alert about unusual sign-in activity. Ten minutes later, antivirus software detects a malicious file. Next, the backup provider reports repeated failed authentication attempts, and a customer asks whether their information is at risk. Each inject forces a decision and reveals whether the organisation can connect detection, investigation, containment and recovery.
Do not make every exercise a ransomware story. Ransomware is a serious and frequent operational risk, but payment diversion fraud, stolen credentials and data exposure can be just as damaging to a smaller firm. Rotate scenarios over time so that the response capability is tested from different angles.
Who should be in the room
Keep the group focused enough to make decisions, but broad enough to reflect how an attack affects the business. For a small organisation, this may be the owner or director, the person responsible for IT, finance, operations and whoever manages customer communications. If you rely on an external IT provider, cloud supplier or managed security service, define how and when they join the response.
Participants should know their role before the session begins. The exercise is more useful when people are asked to act within their actual authority rather than offering theoretical answers. If a director alone can approve customer notification, include that director. If finance can halt suspicious payments, involve finance.
Questions that reveal response gaps
The strongest tabletop exercises use direct questions. How do you verify that an alert is genuine? Who can instruct staff to stop using a system? Where are the administrator accounts, recovery keys and supplier contacts held if email is unavailable? Which systems must be restored first to keep the business trading?
You should also test the evidence trail. Ask who documents the timeline, retains relevant logs and records every decision. If an incident develops into an insurance claim, regulatory enquiry or police report, a clear record of actions taken may matter as much as the technical investigation itself.
Communications deserve particular attention. Staff need a simple channel for reporting suspicious activity and instructions that do not depend on the compromised system. Customers should not be given speculation. A rushed statement can create legal and reputational problems, while saying nothing for too long can undermine confidence. The right approach depends on what has been verified, what data may be involved and the advice received during the incident.
Turn findings into operational improvements
The exercise is only worthwhile if findings become change. Within a few days, record what happened, the decisions made, points of confusion and the actions required. Avoid vague outcomes such as “improve security”. Instead, make each action testable: update the out-of-hours contact list, protect administrator accounts with multi-factor authentication, confirm backup restoration times, create an offline copy of incident contacts, or clarify who can disconnect a device from the network.
Prioritise the issues that reduce the greatest immediate risk. A missing backup test, shared administrator password or uncertainty over who can isolate systems deserves urgent attention. Other improvements, such as refining a communications template, may be scheduled once critical containment and recovery weaknesses are addressed.
Retest after meaningful changes. An annual exercise is a sensible baseline for many small businesses, but more frequent sessions are appropriate after a serious incident, major system migration, staffing change or new supplier arrangement. A short 60-minute scenario can be effective if it tests one decision path thoroughly.
Measure confidence, not performance theatre
A tabletop exercise should not be judged by whether every answer was perfect. Measure whether the team could identify the incident, reach the right people, make defensible decisions and restore priority services in a controlled order. If the session exposes uncertainty, it has done its job.
The practical outcome is confidence based on evidence rather than optimism. When a real alert arrives, your people should know how to preserve evidence, contain the threat, bring in specialist support and protect the services your customers depend on. That preparation may be the difference between a contained security event and a business-wide crisis.
