Skip to content

Tabletop Exercise Pack (K5)

Facilitated, discussion-based incident-response rehearsals that exercise the Incident Response Runbooks (K1) under docs/runbooks/incident/ — without touching production. Nobody touches a console; the team talks through how they would respond as a facilitator reveals escalating "injects". K5 is the "practice the playbook" complement to the IR estate.

Code → name lookup: docs/context/00-asset-glossary.md. These are no-cost, offline doc assets — running one needs only a room (or call), a facilitator, and the matching K1 runbook open on screen.

Where K5 sits in the IR estate

Code Capability Role Where
K1 Incident Response Runbooks The playbook — five incident classes, each Identification→Containment→Eradication→Recovery→Post-Incident. docs/runbooks/incident/
K2 On-Call Integration The pager — Sentinel/Defender incident → PagerDuty/Opsgenie/Slack. modules/azure/oncall-integration/
K3 Sentinel SOAR Playbooks The automation — isolate account / disable SP / quarantine VM (dry-run/enforce). apps/sentinel-playbooks/
K4 Post-Incident Review The learning loop — closed incident → blameless PIR + tracking issue via E7. apps/post-incident-review/
K5 Tabletop Exercise Pack (this dir) The rehearsal — practise K1 end-to-end on paper before a real event forces the issue. docs/runbooks/tabletop/

K1 is what you follow under fire; K5 is how you find out — calmly, in a conference room — whether the team can actually follow it, whether the runbook step you'd reach for exists, and whether K2/K3 would do what you assume. A runbook nobody has ever rehearsed is a hope, not a plan.

The five scenarios

Each tabletop maps 1:1 to a K1 incident class and forces participants to cite the matching runbook's steps by phase.

Tabletop Exercises (K1) Triggering injects (flavour)
Account Compromise incident/compromise.md Impossible-travel sign-in, PIM elevation, Defender for Identity alert.
Ransomware & Malware incident/ransomware.md Defender for Servers alert, mass file modification, encrypted Azure Files share.
Data Exfiltration incident/data-leak.md DLP alert, abnormal storage egress, GitHub secret-scanning hit.
DDoS incident/ddos.md Front Door/WAF alert, Azure DDoS Protection metric, customer timeout reports.
Vendor / Supply-Chain Breach incident/vendor-breach.md Vendor breach disclosure, suspicious vendor SP sign-in, OIDC token misuse.

Authoring or extending a scenario? Start from tabletop-template.md and keep the section headings — the offline gate (validate.py) checks for them.

Cadence

Tier Cadence Who Notes
prod clients Quarterly CO facilitates; on-call + IC + Comms attend Rotate through all five scenarios over the year; repeat the class of the most recent real incident.
staging / internal Twice a year CO or a senior engineer Lighter touch; good for onboarding new on-call.
after a real incident Within <30 days> the responders Re-run the matching class to validate the K4 action items actually landed.

Owner: CO. Each run produces an after-action (see below) that is filed and revisited at the next run.

How to run one (the 60-minute shape)

A standard tabletop is 60 minutes, run by one facilitator with 4–8 participants playing real roles. The facilitator drives; participants respond to injects by saying what they'd do and which runbook step they'd follow — not by doing it.

Time Segment What happens
0:00–0:05 Kickoff Facilitator states the objective, scope, ground rules (blameless, no real consoles), and the scenario assumptions.
0:05–0:45 Injects Facilitator reveals 4–6 timed injects in order. After each, the team works the matching K1 phase and answers the discussion questions. The facilitator captures decisions, gaps, and "we'd assume X" moments.
0:45–0:55 Debrief Score against the rubric; surface the top gaps and what worked.
0:55–1:00 After-action Facilitator captures the after-action stub (gaps → owners → dates).

Full method (prep, timeboxing, the inject-reveal technique, ground rules, scoring): facilitation-guide.md.

How after-actions feed K4

The output of every tabletop is an after-action report (after-action-template.md): what went well, gaps found, runbook/automation improvement items, owners, and dates.

It is intentionally shaped to seed a K4 post-incident review (apps/post-incident-review/): the after-action's timeline, contributing factors, and action items map onto K4's blameless-PIR sections, so a tabletop finding can be filed as a tracked issue through the same E7 ticketing bridge K4 uses — rather than dying in a doc nobody revisits.

A tabletop is a rehearsal, not a real incident, so it does not run the K4 collector against Sentinel. Instead, the facilitator transcribes the after-action into a K4-shaped review for any finding worth tracking, and files it as an action item. Real closed incidents still flow through K4 automatically; tabletops give K4 something to chew on before an incident happens.

Cross-references