A sensible baseline is a full tabletop once or twice a year, plus short drills in between, and an extra run after a major change. No standard fixes a frequency for this specific exercise, so choose a rhythm you will keep and tie it to triggers such as a new pipeline or a public incident.
What the guidance says and does not say
NIST's SP 800-61 Rev. 3 describes incident response as something to build into risk management so organizations can prepare, reduce the number and impact of incidents, and improve detection, response and recovery. It does not tell you to rehearse a dependency compromise on a fixed date. CISA offers over 100 tabletop packages that groups can customize, which makes it easy to run many scenarios, though not a rule for how often. The cadence is your call, and the useful question is how fast your environment changes.
A cadence that works
| Activity | Rhythm | Length | Purpose |
|---|---|---|---|
| Full tabletop | Once or twice a year | 90 minutes | Test decisions and roles end to end |
| Short drill | Quarterly | 20 to 30 minutes | Practice one skill, such as finding a package across repos |
| Cold read of the runbook | After each edit | 15 minutes | Catch steps that no longer make sense |
| Triggered run | As needed | 60 minutes | Respond to a change or incident |
Rotate the scenario. One round could be a compromised maintainer account, the next a malicious install script, the next a vendored copy.
Triggers for an extra run
- A change in how you build. New CI system, new registry mirror, new monorepo layout, new artifact format.
- A change in who is on call. New incident commanders or a new platform team.
- A public incident close to your stack. Use it as scenario material while people are paying attention. See how to run a tabletop exercise for a supply chain breach.
- A real near miss. Replay the timeline and compare what you did with what the runbook says.
- A poor score last time. If a dimension scored low, retest it within a quarter.
Keep it cheap
Teams skip exercises that take a day of preparation. Reduce the cost.
- Keep a scenario library in one folder, each with an inject list and expected answers.
- Reuse the facilitator guide and scoring sheet.
- Run short drills inside existing meetings.
- Time-box discussion. A tight 60 minutes beats a loose half day.
Signs you are running too rarely
You are running too rarely if people cannot find the runbook, contacts have changed since the last session, the last exercise predates your current pipeline, or findings from the previous run are still open. Fix the open findings before scheduling something new, because repeating a known failure teaches little.
Signs you are overdoing it
If participants treat it as a chore, scenarios repeat without new learning, or findings never close, reduce frequency and increase follow-through. A smaller number of exercises with finished actions improves readiness more than a busy calendar.
Quick check
Is a yearly tabletop enough?
It can be a starting point for a stable environment. Add short drills and triggered runs if your build or team changes often.
Should the scenario change each time?
Yes, rotate scenarios, but keep the scoring dimensions the same so you can compare results.
Safeguard can help with the inventory side of this work. SBOM and dependency scanning show where a package and version appear across your projects, and policies and gates can stop a flagged version at the pull request. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
