The exercise should test decisions, not recitation of the plan
Consider a hypothetical enterprise that runs a security incident tabletop exercise every year. On the day, the facilitator announces "ransomware detected", representatives from each department read out the plan sections they own, everyone signs the attendance sheet two hours later, and the report says "exercise completed successfully". A few months later a real incident occurs, and only then does the team discover that the on-call phone number in the plan now belongs to someone else, that nobody clearly has authority to decide whether to disconnect the production network, and that it is disputed which executive must approve an external statement. The exercise took place, but it did not test the things that mattered most.
NIST's guide to test, training and exercise programs defines a tabletop exercise as a discussion-based activity that does not deploy equipment or other resources, in which a facilitator guides participants through one or more scenarios to discuss their roles and responses in an emergency. The guide divides tabletop exercises into design, development, conduct and evaluation phases, and recommends setting objectives and identifying a facilitator and a data collector during design, followed by an after-action report. The guide was published in 2006 and can serve as a methodological foundation rather than a current compliance requirement. Building on it, JOTOglobal suggests that every tabletop exercise be designed around several decisions that people must make on the spot, so participants reveal their reasoning and the limits of their authority instead of repeating text.
Design scenarios and injects around decision points
The design phase is led by the security lead, who first chooses the plan or process to be tested this time and then lists three to five decision points, for example whether to isolate a business system, whether to notify regulators or customers, whether to contact law enforcement, whether to activate a backup site and who confirms the external message. The scenario itself stays short, and complex information goes into injects released in stages. Each inject corresponds to a decision point and states when it is provided, to which role and what discussion it is meant to prompt. Scenarios should be based on the enterprise's own system architecture and supplier relationships rather than copied from generic cases, so the gaps they expose are concrete and fixable. Once the design is complete, a colleague who is not taking part can read the scenario to confirm that the injects do not give away the answers and are not so far-fetched that participants dismiss them as irrelevant.
Participants are invited according to the decisions involved: the technical response lead, business system owners, legal or compliance, external communications, HR, and a management representative with authority to approve major measures. In a first exercise, technical staff and management can practice separately before a combined session tests coordination, which is consistent with the guide's advice. The facilitator manages the pace and does not answer questions for participants. The data collector only records and does not join the discussion, noting for each decision point who raised it, what it was based on, whether anyone's approval had to be awaited and for how long, and any information gaps found. A participant guide explaining the rules, schedule and confidentiality requirements is sent out a week in advance.
During the exercise, ask about basis and authority
When an answer is vague, the facilitator asks two follow-up questions: what information are you basing this judgment on, and can you really get that information at this moment; and who approves this decision, and if they cannot be reached, who can act on their behalf. For example, if someone says "we will notify customers immediately", the facilitator can ask which system holds the customer list, whether that system is available during the incident and who finalizes the wording. Questions like these often reveal gaps between documents and reality, such as a contact who has left the company, backup contact details stored in an affected system, or an authorization that names a position but no deputy. The data collector records these gaps as they are, without arguing on the spot about who is right, so that participants do not avoid the real situation to protect themselves.
An exercise should generally take no more than half a day, leaving at least thirty minutes for an on-site debrief in which participants name the two or three issues that worry them most. The facilitator does not rush to give answers but records the issues for the after-action report. If the exercise involves real customer names, system vulnerabilities or contract details, the distribution of materials should be controlled and the materials collected afterwards, so that the exercise documents themselves do not become a source of leaks. Enterprises spanning several regions can run the exercise online, but they should make sure regional representatives join the discussion of key decision points at the same time.
After-action report, remediation tracking and limits
Within two weeks of the exercise, the security lead completes the after-action report based on the data collector's notes. Rather than stating only that the exercise succeeded, the report lists what was actually discussed at each decision point, the issues found, recommended remediation, the owner of each item and the deadline. Remediation items should be entered in the everyday work tracking system, and before the next exercise starts, the team checks whether the previous items have been completed and deliberately tests in the new scenario whether those changes work. One common mistake is to set the goal as "everyone passes", which leads to scenarios that are too mild. Another is to exercise only technical response and ignore how external communication, legal judgment and business continuity connect.
The scenario design, questioning approach and tracking method in this article are organizational guidance from JOTOglobal and do not replace specific exercise requirements set by industry regulators. A tabletop exercise can only test plans and decision processes; it cannot verify whether systems can actually be restored within the required time, which needs functional exercises or technical tests as a complement. The frequency, scope and level of participation should be decided by each enterprise according to business criticality, recent changes and available resources, and any part involving notifications to external regulators should follow the regulations of the relevant jurisdiction.