Tabletop Exercises: Testing Your Incident Response Plan

Ask any organisation whether it has an incident response plan and the answer is usually yes. Ask when anyone last opened it, and the room goes quiet.

The plan is not the capability. A well-written document that nobody has used under pressure tells you what someone believed the response should look like on the day they wrote it. It says nothing about whether the finance director will authorise a payment hold at two in the morning, or whether anyone knows the phone number of the response firm on the retainer.

A tabletop exercise costs a few hours of people's time and touches nothing in production. It is the cheapest way to find out that half the plan does not survive contact with a real decision.

This guide covers how a tabletop differs from other testing, how to design one that finds genuine gaps rather than confirming the plan reads well, the questions that reliably break teams, what the exercise should produce, and what Saudi organisations should rehearse that international templates miss.

What Is a Tabletop Exercise?

A tabletop exercise is a discussion-based session in which participants walk through their response to a simulated incident scenario, describing what they would do rather than doing it. No system is shut down, no data is restored and no production change is made.

The format is deliberately low-risk, and that is what makes it useful. Because nothing real happens, an organisation can rehearse a scenario it would never dare to trigger deliberately, such as ransomware across the file estate or the compromise of the finance mailbox during a payment run.

What a tabletop tests is the layer where incident response actually fails. Technical containment is usually the part teams handle well, because it is the part they practise daily. The failures cluster around decisions and communication: who declares an incident, who has authority to disconnect a system that generates revenue, who speaks to the regulator, and how anyone coordinates if the compromised system is the one they normally coordinate through.

How Does a Tabletop Compare With Other Testing?

The table below sets out where a tabletop sits among the ways an organisation can test its readiness.

Criterion	Plan walkthrough	Tabletop exercise	Functional exercise	Red team engagement
What happens	The plan is read and reviewed	A scenario is discussed with timed complications	Parts of the response are actually performed	An external team attempts a real intrusion
Production systems touched	None	None	Some, in a controlled way	Live environment
Typical duration	1 to 2 hours	2 to 4 hours	A day or more	Weeks
Who participates	Plan owners	Technical, legal, communications, executive, operations	Technical teams plus coordinators	A specialist external team, usually few insiders informed
Primary value	Confirms the document is current	Exposes decision and communication gaps	Proves procedures work in practice	Tests detection and response against a real adversary
Disruption and cost	Minimal	Low	Medium	High
Best used for	Annual document review	Regular readiness testing across the business	Validating recovery and restoration procedures	Mature programmes with existing detection capability

How Do You Design One That Finds Real Gaps?

A tabletop that confirms everything is fine was designed badly. Four elements determine whether it produces anything useful.

Set two to four objectives, not everything. Decide in advance what you are testing. Decision authority and escalation. Internal and external communications. Regulatory notification. Third-party coordination. Technical containment sequencing. Pick a small number, because a session trying to cover all of them covers none of them properly.

Choose a scenario plausible for your organisation. The scenario should reflect your actual threat profile, your systems and your business. A distributor with sixty staff rehearsing a sophisticated nation-state campaign learns nothing. The same team rehearsing business email compromise during a supplier payment run learns a great deal. Scenarios worth rotating through include ransomware with backups also affected, a compromised finance mailbox and diverted payment, a supplier breach exposing your data, a departing employee exporting customer records, and a cloud account compromised through a leaked credential.

Write injects, and time them. An inject is a complication introduced partway through the session that changes the situation. Injects are what separate an exercise from a plan reading. Useful ones include: the incident lead is unreachable and their deputy is on leave; a journalist has called reception; the backup restore has failed on the second attempt; a customer has posted about the outage publicly; the attacker has emailed the chief executive directly. Prepare six to eight and release them on a schedule rather than improvising.

Assign the roles properly. A facilitator runs the scenario, controls the clock and releases injects, and does not participate in decisions. A separate scribe records decisions, timings and gaps, because the facilitator cannot do both. Participants are the people who would genuinely respond, which means legal, communications, finance, human resources and an executive with authority, not only the IT team. Observers stay silent.

Two to four hours is the right length. Run one at least annually, quarterly if the organisation is regulated or has been through a live incident, and always re-run a scenario after remediating the gaps it exposed.

Which Questions Expose the Most Gaps?

Eight questions reliably produce silence in a room that believed it was prepared. Work them into every exercise regardless of scenario.

Who declares an incident? Naming a role is not an answer. Name the person, then name their deputy, then establish what happens when both are unreachable at three in the morning.

Who can authorise disconnecting a revenue-generating system? Containment often requires taking something offline that costs money every hour it is down. If that decision needs an executive who cannot be reached, containment waits, and the attacker does not.

How do you communicate if email and chat are compromised? This is the gap that appears most often and matters most. If the attacker is inside the mail system, every message coordinating the response lands in their inbox. Establish an out-of-band channel in advance, agree who is on it, and confirm people can access it without corporate credentials.

Where is the plan stored? If the incident response plan lives on the file server, and the file server is encrypted, the plan is gone at exactly the moment it is needed. Keep an offline copy, printed or on a device outside the domain, and include the contact list in it.

Who is on the contact list, and is it current? The response retainer, the insurer, external counsel, the cloud provider's escalation path and the key system integrator. Verify the numbers annually, because they go stale quietly.

Who notifies the regulator, and what is the clock? Notification deadlines are the most time-critical decision in an incident. The person who owns that decision should know it before the day arrives, not be researching it during the response.

Who speaks to customers, and who approves the wording? Draft holding statements in advance. Writing customer communications under pressure produces either silence or something legal will later regret.

If ransom is demanded, who decides? The answer may be that the organisation does not pay, and that is a valid position, but it should be a decided position with executive backing rather than a debate held during the incident. Recovery capability is what makes that answer credible, which links the exercise directly to ransomware recovery and disaster recovery planning.

What Should a Tabletop Produce?

The exercise is not the deliverable. The after-action report is.

An after-action report records what happened during the session and converts it into tracked work. It should contain four things:

• What worked, recorded honestly, because a plan with genuinely strong sections deserves to keep them
• Gaps identified, described specifically rather than as themes, so "no out-of-band communication channel exists" rather than "communications could be improved"
• An owner and a due date for every gap, assigned in the room while the people are still present
• Timings, showing how long decisions took, since delay is itself a finding

Circulate the report within a week, while the session is fresh. Track the actions in whatever system the organisation already uses for work, not in a document that is only opened before the next exercise.

Then close the loop. Re-run the same scenario after remediation and confirm the gaps are actually closed. An exercise programme that never repeats a scenario produces a growing list of findings and no evidence that anything improved.

One point on tone. A tabletop is not an assessment of individuals, and the moment it feels like one, participants start performing rather than revealing. State at the outset that the objective is to find gaps in the plan, not weaknesses in people, and mean it. The most valuable moment in any exercise is someone saying they do not know what they would do, and that only happens in a room where saying it is safe.

What Should Saudi Organisations Rehearse Specifically?

Four factors apply in the Kingdom that international exercise templates do not account for.

Rehearse an incident that starts on a Friday. The Saudi working week runs Sunday to Thursday, and attackers deliberately time intrusions for periods of low staffing. An international response retainer or a global security operations centre built around a Monday to Friday assumption may treat Saturday as a working day and Friday as a weekend, or the reverse, and neither matches local reality. Run at least one exercise where the scenario begins on a Friday afternoon or during Eid, and check what coverage actually exists in the contract rather than what everyone assumes.

Ramadan deserves the same treatment. Adjusted working hours and reduced on-site presence change how quickly people can be assembled, and an exercise run in ordinary conditions will not reveal it.

Rehearse the notification decision. The Personal Data Protection Law (PDPL), administered by the Saudi Data and Artificial Intelligence Authority, requires notification where a breach affects personal data, with a 72-hour window commonly cited in the Saudi market for notifying the authority. Confirm the current period and the thresholds against the Implementing Regulations, and put the answer in the plan. Significant cybersecurity incidents are also reported to the National Cybersecurity Authority, and regulated financial institutions carry the additional obligations of the SAMA Cybersecurity Framework. Testing incident response against the National Cybersecurity Authority's Essential Cybersecurity Controls (ECC) is itself an expectation, so the exercise serves the compliance requirement as well as the operational one.

Prepare communications in Arabic and English before you need them. Customer notifications, regulator correspondence and public statements will be required in both languages. Drafting Arabic communications under time pressure at two in the morning, and then getting them reviewed, is not a task to discover during an incident. Prepare bilingual holding statements in advance and have them approved while nobody is panicking.

Include the system integrator in the exercise. Where a contractor built the environment and retains the operational knowledge, they are part of the response whether the plan names them or not. Establish who at that company answers out of hours, whether the contract covers incident support, and what happens if the relationship has ended since the system was delivered.

Blue Edge, a technology distributor based in Dammam, Saudi Arabia, distributes KnowBe4 security awareness training and human risk management and NinjaOne endpoint and patch management, which support the preparation and recovery sides of incident readiness.

What Are the Most Common Tabletop Mistakes?

Six mistakes account for most exercises that produce nothing.

Only inviting IT. The decisions that stall real incidents belong to legal, communications, finance and executives. An exercise attended only by technical staff tests the part that was already working.

Running it without injects. A scenario with no complications becomes a reading of the plan, and the plan always performs well when nothing goes wrong.

Letting the facilitator also be a participant. Someone controlling the scenario cannot simultaneously be tested by it, and the exercise softens to match what they know is coming.

Choosing an implausible scenario. A threat far outside the organisation's realistic profile produces speculation rather than findings.

Producing no after-action report with owners and dates. Gaps identified and not assigned are gaps rediscovered at the next exercise, and again during the real incident.

Never repeating a scenario. Without a re-run there is no evidence that anything was fixed, only a list of things that were noticed.

Run the Cheap Test Before the Expensive One

Organisations tend to buy the expensive assurance first. A penetration test or a red team engagement is a defensible purchase and produces an impressive report, and neither will tell you that nobody can reach the finance director on a Friday night, or that the response plan is stored on the server the ransomware encrypted.

A tabletop finds those things in an afternoon, at the cost of a meeting room. Run one against a scenario that could genuinely happen to your business, with legal and communications in the room, and with injects that make the situation worse partway through. Record the gaps with names and dates against them. Then run it again once they are closed.

Two commitments make the difference between an exercise programme and an annual event. Someone owns the findings after the room empties. And at least one scenario a year starts at the worst possible moment for your organisation specifically, which in Saudi Arabia usually means a Friday, or the middle of Eid.

Frequently Asked Questions

• How is a tabletop exercise different from a penetration test?

  A penetration test is a technical assessment in which specialists attempt to exploit vulnerabilities in systems. A tabletop exercise is a discussion in which people rehearse how they would respond to an incident, with no systems touched. They answer different questions: a penetration test asks whether an attacker could get in, while a tabletop asks whether the organisation could respond coherently once one did.

• How long should a tabletop exercise take?

  Two to four hours is right for most organisations. Shorter than two hours rarely allows enough injects to produce useful pressure, and longer than four hours loses the attention of senior participants whose presence is the point. Run one at least annually, quarterly for regulated organisations or those recovering from a live incident, and always re-run a scenario after remediating the gaps it exposed.

• How do you communicate during an incident if email is compromised?

  Through an out-of-band channel agreed in advance. If the attacker is inside the mail system, every message coordinating the response is visible to them, and messages can be deleted or altered. Establish an alternative channel that does not depend on corporate credentials or corporate infrastructure, confirm who is on it, test that people can actually access it, and record the details in the offline copy of the plan.

• What is an after-action report?

  An after-action report is the written output of an exercise, recording what worked, what gaps were found, how long decisions took, and an owner and due date for each gap. It matters more than the session itself, because it converts observations into tracked work. Circulate it within a week and track the actions in the system the organisation already uses, not in a document opened only before the next exercise.

• Who do Saudi organisations notify after a data breach?

  Notification obligations depend on the incident and the sector. Breaches affecting personal data are notified to the Saudi Data and Artificial Intelligence Authority under the Personal Data Protection Law, with a 72-hour window commonly cited, and significant cybersecurity incidents are reported to the National Cybersecurity Authority. Financial institutions carry additional obligations under the SAMA Cybersecurity Framework. Confirm current thresholds and timeframes and record them in the plan before an incident occurs.

---

Published 8 September 2026 • Last updated 3 October 2026 • This article is reviewed when standards, regulations or product guidance change.