Tabletop Facilitation Guide (K5)¶

How to facilitate a SnowOps incident-response tabletop. A tabletop is a discussion-based rehearsal of an Incident Response Runbook (K1): the facilitator reveals a scenario one inject at a time, and participants talk through what they would do — citing the matching runbook step — without touching any real system. This guide is for the facilitator (owner: CO).

Pick a scenario from README.md, open the matching K1 runbook under ../incident/, and run the shape below. Capture the result in after-action-template.md.

1. Before the session (prep, ~30 min)¶

Pick the scenario and read it cold, plus the K1 runbook it maps to. You must know the runbook better than the room — your job is to push participants to find the right step, not to feed it to them.
Confirm the roster (4–8 people). Cover at minimum: Incident Commander (IC), the on-call/responder doing the hands-on work, a Comms owner, and an SME for the scenario (identity, data platform, network, etc.). The facilitator is not a participant — stay neutral.
Book 60 minutes and a room or call with one shared screen for injects.
Decide the difficulty. Default is "as written". To stretch a mature team, pre-plan one or two curveballs (the IC is unreachable; the obvious backup is also encrypted; the vendor won't confirm) and hold them for the debrief.
Have the after-action open (after-action-template.md) so you capture findings as they happen, not from memory afterward.

2. Ground rules (state these at kickoff)¶

Read these aloud at 0:00. They are what make a tabletop safe and useful:

Blameless. We are testing the runbook and the system, not the people. "We didn't know how to do X" is a finding about the runbook, never a fault of the person. This mirrors the blameless stance of K4 post-incident reviews.
No laptops into prod. No real consoles. Nobody runs a command, clicks a portal button, or pages anyone for real. If you'd run az ..., say so and say what you expect it to return — don't run it. (If you genuinely don't know the command, that's a finding: the runbook should make it copy-pasteable.)
Cite the step. When you say what you'd do, name the runbook phase/step you are following (e.g. "Containment step 1 — revoke active sessions"). "I'd just know to do it" is not good enough — the test is whether the runbook gets a cold responder there.
Stay in the scenario. Work only with the facts revealed so far. You may ask the facilitator "is X true?" — they'll answer in-character or reveal the next inject. Don't invent facts to make the problem easier.
Decisions over discussion. When the room circles, the IC makes the call and we move on. Capturing who decides is part of the exercise.

3. Timeboxing (the 60-minute shape)¶

Time	Segment	Facilitator does
0:00–0:05	Kickoff	State objective, scope, assumptions, ground rules. Assign roles.
0:05–0:45	Injects	Reveal injects in order (see §4). ~6–8 min per inject. After each, run the matching `K1` phase's discussion questions; capture decisions + gaps.
0:45–0:55	Debrief	Score the rubric (§5); surface top gaps and wins; spring any held curveballs as "what if".
0:55–1:00	After-action	Fill the after-action stub: gaps → owners → due dates.

Keep a visible clock. The most common failure mode is over-investing in inject 1 and never reaching Recovery — the Recovery and Post-Incident phases are exactly where runbooks are thinnest, so protect time for them. If a segment runs long, note "ran out of time on Recovery" as a finding and move on.

4. The inject-reveal method¶

An inject is a single new fact the facilitator reveals to escalate the scenario — an alert fires, a metric spikes, a customer calls, the attacker pivots. Each scenario ships 4–6 injects on a timeline, ordered to walk the team through the K1 phases in sequence.

How to run injects:

Reveal one at a time, in order. Read the inject (and its "facilitator notes" if the scenario has them) aloud / put it on screen. Do not show the whole timeline up front — the value is in reacting without hindsight.
Then ask the phase's discussion questions. Each inject is tied to a K1 phase (Identification → Containment → Eradication → Recovery → Post-Incident). Drive the team to the runbook for that phase.
Play the environment. If asked "what does the SigninLogs query return?", answer in-character with plausible detail consistent with the scenario — enough to let them decide, not enough to decide for them.
Watch for assumptions. Every "we'd just assume K3 auto-isolated it" or "Comms has a template for that, right?" is a gap candidate — note it and, where cheap, challenge it ("does it? where's the template?").
Don't rescue the team. Silence is fine. If they're stuck, the runbook failing to guide them is the result you came to measure. Note it and, only after capturing the gap, nudge them forward so the exercise completes.

5. Scoring with the rubric¶

Every scenario carries an evaluation rubric scored 1–4 per dimension. Score it in the debrief with the room — the conversation about the score matters more than the number. The shared rubric:

Dimension	1 — Ad hoc	2 — Partial	3 — Solid	4 — Strong
Detection & triage	Missed/ignored the signal	Spotted late, misclassified	Identified correctly, used `K1` Identification	Fast, correct class, confirmed out-of-band
Runbook fluency	Didn't know a runbook existed	Found it but improvised most steps	Followed the matching `K1` runbook	Followed it and caught a runbook gap/error
Containment decisions	No clear action	Slow / partial containment	Contained correctly per runbook	Contained fast, scoped blast radius, used `K3` correctly
Roles & comms	Confusion over who owns what	IC emerged late	Clear IC + Comms cadence	Crisp roles, stakeholder + client comms on time
Recovery & learning	No recovery/learning discussed	Recovery hand-waved	Recovery + a real follow-up named	Recovery validated + concrete `K4`-bound action items

Total /20. Below ~12 means rehearse this class again next quarter and prioritise its runbook gaps. The point of the number is to track movement over repeated runs, not to grade individuals.

6. Capturing the after-action¶

In the final 5 minutes, fill after-action-template.md live with the room watching:

What went well — keep these; they're the practices to reinforce.
Gaps found — every "the runbook didn't say", "we assumed", "we couldn't find" from the session. Be specific and cite the runbook step.
Improvement items — concrete edits to K1 runbooks, K3 playbooks, comms templates, or access; each with an owner and a due date.
Rubric score and the headline takeaway.

Then route the findings to K4. For any gap worth tracking, transcribe it into a K4-shaped review and file it through the E7 ticketing bridge that K4 uses (see apps/post-incident-review/), so a tabletop finding becomes a tracked, owned action item rather than a forgotten doc. Close the loop at the next quarterly run by checking those items shipped.

7. Common facilitator pitfalls¶

Answering your own questions. If you fill silences, you measure your own knowledge, not the team's. Wait.
Letting it become a lecture. Keep it a discussion — short prompts, then listen.
Skipping Recovery/Post-Incident. Guard the clock (§3). These phases expose the thinnest runbook content.
Soft-pedalling gaps. A comfortable tabletop where nothing broke usually means the scenario was too easy — add a curveball next time.
Not filing the after-action. An un-filed after-action is the same anti-pattern K4 exists to kill. File it.