A tabletop exercise is a talk-through of an incident with no systems touched. For a team of 5 to 20 engineers, pick one realistic scenario, gather everyone for an hour, walk through who does what, and write down the gaps. Once a year is a sensible starting rhythm.
What a tabletop is, and is not
A tabletop is a discussion. Nobody attacks anything and nobody breaks production. You read out a short scenario, then ask the group what they would do at each step. The value is finding out, in a calm room, that two people each assumed the other would call the customer.
It is not a penetration test and it is not a fire drill. It tests your people and your plan, not your servers.
CISA publishes free tabletop exercise packages that include template objectives, scenarios and discussion questions, and they can be customized. Ransomware, phishing and insider threat scenarios are among the cybersecurity ones, so you do not need to invent a scenario from scratch.
Before the hour
Pick one scenario that fits your product. A leaked deploy token, a malicious package in a build, or a lost laptop with source code on it are all believable for a small team. Choose one person to run the session and one person to take notes. The facilitator should not be the person who owns the plan, because the owner will fill in gaps without noticing.
Invite everyone who would be pulled in: engineers, whoever handles customer messages, and a founder or manager who can approve a decision.
The session
| Step | Time | What happens |
|---|---|---|
| Setup | 5 minutes | State the scenario and the ground rules: no blame, no real systems |
| Detection | 10 minutes | How would we notice? Who gets the alert? |
| First response | 15 minutes | Who is in charge? What do we stop, revoke or isolate? |
| Communication | 15 minutes | Who tells customers, and who decides what to say? |
| Recovery | 10 minutes | How do we restore and confirm we are clean? |
| Wrap up | 5 minutes | List gaps and name an owner for each |
Release one new fact at each step, such as "the token was also used from a second country". Facts that change the picture force the team to adapt, which is what a real incident does.
What to write down
Keep the output short: the scenario, the date, who attended, the gaps found, and an owner and a date for each fix. Most gaps are small and fixable. A missing phone number, an access you could not revoke quickly, an unclear call on who may shut a service down.
Then update your incident plan. If you do not have one yet, start with the one in a one-page incident plan for a two person team and the roles in lead, scribe and communicator.
Common mistakes
Running it as a quiz where one person knows the answers. Letting it drift into a debate about tools. Skipping the notes. Doing it once and never closing the gaps. The exercise only pays off if at least one fix lands before the next one.
Where Safeguard fits
Safeguard can cover the dependency side of this work: SBOM and dependency scanning, reachability analysis to show which findings are actually exposed, and policies and gates for pull requests. A free scan is at gold.safeguard.sh/scan.
Quick check
Do we need an outside facilitator?
No. Any engineer who is not the plan owner can run it with a printed scenario. Bring in outside help only if you want a harder or more specialized exercise.
How often should a small team do this?
Once a year is a reasonable start, plus after a real incident or a big change such as a new cloud account or a new customer type.
Sources
Last reviewed: 19 October 2026.
