An incident response plan that has never been exercised is a hypothesis. It assumes people know their roles, the contact list is current, the notification register is usable, and someone can make a decision with half the facts. A tabletop exercise tests those assumptions in a meeting room instead of during a real incident.
It is also evidence auditors commonly accept when they ask whether your plan has been tested. The session itself takes an hour or two. The value, and the evidence, come from the preparation beforehand and the report afterwards.
This article covers why a tabletop counts as a test, how to set objectives, choose a scenario, write injects, run the session, and write the after-action report that an auditor will ask for.
Why a tabletop counts as a test
Several frameworks require the incident response capability to be tested, and none requires a live simulation.
PCI DSS v4.0 Requirement 12.10.2 requires the incident response plan to be reviewed, updated as needed, and tested at least once every 12 months.
NIST SP 800-53 Rev. 5 IR-3 covers incident response testing. NIST SP 800-84 is a guide to designing test, training, and exercise programs, including tabletop exercises.
ISO 27001:2022 Annex A 5.24 covers planning and preparing for incident management, which in practice includes confirming the plan works.
SOC 2 does not prescribe a test method, but a documented exercise is common evidence that the response program described under CC7.4 is more than paper.
A tabletop is a discussion-based exercise. Participants talk through what they would do as a scenario unfolds, using the real plan. It tests decisions, communication, and coordination. It does not test whether a backup restores or a failover works; those need technical tests of their own.
If you are still writing the plan, start with writing an incident response plan. A tabletop of a plan that does not exist yet tests nothing.
Set objectives before the scenario
A frequent mistake is to pick an exciting scenario and see what happens. Decide first what you want to learn. Two to four objectives is plenty, for example:
Can the on-call engineer identify the incident lead and reach them out of hours?
Does the team assign severity consistently using the plan's definitions?
Can legal and privacy determine notification duties from the register, within the time the register says they have?
Does anyone know who can authorize taking a customer-facing service offline?
Objectives shape the scenario and give the after-action report something to measure against. "We ran a tabletop" is weak evidence. "We tested these three objectives and met two" is strong.
Choose a scenario that fits your business
The scenario should be plausible for your company, touch the systems that matter most, and force at least one decision with no obvious answer. Your risk register is a good source: the top risks are the scenarios worth rehearsing. Building a risk register auditors accept covers how those risks are identified and scored.
Hypothetical scenarios that tend to work well for SaaS companies:
An engineer's credentials are phished and used to access a production database.
A storage bucket holding customer exports is found to have been publicly readable for several weeks.
A critical vendor reports a breach that may include your customers' data.
Ransomware encrypts shared drives and some laptops on a Friday evening.
Avoid scenarios that end in the first ten minutes. A lost laptop with confirmed encryption is a fine playbook test, but a thin tabletop.
Write the injects
Injects are the pieces of new information the facilitator releases during the session. They move the scenario forward and force decisions. Each one should change what the team knows and demand a response.
Here is an inject sequence for the second scenario above, purely illustrative:
Start. A security researcher emails your security address saying a storage bucket appears to be public. They include one file name.
Ten minutes in. The bucket is confirmed public. It holds customer data exports. Access logs for the bucket were not enabled.
Twenty minutes in. One of the affected customers is in the EU. Their data processing agreement requires notice within a shorter window than GDPR's.
Thirty-five minutes in. The researcher asks when you will publish a statement, and says they plan to write about it.
Fifty minutes in. An engineer finds the setting was changed by a deployment script eight weeks ago.
Notice what the sequence tests: severity assignment, notification under uncertainty (no access logs means you cannot rule exposure out), contractual obligations, external communication, and root cause. The 72-hour question alone is worth the session; GDPR breach notification and the 72-hour clock covers when the clock starts.
Write the expected decision for each inject in the facilitator's notes, so the gap between expected and actual is easy to see.
Who takes part, and who runs it
Invite the people who hold roles in the plan: incident lead, technical lead, communications, legal or privacy, and the executive who makes business decisions. Include deputies sometimes. A plan that only works when the primary incident lead is present has a single point of failure.
The facilitator should not also be a participant. Their job is to release injects, keep time, ask "who would you call?" and "where is that written?", and resist solving problems for the room. A scribe records decisions, questions, and gaps with timestamps.
Running the session
Set ground rules at the start:
Use the real plan and the real contact list. Open them during the session.
Say what you would actually do, not what the plan says you should do. The difference is the finding.
No blame. The exercise tests the plan, not the people.
Park technical deep dives. Note them as follow-ups rather than solving them in the room.
Keep to time. A focused session of 60 to 90 minutes, with a short debrief at the end while memories are fresh, produces better notes than an afternoon.
The after-action report is the evidence
An auditor asking for evidence of plan testing wants the report, not the invitation. Write it within a few days and include:
- Not done:
Date, duration, facilitator, and participants with their roles
- Not done:
Objectives and the scenario summary
- Not done:
What worked, against each objective
- Not done:
Gaps found, each with a specific description
- Not done:
Actions, each with an owner and a due date
- Not done:
Changes made to the plan, playbooks, or contact list as a result
Then close the actions. A report listing gaps that are still open at next year's exercise shows a test that found problems and a process that did not fix them. Link each action to a ticket and record its closure.
How often, and how to vary it
Annual is the floor for PCI DSS and a common choice in policies for other frameworks. More often is useful when the team or the environment changes quickly. Vary the scenario each time, rotate the facilitator if you can, and occasionally include a business continuity scenario, such as the loss of a cloud region, so recovery decisions are rehearsed too. If you are assessed against PCI DSS, check the exercise also covers the plan elements listed in Requirement 12.10.1, since 12.10.2 asks for all of them to be tested.
How TrustLynce helps
TrustLynce continuous monitoring routes control failures to their owners, so a lapsed control has a name attached. The auditor portal keeps auditor requests and findings in one place, which is where the after-action report goes when the auditor asks for evidence of plan testing.