Which compliance frameworks require a tabletop exercise?

Very few name tabletop exercises specifically. Most require that incident response or continuity plans are tested, and a tabletop is a widely accepted way to do that for the people and process side. PCI DSS v4.0 requirement 12.10.2 is the most explicit, requiring the incident response plan to be tested at least once every 12 months. SOC 2, ISO 27001, NIS2, DORA and HIPAA express testing expectations in more general terms.

Does a tabletop exercise satisfy SOC 2?

It can support it. SOC 2 criteria CC7.3 to CC7.5 cover evaluating, responding to and recovering from security incidents, and A1.3 in the Availability category covers testing recovery plan procedures. Auditors commonly accept a documented tabletop as evidence that incident response procedures were exercised, but what counts depends on how your controls are written and on your auditor. Recovery testing under A1.3 usually also needs technical restore evidence.

How often should you run a tabletop exercise for compliance?

At least once every 12 months is the common baseline, and PCI DSS makes annual incident response plan testing explicit. Also exercise after significant changes, such as a new incident response plan, an acquisition, a major system migration or a real incident. Many organisations run a technical exercise and a separate executive exercise each year to cover both operational and governance expectations.

What evidence do auditors want from a tabletop exercise?

Typically the exercise plan and objectives, the scenario and injects, an attendance record, the after-action report, and an improvement plan with owners and due dates. Stronger evidence also shows that findings were closed and retested, and that the incident response plan was updated as a result. An exercise with no follow-up is weak evidence regardless of how well it ran.

Tabletop Exercise Requirements by Compliance Framework

Few compliance frameworks require a "tabletop exercise" by name. Most require that incident response or business continuity plans are tested periodically, and a documented tabletop is the most common way organisations meet that expectation for the people, decisions and coordination side of the plan. PCI DSS is the most explicit: the incident response plan must be tested at least once every 12 months.

This page maps the main frameworks to their testing expectations in one place, then covers the evidence auditors typically look for and how often to exercise. It is written for security and compliance teams who answer to several frameworks at once and want one exercise programme that serves all of them.

Note: This page summarises framework expectations for planning purposes. It is not legal or audit advice; confirm requirements against the current text of each framework and with your auditor or counsel.

Why the wording matters

Frameworks usually say "test the plan", not "run a tabletop". That gives you freedom, but it also puts the burden on you to show the test was meaningful. Two consequences follow:

A tabletop evidences process, not technology. It shows people know their roles and can make decisions. It does not show that backups restore or that failover works. Where a framework expects recovery testing, pair the tabletop with technical tests.
The documentation is the evidence. An auditor cannot observe an exercise that happened six months ago. They can read the plan, the attendance, the report and the improvement tracker.

The mapping table

Framework	Relevant requirement	What it expects	How a tabletop helps
SOC 2 (AICPA Trust Services Criteria)	CC7.3–CC7.5; A1.3 (Availability)	Evaluate security events, respond to incidents through a defined programme, recover from incidents; test recovery plan procedures	Exercises the response programme end to end; recovery testing under A1.3 usually also needs technical restore evidence
ISO/IEC 27001:2022	Annex A 5.24–5.28, 5.29, 5.30; clause 9	Incident management planning, assessment, response, learning and evidence handling; security during disruption; ICT readiness that is planned, implemented, maintained and tested; performance evaluation	Tests the 5.24–5.27 process in practice; feeds learning from incidents, internal audit and management review
PCI DSS v4.0	Requirement 12.10.2	Incident response plan reviewed, updated as needed and tested at least once every 12 months	A documented annual tabletop is a common way to evidence the test
NIST CSF 2.0	Respond and Recover functions; improvement outcomes	Outcomes-based; improvements identified from tests and exercises	Produces the lessons learned that drive improvement outcomes
NIST SP 800-61 Rev. 3	Incident response recommendations aligned to CSF 2.0	Guidance, not a mandate, for US federal agencies and a common reference elsewhere	Scenario design and objectives can follow its incident response activities
NIST SP 800-84	Test, training and exercise programmes	Guidance on designing, running and evaluating tabletop and functional exercises	Provides a recognised methodology to cite in your exercise plan
NIS2 (Directive (EU) 2022/2555)	Arts. 20, 21, 23	Management oversight; incident handling, continuity and crisis management; assessing effectiveness of measures; 24 h / 72 h / one-month reporting	Tests reporting clocks and management decisions; see the NIS2 and DORA tabletop guide
DORA (Regulation (EU) 2022/2554)	Arts. 11, 19, 24–26	Testing ICT continuity plans and crisis communication; major incident reporting; resilience testing programme; TLPT for certain entities	Covers scenario-based testing of response and reporting; does not replace TLPT
HIPAA Security Rule	45 CFR §164.308(a)(6), (a)(7)(ii)(D)	Security incident procedures; contingency plan testing and revision (addressable)	Tests incident procedures and contingency plans; see the HIPAA tabletop guide
US SEC (2023 rules)	Form 8-K Item 1.05	Disclose material cybersecurity incidents within four business days of determining materiality	Rehearses the materiality determination and disclosure process
Cyber insurance	Underwriting questions	Varies by insurer and policy	Gives a documented answer when asked whether the IR plan is tested

The sections below add the detail behind each row.

SOC 2

SOC 2 reports are built on the AICPA Trust Services Criteria. In the common criteria, CC7.3 covers evaluating security events to determine whether they are incidents, CC7.4 covers responding to identified incidents through a defined incident response programme, and CC7.5 covers recovering from them. If the Availability category is in scope, A1.3 covers testing the recovery plan procedures that support system recovery.

The criteria do not prescribe a tabletop. Your own control descriptions do. If your system description says "the incident response plan is tested annually through a tabletop exercise", the auditor will test exactly that, so write the control to match what you actually do. For A1.3, a tabletop covers the decision-making side of recovery; restore tests or failover tests cover the technical side.

ISO/IEC 27001:2022

The 2022 revision groups incident management in Annex A controls 5.24 to 5.28: planning and preparation, assessment and decision on events, response, learning from incidents, and collection of evidence. Control 5.29 covers maintaining information security during disruption, and 5.30 covers ICT readiness for business continuity, which is expected to be planned, implemented, maintained and tested.

A tabletop is a natural way to demonstrate 5.24 to 5.27 in practice, and its findings feed clause 9 (performance evaluation, including internal audit and management review) and clause 10 (improvement). Certification auditors typically look for a planned test, recorded results and corrective actions that were followed through.

PCI DSS v4.0

Requirement 12.10.2 is the clearest testing requirement on this page: at least once every 12 months, the security incident response plan is reviewed, updated as needed and tested. Assessors usually want to see the plan version, the test record and evidence that the plan was updated when the test found gaps.

Design the scenario so it touches the elements your plan must contain under 12.10.1, such as roles, communication and contact strategies, including notification of payment brands and acquirers, and business recovery. A cardholder data compromise scenario is the obvious fit; a ransomware scenario affecting the payment environment also works.

NIST CSF 2.0, SP 800-61r3 and SP 800-84

NIST publications are guidance for most private organisations, but they are widely used as the reference structure for programmes and audits.

CSF 2.0 organises outcomes under six functions: Govern, Identify, Protect, Detect, Respond and Recover. Its improvement outcomes explicitly include identifying improvements from tests and exercises.
SP 800-61 Rev. 3 (2025) replaced the older incident handling guide with recommendations aligned to CSF 2.0. Use it to choose which response activities your objectives should cover.
SP 800-84 is NIST's guide to test, training and exercise programmes for IT plans and capabilities. It describes tabletop and functional exercises and is a good methodology to cite in an exercise plan.

NIS2 and DORA

In the EU, NIS2 requires essential and important entities to have incident handling, business continuity and crisis management, and ways to assess the effectiveness of their measures, with management bodies accountable. Its reporting clocks (early warning within 24 hours, notification within 72 hours, final report within one month) are ideal exercise material. DORA requires financial entities to test ICT continuity plans and crisis communication, report major ICT-related incidents, and run a resilience testing programme; scenario-based tests are among the test types it lists. The NIS2 and DORA tabletop guide covers scenario design and a full evidence mapping.

HIPAA

For US healthcare organisations and their business associates, the Security Rule requires security incident procedures (§164.308(a)(6)) and a contingency plan (§164.308(a)(7)), with testing and revision of the plan as an addressable specification. Breach notification adds a 60-day outer limit for notifying individuals. The HIPAA tabletop guide covers attendees, scenarios and documentation.

SEC cybersecurity disclosure

US public companies must disclose material cybersecurity incidents on Form 8-K under Item 1.05 within four business days of determining that the incident is material. The rules do not require a tabletop, but the materiality determination is a decision process involving security, legal, finance and executives, often under uncertainty. That makes it a strong exercise objective: who convenes the materiality discussion, what information they need, who decides, and how the decision and its timing are documented.

Cyber insurance

Insurers do not follow a single standard. Underwriters commonly ask whether an incident response plan exists and whether it has been tested, and policies often include specific conditions, such as using panel response firms or notifying the insurer promptly. A tabletop helps in two ways: it gives you a documented answer for the application, and it tests whether your team knows the policy conditions at the moment they matter. Include the insurer notification step in the scenario and invite whoever holds the policy details.

What evidence auditors typically look for

Across frameworks, the evidence pack looks remarkably similar. Build it once and reuse it.

Evidence	What it shows	Notes
Exercise plan and agenda	The test was planned with defined objectives	Map objectives to the requirements you are evidencing
Attendance record	The right roles took part	Names, roles, primary or deputy; include executives where governance is in scope
Scenario and inject list	What exactly was tested	Include the plan version tested
Decision log or scribe notes	How the team performed	Timestamps in scenario time help
After-action report	Findings were analysed	See writing the after-action report
Improvement plan	Findings became actions	Each item needs an owner, due date and status
Plan revision record	The plan was updated	Change log or version history referencing the exercise
Retest evidence	Fixes were verified	Next exercise or targeted walkthrough covering the closed items

The most common weakness auditors find is not a missing exercise. It is an improvement plan that nobody updated. If your evidence shows the same findings in two consecutive reports, expect questions.

Running the exercise with a live tool can reduce the documentation burden. The site's live exercise runner timestamps each inject and response and exports an after-action report, which gives you the decision log and report draft without transcribing notes.

How often to run tabletop exercises

A practical frequency that satisfies most frameworks:

At least once every 12 months for the core incident response team, which meets PCI DSS 12.10.2 and the periodic testing language elsewhere.
At least once a year with executives where governance is in scope (NIS2, DORA, SEC disclosure, board oversight). This can be a shorter session.
After significant change: a new or rewritten incident response plan, a merger or acquisition, a major platform migration, a new critical supplier, a new regulatory obligation.
After a real incident, to test the fixes from its post-incident review.
Retests of specific weak areas, which can be short and focused.

Rotate scenarios through the year so different parts of the plan get tested. The how to run a tabletop exercise guide covers planning a single exercise end to end.

Designing one exercise for several frameworks

Most organisations answer to more than one framework. Instead of running separate exercises for each, write objectives that serve several at once and tag each objective with the requirements it evidences. For example, "the team classifies the incident and prepares the first regulatory notification within its deadline" can evidence NIS2 Article 23, GDPR Article 33 and your ISO 27001 incident response control in a single module. Keep the tagging in the exercise plan, and repeat it in the after-action report so each auditor can find their part quickly.