Blog
The gap came back at the second tabletop
A March finding named an owner and a date. By October nobody had checked either, and the second tabletop spent its first six minutes re-finding what the first one already found.
On 11 March 2026, a ransomware inject at an incident-response tabletop reports mass file rename on build-runner-04. The plan's containment step names the Falcon console: isolate the host there. Priya S, on-call that night, opens Falcon and cannot find build-runner-04, because the company migrated to SentinelOne in January and nobody updated the plan. She spends six minutes in the wrong console before the facilitator stops the clock and writes a finding: step 4 of the containment plan names a decommissioned EDR console. Owner: Priya S. Fix by 10 April 2026. The finding goes into a slide in the retro deck, next to two others from the same sitting, and the meeting ends.
On 29 October 2026, a second tabletop runs a different ransomware inject against a different host. Priya moved to a different team in June. Jae K, now on-call, opens the same plan, reads the same step 4, and goes looking for Falcon. It takes five minutes to learn it does not exist. The facilitator pulls up the March retro deck to check. The finding is still there, worded the way it was in March: no ticket number, no later comment, nothing to say whether anyone opened the plan between the two sittings.
A weak finding reads:
Action item: update the IR plan to reference SentinelOne instead of Falcon. Owner: Priya.
A strong one reads:
2026-03-11. Finding: containment step 4 names Falcon console, decommissioned 2026-01-14 in favor of SentinelOne. Owner: Priya S. Ticket OPS-2291. Due 2026-04-10. Verification: before the next tabletop is scheduled, confirm OPS-2291 is closed and the plan's step 4 names the current console, or carry the finding forward with a new owner and a new date and write why it is still open.
Both describe the same six minutes. Only the second can be checked by someone who was not Priya and was not in March's room. The first costs you October: a second tabletop spends its own clock re-finding a gap you already paid once to find, and the record cannot say whether anyone tried to close it or simply forgot it existed.
A slide in a retro deck is not a system that reminds anyone
Nobody hid the finding. It is written down, in the deck from the session where it was found, which is exactly where nobody looks again until the next tabletop is already running. A retro deck is a record of what the room noticed. It is not a tracker, it does not have a due date field anyone's calendar reads, and it does not page an owner when 10 April passes with the plan unchanged. The four-part shape for a gap, what the plan said, what the room did, who owns the fix, by when, gets you an owner and a date. It does not get you a system that notices when the date passes and nothing happened.
Closed on a ticket is not verified in the plan
Suppose Priya had filed OPS-2291 in March and marked it closed in April. That is still a self-report. The only independent check a tabletop can give you is whether the gap shows up again, and that check costs a full second sitting to run. The honest limit is this: an evidence packet can show that a finding had an owner, a ticket, and a date, and whether that ticket was marked closed before the next exercise. It cannot show that the plan was actually edited correctly, or that Jae K would have found the right console if he had opened it before the exercise. Only reading the current plan, or hitting the same inject again, proves that. A packet that says closed is reporting a status, not confirming a fact.
Check the open findings before you book the room
The fix is cheap and it has nothing to do with running a better tabletop. Before scheduling the next one, pull every finding from the last one and read the plan against each of them: is the step now correct, yes or no. Close the ones that check out, with who checked and when. Carry the rest forward with a new owner and a new date, in the same packet, not a fresh one that starts the count at zero. The free plan self-check asks exactly this: whether the last exercise produced findings with owners, and whether they were closed. Run it between sittings, not just before the next one, and OPS-2291 would have surfaced in July instead of in October's room.
What the packet records
Write the finding and its follow-up in the free evidence template: the plan sentence that was wrong, the ticket, the owner, the due date, and a line for who verified the fix and when, separate from who marked the ticket closed. The post-incident review template is built for the same handoff on a real incident, carrying a finding from the hot debrief into something somebody is still reading months later. Both sit in the template library. If the Falcon line had been in that shape in March, the October room would have opened with a line that said still open, 232 days, new owner, instead of discovering it live. A file that only makes sense with the Slack thread or the slide deck still open is the same miss covered in the packet-hygiene post: a finding you cannot act on without the original meeting is not a finding, it is a memory.
The packet from October does not show that SentinelOne is configured correctly, or that Jae K would isolate the right host on a real night. It shows that the same six minutes happened twice, 232 days apart, and names whose job it was to stop that.
Bottom line: an owner and a date on a slide is a sentence, not a system. Check your last tabletop's findings against the current plan before you book the next room, or the next room checks them for you, on the clock, during the exercise meant to test something else.