Does a tabletop exercise count as incident response plan testing?
Yes. On every application and framework we have been able to read, a tabletop exercise satisfies the incident response testing question, because none of them specifies a method. They ask whether the plan has been tested. The format is your choice, and the thing that decides whether your yes holds up is the record you kept afterwards.
What do the forms actually say?
Cowbell’s application asks whether the organisation has an incident response plan - tested and in-effect (Cowbell Cyber Risk Insurance Renewal Application, Prime 250, 2021). Tested. No method, no cadence, no participant count.
Beazley’s Canadian form splits the question into two tick boxes, Have a plan and Tested in last year (Beazley Cyber Application, Canada, 2026). That one adds a twelve-month window and still says nothing about how.
New York’s financial services rule, where testing is actually mandated, requires covered entities to test their plans periodically, but at a minimum annually, with all staff and management critical to the response (NYDFS, 23 NYCRR 500.16(d), 2023). A cadence and an audience. Still no method.
The one place the format does get named is a vendor framework. The Cloud Security Alliance’s control SEF-04, Incident Response Testing, requires plans to be tested at planned intervals, and CSA’s own guidance says that should happen either through paper walk through/table top exercises or simulations (Cloud Security Alliance, Cloud Controls Matrix, SEF domain, 2025).
So the one framework that does name a method names yours.
Then what makes a yes weak?
Not the format. The evidence.
A tabletop exercise counts. A tabletop exercise nobody wrote up counts for exactly as much as a meeting nobody wrote up, which is to say it is true and unprovable. The gap between a strong yes and a dangerous one is a dated document naming the scenario, the people in the room by role, what they decided and what it found.
That matters because of what sits above the signature. Application answers are representations, and the forms say in their own words that misrepresenting a material fact can be grounds for rescinding the policy. Nobody is going to argue that a tabletop was not really testing. They are going to ask what you have.
What about a walkthrough?
Also counts, and it is a weaker answer for a reason that has nothing to do with the label.
A session where the plan is read aloud and everyone agrees it looks fine tests the document. A session where a scenario develops and people have to decide under time pressure tests the response. The first usually produces no findings, and a report with no findings reads as a demonstration rather than a test to anybody who has seen a few.
The practical test is simple. If nobody disagreed with anyone, you reviewed the plan. If somebody discovered they did not know who makes a call they assumed was theirs, you tested it.
What to keep
Four things, in one place, with the application file.
The plan, with a version and approval date. The exercise record: scenario, date, participants by role, decisions, findings. The findings with an owner and a target date against each one. And, if the answer will be read by an underwriter or a claims reviewer rather than only by you, a confirmation from somebody independent of your response that the exercise took place.
The first three you can produce yourself. The fourth is the only part of the answer that has to come from outside your organisation, and it is the reason the question is on the form at all.
Does a walkthrough count, or does it have to be a full exercise?
Both count as testing on the face of the form, because no form distinguishes them. The difference is what the record shows. A walkthrough where the plan was read aloud and everyone agreed produces a record that says a meeting happened. An exercise where decisions were forced produces findings, and findings are what make the record look like a test.
Does a penetration test count?
No. That answers a different question on the same form. A penetration test evidences that your systems were tested. The incident response line asks whether your plan was tested, which is about what people do after something gets through.