An exercise finding without an owner never ships. Turn tabletop outcomes into tracked work that lands as controls, alerts and runbook edits.
45 min 195 XPSkills: Exercises, Follow-through, Control design
Brief
The tabletop exercise is GRC's favourite ritual: a scenario, a conference room, a facilitated discussion, and a findings document that everyone agrees is valuable. Twelve months later the same exercise produces the same findings, because nothing about the findings ever shipped.
The engineering fix is to treat exercise output as work intake. A finding is not an observation: it is a ticket with an owner, a due date, and a definition of done that ends in a control, an alert, or a runbook change.
An exercise that finds the same gap twice is not a detection control. It is a tradition.
Findings are intake, not minutes
The loop that works is short: exercise, findings list, tracked tickets, shipped fixes, and the next exercise tests whether the fixes hold. Every hop has an owner. The failure mode is the hop from findings to tracked work: findings get written into a report, the report gets read, and reading is mistaken for progress.
Measure the loop with the closure rate: what fraction of exercise findings shipped as changes before the next exercise ran. It is the only exercise metric that cannot be gamed by holding easier exercises.
The loop is the control. Break it at the ticket stage and the exercise is theatre.
Design exercises that can fail
A tabletop everyone passes taught nobody anything. Realistic scenarios include ambiguity, missing information and time pressure, because real incidents do. Measure time to detect and time to decide during the exercise; those two numbers, tracked across exercises, are your actual readiness trend.
Ground the scenario in your own environment: your runbooks, your on-call rota, your vendors. An exercise about a generic ransomware scenario tests generic knowledge. An exercise where the scenario is 'your payroll vendor's fourth party is breached at 2am Saturday' tests your system.
Same findings, different destination. Only one of these reduces risk.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: Six findings, zero owners
Scenario sim+65 XP
Read the brief and answer both questions.
Incident brief
The annual ransomware tabletop went well, according to the facilitator's report: 'strong engagement, valuable discussion.' The report lists six findings, each phrased as 'the organisation should consider...'. None name an owner. None have dates. The report is filed next to last year's report, which contains five of the same six findings.
The CISO presents both years to the board as 'continuous improvement'.
Term bank, not all of these are right
continuous improvementownerdue datefacilitation
1.1What must every exercise finding name before it can be tracked? (one word)
1.2Alongside the owner, what must each finding carry so 'later' cannot mean 'never'? (two words)
Task 2: The exercise designed to be passed
Scenario sim+65 XP
Read the brief and answer both questions.
Incident brief
Compliance runs the incident exercise. The scenario is emailed in advance so nobody is caught off guard, the 'injects' pause whenever discussion gets interesting, and everyone playing has done the exercise three years running. The report concludes: 'response time: excellent. All participants performed their roles.'
A new engineer asks why the exercise never touches the part of the system where the last real incident happened. 'Too disruptive,' compliance says. 'We need a clean pass for the audit.'
Term bank, not all of these are right
clean passrealistic scenariotime to detectparticipation rate
2.1What kind of scenario, grounded in your own systems, with ambiguity and pressure, is required for an exercise to teach anything? (two words)
2.2Which measurement, taken during the exercise, tells you how fast the team spots that something is wrong? (three words)
Task 3: Findings, filed and forgotten
Scenario sim+65 XP
Read the brief and answer both questions.
Incident brief
Your team has run four tabletop exercises this year: genuinely hard ones, with real findings. The findings live in a wiki page titled 'Exercise Findings 2026'. The page is well organised and thoroughly linked. Nothing in the page can produce a notification, a reminder, or a metric. Twelve of twenty findings are marked 'in progress' with no last-updated date.
Asked how the programme is improving, the GRC lead points to the page view count.
Term bank, not all of these are right
page viewstracked workclosure ratedocumentation
3.1What should findings become: rows in a system that can notify, remind, and measure? (two words)
3.2What metric, findings shipped before the next exercise, tells you whether the loop is working? (two words)
Labs
85 bonus XP
Hands-on work. You edit the artefact, the server runs the checks: the expectations and the reference solution never reach your browser.
Four exercises produced twenty findings. They live in a wiki page titled 'Exercise Findings 2026'. Twelve are marked 'in progress' with no date; the page view count is the programme's evidence of improvement.
Specify the loop instead: exercises that can fail, findings that enter the work system with an owner and a due date, ship targets that end in a control or an alert, and a closure rate reported per cycle.
Current practice
scenario: emailed in advance, "so nobody is caught off guard"
injects: paused when discussion gets interesting
findings: wiki page, well organised
tracking: none (page views reported to leadership)
evidence of improvement: "strong engagement"
1
2
3
4
5
6
7
8
9
10
11
12
Checks
Scenario can fail and is grounded in your own systems
Time to detect and time to decide are measured
Findings land in the work tracker, not a wiki
Owner and due date are required before a finding leaves the room
Every finding has a ship target: control, alert or runbook change
