Tabletop Scenario: <SCENARIO NAME>¶
Reusable template for a SnowOps incident-response tabletop (
K5). Copy this file toscenario-<slug>.md, fill every<PLACEHOLDER>, and keep the section headings — the offline gate (validate.py) checks for Objective, Roles, Injects, Discussion Questions (referencing the fiveK1phases), Evaluation Rubric, and After-Action, plus a cross-link to the matchingK1runbook under../incident/.How to facilitate this:
facilitation-guide.md. What a tabletop is and how findings feedK4:README.md.
Exercises runbook: ../incident/<RUNBOOK>.md — <incident class>.
| Field | Value |
|---|---|
| Scenario | <SCENARIO NAME> |
Incident class (K1) |
<compromise / ransomware / data-leak / ddos / vendor-breach> |
| Duration | 60 min |
| Participants | 4–8 |
| Difficulty | <standard / +curveballs> |
| Last run | <YYYY-MM-DD> |
Objective¶
<One or two sentences: what this tabletop tests. E.g. "Validate that on-call can
detect, contain, and recover from <incident> using ../incident/<RUNBOOK>.md, and
surface gaps in the runbook, the K3 automation, and the comms plan.">
Success looks like: the team reaches a defensible containment decision within the timebox, citing the matching runbook step at each phase, and ends with named follow-up actions.
Scope & assumptions¶
- In scope:
<the env (e.g. prod), the workload, the systems in play>. - Out of scope:
<things to declare off-limits so the room doesn't rat-hole>. - Assumptions (state at kickoff):
<the baseline reality — e.g. "K2 on-call paging is live; K3 SOAR playbooks are deployed in dry-run mode; Sentinel (J3) + Defender are ingesting logs; backups (L1) are healthy and tested by L4">. - Standing rule: discussion only — no real consoles, no real paging (see
facilitation-guide.md§2).
Roles¶
Assign before kickoff. The facilitator is neutral and not counted below.
| Role | Played by | Responsibility in this scenario |
|---|---|---|
| Incident Commander (IC) | <name> |
Owns decisions, declares severity, runs the response. |
| On-call responder | <name> |
Hands-on actions (would-be); drives the runbook. |
<Domain SME> |
<name> |
<e.g. identity / data platform / network / security>. |
| Communications | <name> |
Internal + client/stakeholder updates, status page. |
| Scribe (optional) | <name> |
Captures the timeline + decisions for the after-action. |
Injects (timeline)¶
The facilitator reveals these one at a time, in order (see
facilitation-guide.md§4).T+is minutes from the first inject. Each inject maps to aK1phase and drives that phase's discussion questions.
| # | T+ | Inject (revealed to the room) | Maps to K1 phase |
Facilitator notes (don't read aloud) |
|---|---|---|---|---|
| 1 | 0 min | <the first signal — an alert/report> |
Identification | <the "truth" behind it; what answers to give if probed> |
| 2 | <~8> min |
<escalation / new fact> |
Containment | <…> |
| 3 | <~16> min |
<new finding from investigation> |
Eradication & Investigation | <…> |
| 4 | <~26> min |
<the situation worsens or clarifies> |
Recovery | <…> |
| 5 | <~34> min |
<all-clear / residual risk surfaces> |
Post-Incident | <…> |
| 6 | <~40> min |
<optional curveball> |
<any> |
<hold for stretch> |
Discussion Questions (by K1 phase)¶
Tie each block to the inject above and push the team into
../incident/<RUNBOOK>.md. They must cite the runbook step, not improvise from memory.
Phase 1 — Identification¶
<Q: what signal told you this, and is it real? How do you confirm out-of-band per the runbook's Identification section?><Q: what incident class is this, and could it be more than one? (misclassification changes containment)>
Phase 2 — Containment¶
<Q: what is the first containment action per the runbook, and who is authorised to take it?><Q: which K3 SOAR playbook (if any) would you trigger, and in dry-run or enforce? What's the blast radius?>
Phase 3 — Eradication & Investigation¶
<Q: what query/log (cite the runbook's KQL) tells you scope and entry point?><Q: what do you rotate / revoke / patch to ensure the threat can't re-enter?>
Phase 4 — Recovery¶
<Q: what's the safe path back to normal per the runbook? How do you verify before re-enabling access?><Q: how long do you monitor, and what would make you re-open the incident?>
Phase 5 — Post-Incident / Lessons Learned¶
<Q: what does the runbook's Lessons-Learned section say to change? Legal/compliance/notification obligations?><Q: which finding becomes a tracked K4 action item, with what owner and due date?>
Evaluation Rubric¶
Score 1–4 per dimension (see facilitation-guide.md §5);
total /20.
| Dimension | 1 — Ad hoc | 2 — Partial | 3 — Solid | 4 — Strong | Score |
|---|---|---|---|---|---|
| Detection & triage | Missed signal | Late/misclassified | Correct, used Identification | Fast, confirmed out-of-band | |
| Runbook fluency | Unaware of runbook | Improvised most steps | Followed the runbook | Followed + caught a gap | |
| Containment decisions | No clear action | Slow/partial | Contained per runbook | Fast, scoped, correct K3 use |
|
| Roles & comms | Role confusion | IC late | Clear IC + cadence | Crisp roles + on-time client comms | |
| Recovery & learning | None discussed | Hand-waved | Recovery + a follow-up | Validated + concrete K4 items |
|
| Total | /20 |
After-Action¶
Fill live in the last 5 minutes; then expand into
after-action-template.mdand route trackable findings toK4(apps/post-incident-review/).
- Date / facilitator / attendees:
<…> - Rubric total:
<n>/20 - What went well:
<…> - Top gaps found (cite runbook step):
<…> - Improvement items:
<item — owner — due date — destination (K1 edit / K3 / comms / K4 issue)>