Every organisation has an incident response plan somewhere. Far fewer have watched their leadership team try to use it at two in the morning, with half the facts missing and a journalist on the phone. That is the gap a tabletop exercise closes.
A cyber tabletop exercise is a structured conversation around a realistic scenario. A facilitator releases new information in stages, called injects, and the people who would make decisions in a real crisis talk through what they would do. Nothing is switched off and no systems are touched. What gets tested is judgement, authority and communication, which is exactly where most real incidents go wrong.
This guide sets out five scenarios every leadership team should run, the questions each one is designed to test and how to run the session so it produces actions rather than just a pleasant afternoon.
Why Leadership Teams Need to Rehearse, Not Just Plan
Plans are written in calm conditions. Incidents happen in the opposite ones: key people are on leave, information is incomplete and several urgent decisions arrive at once.
The value of rehearsal is that it surfaces the assumptions nobody has tested. Who has the authority to shut down the network? Who talks to the insurer? Which customers do we call first? In most organisations the honest answer to at least one of these is "we are not sure", and it is far cheaper to discover that in a meeting room than in the middle of an attack.
What a document tells you, and what a rehearsal reveals
The plan says
- "The incident lead will convene the response team."
- "Backups are taken nightly."
- "Communications will be issued promptly."
- "Suppliers will be contacted as required."
The rehearsal finds
- The incident lead is on holiday and nobody else has authority.
- Nobody has restored the finance system in two years.
- Three people think they approve the statement.
- The supplier's emergency number goes to voicemail.
Rehearsal also matters because regulators and boards increasingly expect it. The UK government's Cyber Governance Code of Practice asks directors to make sure incident plans are in place and exercised, and the NCSC's Board Toolkit encourages leadership teams to take part in exercises rather than leave them to IT. If you supply larger organisations or the public sector, expect to be asked when your last exercise took place.
The NCSC's free Exercise in a Box is a useful starting point. The scenarios below focus on the decisions that land on a leadership team.
Scenario 1: Ransomware Over a Bank Holiday Weekend
Ransomware groups know when organisations are thinly staffed. Long weekends, Christmas and the start of the summer holidays are favourite times to start encrypting. This scenario tests whether your response works when the usual decision makers are unavailable and the clock is already running.
The richest discussion usually comes from the ransom question. In the UK, the government has announced plans to ban ransom payments by public sector bodies and operators of critical national infrastructure, and to require other organisations to notify the government before paying. Whatever your sector, the exercise should establish who would make that call, what advice they would take and how the decision would be recorded. Our article on the UK ransomware payment ban explains the proposals in more detail.
Use the explorer below to see the timeline and questions for each scenario.
Pick a scenario to see its timeline and the questions it tests
Ransomware Over a Bank Holiday Weekend
Encryption starts at 02:10 on the Saturday of a long weekend. The on-call engineer cannot reach the IT manager, the backup server is also showing encrypted files, and a ransom note gives a 72-hour deadline.
- Sat 02:10Monitoring alerts on mass file changes across two file servers
- Sat 07:30Staff report they cannot log in; the ransom note appears on screens
- Sun 16:00Attackers post a sample of your data and email two customers
- Tue 08:00The business reopens. What is running, and what is not?
- Who can declare a major incident when the usual people are away?
- Do we know the order in which systems must come back?
- Who decides on any ransom question, and on what basis?
A Critical Supplier Is Breached
Your managed IT provider tells you, almost in passing, that it is dealing with an incident. It holds administrator access to your systems and cannot yet say whether your environment was touched.
- 09:00The supplier mentions an incident on a routine call
- 11:30Their status page goes quiet; your account manager stops replying
- 16:00You find a new admin account created on your network last week
- Day 2A customer asks whether you are affected
- Do we know exactly what access each critical supplier has?
- Can we cut a supplier off without stopping the business?
- What do our contracts say about notification and cooperation?
Customer Data Appears on a Leak Site
A journalist emails the press office with a screenshot from a criminal leak site. It appears to show a spreadsheet of your customers' names, addresses and order histories. Nobody internally knew there had been a breach.
- 10:15A journalist asks for comment by 14:00
- 10:40IT cannot yet confirm where the file came from
- 13:30Customers start posting on social media
- Day 3The ICO asks when you first became aware
- When does our 72-hour clock to the ICO start?
- Who approves a holding statement, and how fast?
- How do we tell affected customers what they should do?
A Deepfake Call Approves a Payment
Your finance lead joins a video call with what looks and sounds like the chief executive and two colleagues. They approve an urgent, confidential payment to a new supplier. The real chief executive was on a flight at the time.
- 15:05A video call invitation arrives from the chief executive's assistant
- 15:20A payment is approved to a new overseas account
- 18:10Finance realises the call was fake
- Day 2The bank asks for a police reference before it will try to recall funds
- Which payments need a call back on a known number, every time?
- Could any single person approve this payment?
- How quickly can we contact our bank out of hours?
A Cloud Outage You Cannot Fix Yourself
A major cloud provider suffers a regional outage. Your customer portal, phone system and finance platform all depend on it. There is no attacker to chase and nothing your team can repair. The provider estimates recovery in 'several hours'.
- 08:45Customers cannot log in to the portal
- 09:30The phone system fails over badly; calls drop
- 13:00A key customer asks about your contractual service levels
- 16:00Partial service returns, but data looks out of sync
- Which services share a single point of failure we never chose?
- What can we run manually, and for how long?
- Do customers hear from us before they hear the news?
Times are illustrative. Adapt each inject to your own systems, suppliers and calendar.
Scenario 2: A Critical Supplier Is Breached
Many of the most damaging recent incidents did not start inside the victim's own network. They started at an IT provider, a software supplier or a payroll bureau with trusted access. This scenario tests how well you know your suppliers and how quickly you can act when one of them is compromised.
The setup is deliberately vague, because that is how it happens in practice. Do you cut off the supplier's remote access, knowing it might stop your own IT support? Do you warn customers before you know whether you are affected?
Leadership teams often find they cannot answer a basic question: which suppliers have privileged access to our systems, and how do they connect? If that is the outcome, it is a valuable one. Our third-party and supply chain risk service helps build that picture.
Scenario 3: Customer Data Appears on a Leak Site
Sometimes the first you hear of a breach is from someone outside the organisation. A journalist, a researcher or a customer finds your data on a criminal leak site and asks for comment. This scenario tests communications, legal obligations and the uncomfortable business of speaking publicly before you know the full story.
Under UK GDPR, a personal data breach that is likely to result in a risk to people's rights and freedoms must be reported to the ICO within 72 hours of the organisation becoming aware of it. The exercise should test how you decide when that awareness began, who prepares the report and how you would tell affected individuals what to do. The ICO's guidance is a good pre-read for the session.
A good twist is to make the data come from a system the organisation believed it had retired. It tests data retention as well as the crisis response.
Scenario 4: A Deepfake Call Approves a Payment
Payment fraud has moved well beyond the badly written email. In 2024, the engineering firm Arup confirmed that an employee in Hong Kong had transferred around HK$200 million after a video call in which the senior colleagues on screen were deepfakes, as reported by CNN. Convincing voice and video cloning is now cheap and widely available.
This scenario tests your payment controls rather than your technology. Could one person approve an urgent payment to a new account? Is there a rule that new or changed bank details are always confirmed by calling a known number? How quickly can you reach your bank out of hours to try to recall the funds?
It also tests how the organisation treats the person who was deceived, because a blame culture makes people slower to report. Our briefing on AI phishing and deepfake fraud covers the wider threat, and security awareness training can prepare finance teams for exactly this kind of approach.
Scenario 5: A Cloud Outage You Cannot Fix Yourself
Not every crisis involves an attacker. When a major cloud or software provider has a bad day, thousands of organisations go down at the same time and there is nothing their own teams can repair. This scenario tests resilience and dependency rather than security.
The discussion usually reveals single points of failure that nobody chose deliberately. The exercise should ask what can run manually, for how long, and how customers will hear from you first.
It is also a good moment to review business continuity and disaster recovery plans, and to check that recovery is actually tested. Our cyber recovery testing playbook sets out how to prove that systems can come back in the time the business expects.
How to Run the Session and Capture Actions
A tabletop exercise is only as good as the actions that come out of it. These habits separate a useful exercise from an interesting conversation.
Before, during and after the exercise
Two weeks before
- Agree one or two objectives with the sponsor
- Choose the scenario and tailor the injects
- Invite decision makers and their deputies
- Share the incident plan, not the scenario
On the day
- Set ground rules: no blame, no laptops
- Release injects one at a time
- Ask "who decides?" and "how do we know?"
- Keep a live log of decisions and gaps
Within a week
- Circulate a short report with findings
- Give every action an owner and a date
- Update the plan, contacts and playbooks
- Book the next exercise in the diary
Choose the Right People
Invite the people who would make decisions, plus their deputies, because the exercise should test what happens when the first choice is unavailable. Appoint a note taker whose only job is to record decisions and gaps.
Make It Realistic, Not Theatrical
Injects should feel plausible for your organisation: your systems, your suppliers, your customers. The aim is to stretch the team, not to make the problem impossible.
Keep Asking Two Questions
A good facilitator returns again and again to two questions: "Who decides?" and "How would we know?" The first exposes gaps in authority. The second exposes gaps in information, logging and monitoring. If the answer to the second is that nobody would notice until Monday, that is a finding in its own right, and one that round-the-clock managed detection and response is designed to close.
Turn Findings Into Owned Actions
Within a week, circulate a short report. Each finding should become an action with a named owner and a date, and the actions should be reviewed at the next leadership meeting. Then book the next exercise, ideally with a different scenario, so the programme keeps moving.
How Cybergen Can Help
Cybergen designs and facilitates tabletop exercises and crisis simulations for boards, leadership teams and technical responders. We build each scenario around your organisation and give you a clear findings report with prioritised actions. We can also help you act on what the exercise reveals:
- Incident response planning and retained support, so you know who to call
- Business continuity and disaster recovery planning and testing
- Supplier risk management built around real access
- Security awareness training for finance teams and executives
If you would like to run your first exercise, or make your next one more useful, speak to our team.
The proposed ransomware payment ban and related government guidance are subject to change. This guide reflects the position as at 9 November 2026.
Frequently Asked Questions
How often should we run a tabletop exercise?
At least once a year for the leadership team, and again after any major change such as a new chief executive, an acquisition or a new critical supplier. Many organisations add a shorter technical drill every quarter so the response team stays sharp between leadership sessions.
Who should attend?
The people who would make decisions in a real incident: the chief executive or managing director, finance, operations, legal or compliance, communications, HR and the technology lead, plus their deputies. Keep it to around a dozen people so everyone contributes. A neutral facilitator and a note taker run the session.
How long does a tabletop exercise take?
Two to three hours is enough for one scenario with a proper debrief. Shorter sessions tend to stop just as the hard decisions arrive. Longer sessions work well for a combined technical and leadership exercise.
Do we need an external facilitator?
Not always, but it helps. An external facilitator can challenge senior people without the politics, bring realistic injects from real incidents and write a findings report that the board will take seriously.
What is the difference between a tabletop exercise and a crisis simulation?
A tabletop exercise is a discussion around a scenario. A crisis simulation is more immersive, with live injects arriving by email or phone, role players and time pressure. Most organisations start with tabletops and move to simulations as they mature.



