How Often Should You Conduct a Tabletop Exercise?
How often should you conduct a tabletop exercise? Cadence by audience, triggers for extra sessions, a 12-month calendar and the metrics to report.
Most organisations should run a tabletop exercise at least once a year, and many run several: a technical tabletop each quarter, an executive exercise once or twice a year and a cross-functional exercise annually. Add extra sessions whenever something material changes, such as a new plan, a merger or a significant incident.
None of these numbers is a universal rule. They reflect common practice and the minimums some frameworks set. What matters more than frequency is that exercises form a programme: each one builds on the last, gaps are tracked to closure and retested, and leadership sees whether the organisation is actually getting better. This guide shows how to build that programme for a year.
Why a programme beats one-off exercises
A single tabletop produces a list of gaps. Without a programme, that list sits in a report, the people who took part change jobs and next year's exercise finds the same gaps again. A programme adds three things:
- Continuity. Findings from one exercise become objectives for the next.
- Coverage. Different audiences and scenarios are exercised over the year, rather than the same team rehearsing ransomware every time.
- Evidence. A documented series of exercises, actions and retests is far more convincing to an auditor, regulator or board than a single report.
NIST SP 800-84 describes this kind of test, training and exercise programme for IT plans, and HSEEP's building-block approach points the same way: plan a sequence of exercises that increase in complexity as capability matures.
Cadence by audience
Different groups need different rhythms. Treat this as a starting point to adjust, not a standard.
| Audience | Common cadence | Duration | Focus | Typical scenarios |
|---|---|---|---|---|
| Technical response team (SOC, IR, IT ops, cloud) | Quarterly | 2–3 hours | Detection, escalation, containment, recovery procedures | Phishing and credential theft, cloud key leak, identity provider compromise |
| Executive or crisis team | Once or twice a year | 90–120 minutes | Decisions: shutdown, ransom, disclosure, communications | Ransomware, data breach, deepfake fraud |
| Cross-functional (IT, legal, privacy, comms, HR, business units) | Annually | Half day | Hand-offs between functions, notification, customer impact | Data breach notification, supplier compromise |
| Board | Annually or every other year | 60–90 minutes | Oversight, escalation thresholds, risk appetite | Shortened executive scenario |
| Specific teams (finance, service desk, OT) | Annually or after changes | 60–90 minutes | Team-specific procedures | Business email compromise, OT/ICS incident |
A quarterly technical rhythm works because technical teams change fastest: new tools, new cloud services, staff turnover. Executive exercises are less frequent because diaries are harder, but they carry the decisions that most often go untested. The executive tabletop guide covers how to run them.
Smaller organisations can compress this to one combined exercise a year plus a short technical session. The small business guide shows a lighter version.
Triggers for an extra exercise
Scheduled exercises cover the steady state. Some events justify an exercise outside the cycle, usually within a few months:
- A new or substantially revised incident-response plan. Test it before you need it.
- A merger, acquisition or divestment. Two sets of plans, contacts and tools now have to work together, or separate cleanly.
- A reorganisation or key leadership change. New people hold decision rights they have never exercised.
- A significant incident or near-miss. After the post-incident review, exercise the fixes to confirm they work.
- A new regulatory obligation. For example, new reporting deadlines under NIS2 or DORA, or new disclosure rules for listed companies.
- A major technology change. Moving to a new identity provider, a cloud migration or outsourcing a critical service to a new provider.
- A new critical supplier or MSP. Test how the incident process works across the contract boundary.
Keep these short and targeted. A 90-minute tabletop on the one process that changed is more useful than a full exercise that dilutes the point.
A sample 12-month calendar
This example is for a mid-sized organisation with an in-house security team. It rotates audiences and scenarios so that, over the year, the main threats and the main teams are all covered at least once.
| Month | Exercise | Audience | Scenario | Main objective |
|---|---|---|---|---|
| January | Programme planning | Programme owner, sponsor | — | Review last year's register; set objectives and calendar |
| February | Technical tabletop | IR, SOC, IT ops | Phishing and credential theft | Escalation and account containment within target times |
| March | Finance team tabletop | Finance, service desk | Business email compromise | Payment verification and bank recall process |
| April | Executive tabletop | Crisis team | Ransomware | Shutdown authority and ransom governance |
| May | Technical tabletop | IR, cloud, platform | Cloud access key leak | Key revocation and blast-radius assessment |
| June | Drill | IT ops | Backup restore of a tier-1 system | Validate restore time against the recovery objective |
| July | Mid-year review | Programme owner, sponsor | — | Improvement register status; adjust H2 plan |
| August | Technical tabletop | IR, IAM, service desk | Identity provider compromise | Recovery of identity services and out-of-band access |
| September | Cross-functional tabletop | IT, legal, privacy, comms, business | Data breach notification | Notification decisions within regulatory deadlines |
| October | Executive tabletop | Crisis team, observed by board members | Third-party vendor breach | Supplier dependency and customer communication |
| November | Technical tabletop (retest) | IR, SOC, IT ops | Variant of February's scenario | Retest the year's top technical gaps |
| December | Annual report | Sponsor, board | — | Metrics, closed actions, next year's priorities |
Several of these can be run from the scenario library. You can also run them live with the exercise runner, which keeps inject timing, decisions and the after-action export in one place, making it easier to compare exercises over the year.
Tracking improvement actions across exercises
The improvement register is the spine of the programme. Keep one register for all exercises, not one per report.
Each entry should record:
| Field | Example |
|---|---|
| ID | IA-2026-014 |
| Source exercise | April executive tabletop |
| Finding | No documented threshold for authorising shutdown of revenue systems |
| Capability or objective | Containment authority |
| Action | Add shutdown authority and cost thresholds to crisis plan |
| Owner | COO |
| Due date | 30 June |
| Status | Open / in progress / closed / accepted risk |
| Retest | November technical tabletop; next executive exercise |
| Retest result | Pass / partial / fail |
Three rules keep the register honest:
- Every action has one named owner and a date. "IT" is not an owner.
- Closure needs evidence. An updated plan, a completed drill, a configuration change. "Discussed" is not closed.
- Major gaps are retested. Schedule the retest when you log the action. The next exercise for that audience should include at least one inject that targets the gap.
The after-action report guide covers how each report feeds the register. Rate capabilities consistently, on the same scale each time, so that results can be compared across the year.
Metrics to report
Leadership does not need a dashboard of twenty measures. Four or five, reported twice a year, tell a clear story.
| Metric | What it shows | How to measure |
|---|---|---|
| Exercises completed against plan | Whether the programme is happening | Count per quarter vs calendar |
| Improvement actions closed on time | Whether findings lead to change | Closed by due date ÷ due in period |
| Repeat findings | Whether fixes actually work | Gaps found again in retest ÷ gaps retested |
| Time to key decisions in exercise | Speed and clarity of decision-making | Exercise-clock time to declare severity, approve containment, decide on notification |
| Coverage | Breadth of the programme | Audiences, scenarios and plan sections exercised in the last 12 months |
Time-to-decision needs care. Exercise time is compressed and scenarios differ, so compare like with like: the same decision, in similar scenarios, with similar inject timing. The trend matters more than the absolute number.
Avoid metrics that score individuals or teams against each other. They discourage candour, and candour is what makes exercises useful.
How compliance frameworks set minimums
Many organisations start a programme because an auditor asks for evidence. Frameworks typically set a floor, not a target.
- PCI DSS v4.0, requirement 12.10.2: the incident response plan is reviewed, updated and tested at least once every 12 months. This is one of the few explicit frequencies.
- ISO/IEC 27001:2022 includes incident management controls (Annex A 5.24–5.28) and ICT readiness for business continuity (5.30), and clause 9 requires performance evaluation. Exercises are a common way to show the controls work.
- SOC 2 criteria cover responding to and recovering from incidents (CC7.3–CC7.5), and the availability criteria include testing recovery plan procedures (A1.3).
- HIPAA requires security incident procedures and a contingency plan, with testing and revision procedures as an addressable specification.
- NIS2 and DORA expect incident handling, business continuity and crisis management, and testing of their effectiveness. DORA explicitly includes testing ICT business continuity plans and crisis communication.
The compliance requirements guide goes through each framework in more detail. Build the programme around your risks first, then check that it meets every applicable minimum, rather than the other way round.
Getting started
If you have no programme today:
- Name a programme owner and an executive sponsor.
- Run one tabletop with the core response team in the next quarter, using a ready-made scenario.
- Start the improvement register with its findings.
- Book an executive exercise within six months.
- Draft the calendar for the next 12 months using the table above as a template.
- Report the first set of metrics at the end of the year.
The first year is about habit. Once exercises are routine, the programme can grow in difficulty, audiences and realism, and add drills or functional exercises as described in types of security exercises.
Related
Frequently asked questions
How often should you conduct a tabletop exercise?
At least once a year for the core incident-response process, which is also the minimum several frameworks expect. Many organisations go further: a technical tabletop each quarter, an executive exercise once or twice a year and one cross-functional exercise annually. Add extra sessions after major changes such as a new plan, a merger, a reorganisation, a significant incident or a new regulatory obligation.
Is an annual tabletop exercise required?
It depends on what applies to you. PCI DSS v4.0 requirement 12.10.2 expects the incident response plan to be reviewed, updated and tested at least once every 12 months. Other frameworks, including ISO/IEC 27001, SOC 2, HIPAA, NIS2 and DORA, expect incident response or continuity capabilities to be tested or their effectiveness assessed, without always prescribing a tabletop or a frequency. Annual is a common baseline.
What should a tabletop exercise program include?
A named owner and sponsor, a calendar that rotates audiences and scenarios, clear objectives for each exercise, a single improvement register that tracks actions across exercises, a retest step for major gaps and a small set of metrics reported to leadership. The programme should also define triggers that prompt an extra exercise outside the normal cycle.
How do you measure improvement across tabletop exercises?
Track the improvement actions from each after-action report to closure and report the percentage closed on time. Measure the exercise time it takes to reach key decisions, such as declaring severity or approving containment, and compare it across exercises using similar scenarios. Record whether gaps found previously recur when retested. Avoid scoring individuals.