Tabletop After-Action Report (K5)¶

Structured output of one tabletop exercise. The facilitator fills this in the last few minutes of the session (see facilitation-guide.md §6) and files it. It is shaped to seed a K4 post-incident review: the sections below map onto K4's blameless-PIR structure (summary · timing · timeline · contributing factors · action items · lessons), so any trackable finding can be filed as an issue through the same E7 ticketing bridge K4 uses (apps/post-incident-review/).

Copy this file per run to e.g. after-actions/<YYYY-MM-DD>-<scenario>.md. A tabletop with no filed after-action is the anti-pattern K4 exists to kill.

Field	Value
Scenario	`<account-compromise / ransomware / data-exfiltration / ddos / vendor-breach>`
`K1` runbook exercised	`<../incident/<RUNBOOK>.md>`
Date / time (UTC)	`<YYYY-MM-DD HH:MM>`
Facilitator	`<name>` (owner: CO)
Participants (role — name)	`<IC — …, On-call — …, SME — …, Comms — …>`
Difficulty	`<standard / +curveballs>`
Rubric total	`<n>/20`

1. Summary¶

<2–3 sentences: what scenario was run, how the team performed at a high level, and the single most important takeaway. Blameless — describe the system/runbook, not individuals. This maps to a K4 PIR "summary".>

2. Timing (rehearsal clock)¶

These are exercise times (when the team reached each phase against the inject clock), not a real MTTR — but they map to K4's timing fields and show where the response dragged.

Milestone	Inject T+	Reached at (exercise)	Notes
Detection / triage (Identification)	0 min	`<…>`	`<…>`
First containment action	`<…>`	`<…>`	`<…>`
Scope understood (Eradication)	`<…>`	`<…>`	`<…>`
Recovery decision	`<…>`	`<…>`	`<…>`
Post-incident / all-clear	`<…>`	`<…>`	`<…>`

3. What went well¶

Practices to reinforce. Be specific.

<…>
<…>

4. Gaps found¶

The core output. Every "the runbook didn't say", "we assumed", "we couldn't find", or "we ran out of time on X". Cite the runbook phase/step. These become K4 contributing factors and feed the action items below.

#	Gap (what failed / was missing)	Runbook step / phase	Severity (H/M/L)
1	`<…>`	`<e.g. compromise.md Containment §2>`	`<…>`
2	`<…>`	`<…>`	`<…>`
3	`<…>`	`<…>`	`<…>`

5. Improvement / action items¶

Concrete, owned, dated. Destination says where it lands: a K1 runbook edit, a K3 SOAR playbook change, a comms-template fix, an access/RBAC change, or a tracked K4 issue. These map 1:1 onto a K4 PIR's action-item checklist.

#	Action item	Owner	Due	Destination	Tracked issue (`K4`/`E7`)
1	`<…>`	`<name>`	`<YYYY-MM-DD>`	`<K1 edit / K3 / comms / RBAC / K4>`	`<issue link or "to file">`
2	`<…>`	`<name>`	`<YYYY-MM-DD>`	`<…>`	`<…>`
3	`<…>`	`<name>`	`<YYYY-MM-DD>`	`<…>`	`<…>`

6. Lessons learned¶

<Narrative: what this rehearsal told us about our IR readiness for this incident class. What surprised us. Whether the runbook, K2 paging, K3 automation, and comms plan are actually adequate. This maps to a K4 PIR "lessons" section.>

7. Routing to K4¶

High/Medium gaps from §4 transcribed into K4-shaped reviews and filed via the E7 ticketing bridge (one tracked issue per material finding).
Action items in §5 have owners + due dates and are linked to their tracked issues.
Next quarterly run scheduled; this scenario class flagged for re-run if rubric total < 12.
After-action filed at after-actions/<YYYY-MM-DD>-<scenario>.md and linked from the previous run's "follow-up" items.

Sign-off¶

Field	Value
Facilitator	`<name>`
IC (reviewed)	`<name>`
Date	`<YYYY-MM-DD>`
Rubric total	`<n>/20`
Re-run next quarter?	☐ yes ☐ no
Findings filed to `K4`?	☐ yes ☐ n/a (no material findings)