Tabletop exercise: what always comes out

An incident response plan reads well as long as nobody uses it. The tabletop exercise is the cheapest way to find out: a room, a scenario that moves forward through injects, and people who have to say out loud what they would do. We facilitate them regularly, and the same findings come back.

What the sources say

CISA publishes tabletop exercise packages (CISA Tabletop Exercise Packages, CTEP), a set of resources so that organizations can run their own exercises. Each package is customizable and provides template objectives, a scenario, discussion questions and reference material, plus templates for roles, invitations, slides, feedback forms and the after-action report. More than a hundred packages cover cybersecurity (ransomware, insider threat, phishing, industrial control system compromise, with sector variants including healthcare and local government), physical security and the convergence of the two.

In April 2025, NIST published revision 3 of Special Publication 800-61, as a community profile of the Cybersecurity Framework (CSF) 2.0. The text replaces the old phase-based life cycle with the six CSF functions: Govern, Identify, Protect, Detect, Respond, Recover. It notes that procedures can be tested or exercised periodically to verify their accuracy and to train staff, that organizations benefit from documenting playbooks for the most common incidents, and that lessons learned should be shared as soon as they are identified, without waiting for recovery to end. Outcome ID.IM-02 of the profile provides that improvements be drawn from tests and exercises, including those conducted with suppliers and third parties; outcome RC.RP-06 asks for an after-action report that documents the incident, the response and recovery actions and the lessons learned. The document also names the roles: leadership, which oversees and holds the authority over high-impact decisions such as shutting down a service; incident handlers, on staff, on contract or available when needed; and technology professionals.

Why it matters

The tabletop exercise does not test the technology. It tests the decisions: who decides to isolate a server, who calls the insurer, who talks to the customer, when to notify the Commission d'accès à l'information or the Office of the Privacy Commissioner of Canada. Those decisions cannot be improvised in the middle of the night.

What almost always comes out, in the order we see it:

The plan names roles, not reachable people. The "security lead" is on vacation, and the backup has never read the plan.

Nobody knows who can shut down production. Leadership thinks IT will decide; IT is waiting for authorization. NIST explicitly places that authority in the plan.

The managed services provider is not in the room. When detection and response are under contract, the exercise reveals that the contract specifies neither the callback delay nor who makes the decisions.

Notification obligations are known by name, not by deadline. Law 25, PIPEDA, NIS2 for European subsidiaries, contractual obligations to customers: the table rarely exists, and it has to be completed during the session.

The backups have never been fully restored. The question "how long would it take?" gets an estimate.

The after-action report is never written. The exercise ends on a good conversation, and nothing changes.

What we think at Sentrix

A useful exercise fits in a morning if the preparation is done. Our sequence, in order:

1. Choose a scenario credible for your organization, starting from a CTEP package: ransomware with exfiltration for most, compromise of a vendor for those that depend on a managed provider. A few injects, each forcing a decision.
2. Gather the decision-makers, not only IT: leadership, legal, communications, human resources, the privacy officer, and the managed services provider if there is one.
3. Ask the role questions before the technical questions: who decides, who speaks, who takes notes, who calls whom, and with which number.
4. Have the incident log kept live by a designated person, as during a real incident: it is the evidence the auditor will ask for.
5. Write the after-action report within the week, with named gaps, an owner and a date, and feed it into the improvement plan.
6. Do it again within the year, with a different scenario, and compare the two reports.

For ISO 27001:2022, the exercise feeds controls 5.24 to 5.27 (incident management planning, assessment, response and learning from incidents); for SOC 2, criteria CC7.3 to CC7.5; for NIS2 and DORA, the obligation to test the plans. Our incident response service facilitates these exercises and writes the after-action report; the NIS2 and Law 25 framework pages summarize the notification obligations.

The next step

If your plan has never been exercised, do not start with the package: take the list of people in the plan and call them, today, with the numbers written there. The result of that call is your first after-action report.