What does a carrier mean by a tested incident response plan?

Tested means the plan was put under pressure with the people who would actually have to run it, and that something was written down afterwards. That is the working definition, and it is not on the form. The word is never defined on a cyber insurance application, and three different readers use it to mean three different things. An underwriter means the plan is live and has been exercised. A SOC 2 auditor means there is an artifact trail. A government exercise programme means a structured discussion. You are usually being asked to satisfy one of them at a time, and knowing which one changes what you need to have on file.

What does an underwriter mean by tested?

Less than most people expect, and it is published. The clearest example is Cowbell’s Prime 250 application, which asks:

Does the organization have an incident response plan - tested and in-effect - setting forth specific action items and responsibilities for relevant parties in the event of a cyber incident or data breach matter?

That is question 4 on the renewal form and the identical wording is question 7 on the full application (Cowbell Cyber Risk Insurance Renewal Application, Prime 250, 2021).

Read what it does not say. It does not define testing. It names no method, no cadence and no minimum number of participants. It does not use the words “tabletop exercise”, “simulation” or “at least annually” anywhere in the question. What it does is assert three things at once: that a plan exists, that it is in effect, and that it has been tested.

Beazley’s Canadian application divides the same ground more visibly. Question 1.7 asks whether you have an incident response plan addressing network incidents and data breaches, then gives two separate tick boxes: Have a plan and Tested in last year (Beazley Cyber Application, Canada, 2026). Two boxes, because those are two different claims, and it is the form written for Canadian applicants that bothers to separate them.

Beazley’s large-account US form asks less again. Just Do you have an incident response plan for network intrusions and malware incidents? (Beazley Cyber Insurance Application, form F00657, 2023). A plan, full stop. Nothing about testing.

So the question arrives in at least three shapes, and which one is in front of you decides what has to be in the file.

So where a carrier does ask about testing, it is asking for a state of affairs rather than a methodology. It wants to know the plan is real and has been exercised. It leaves the definition of exercised to you, which is convenient right up until somebody asks you to prove it.

What does a SOC 2 auditor mean by tested?

An auditor means an artifact trail, and wants it in a particular shape.

SOC 2 is built on the AICPA’s Trust Services Criteria. The common criteria dealing with incidents run from CC7.3 to CC7.5: deciding whether a security event is actually an incident, responding to it through a defined incident response programme, and recovering (AICPA, 2017 Trust Services Criteria with Revised Points of Focus (2022), TSP Section 100, 2022). The middle one is where a tabletop exercise usually lands.

The criteria do not tell you to run a tabletop. They name no cadence and no facilitator. What the auditor asks for is evidence, and the evidence request is consistent in practice: the after-action report, the scenario document, who attended, the date, the findings, and something showing the findings were tracked to closure.

A lot of published advice gets two things wrong here.

Start with the version. The governing document is the 2017 criteria with revised points of focus published in 2022. There is no 2026 edition. If something you are reading cites one, stop reading it.

The bigger one: no SOC 2 or ISO 27001 requirement makes an outside facilitator mandatory. Auditors accept internally-run exercises where the documentation exists. Independence is what a carrier values, and it is what we sell, but it is not something the audit standard demands. Anyone telling you otherwise is selling you something and getting the reason wrong.

What does CISA mean by an exercise?

Different again, and this one is usually the picture already in your head.

CISA’s tabletop exercise packages describe the format as an interactive discussion-based exercise (CISA, Tabletop Exercise Package Overview, 2020). Discussion-based is the operative half. Nobody is at a keyboard and nobody is reading logs. A scenario goes up, and the room works the problem out loud.

That is a description of a method. It is not a standard of proof. CISA is telling you how to run a useful session. It is not telling a carrier what to accept afterwards, and it was never written to.

How do the three definitions compare?

	The underwriter	The SOC 2 auditor	CISA
What the word means	The plan is in effect and has been exercised	The incident response programme operates as described	A structured, discussion-based session
What satisfies it	A dated record that it happened, ideally confirmed by someone independent	Report, scenario, attendance, date, findings, and their closure	Running the package as written
Method specified?	No	No	Yes, discussion-based
Cadence specified?	No	No	No
Facilitator specified?	No. Independence is what makes the record hard to dispute	No. Internal is accepted	Your own planning team
What it is ultimately for	Pricing the risk, and reading back at a claim	An opinion on your controls	Improving the plan

The row that does the most work is the last one. The three readers are not grading the same thing. An auditor is checking that you do what you say. CISA is trying to make you better at responding. An underwriter is deciding what to charge you, and keeping the answer on file in case there is ever a claim.

Where does “at least annually” come from, then?

Not from the carrier’s incident response question. It comes from regulators and from government checklists, and then it gets read back onto the form by people who have seen both.

The clearest version is New York’s financial services rule, which requires covered entities to test their incident response and recovery plans periodically, but at a minimum annually, with all staff and management critical to the response (NYDFS, 23 NYCRR 500.16(d), 2023). Note the exact words. The phrase everyone repeats, “at least annually”, is a paraphrase, not the text. That rule binds financial services entities licensed in New York. It almost certainly does not bind you. It matters anyway, because it is the clearest published statement of the cadence the industry has settled on.

The second source is public underwriting checklists. Read the next one slowly. Indiana’s state cybersecurity hub publishes a list of the questions underwriters ask. Its response planning category runs to 4 questions (Indiana Cybersecurity Hub, Cyber Insurance Toolkit, underwriting security controls questions, 2026). Three of them ask whether a document exists: a written incident response plan, a written data breach response plan, a written disaster recovery and business continuity plan. The fourth asks about annual testing, and it attaches that question to the disaster recovery and business continuity plan.

Not to the incident response plan.

So on one of the most widely circulated public lists of underwriting questions, the annual testing obligation that everybody associates with incident response is hung on a different document, and the incident response line asks only whether the plan is written down. Know that before you answer either one. The two questions travel separately.

Does a walkthrough count?

It depends which reader is asking, which is the point of this page.

For an auditor, a documented walkthrough with a date, an attendee list and findings usually evidences the response criterion, provided the findings went somewhere afterwards.

For an underwriter reading “tested and in-effect”, a walkthrough is a weaker answer than an exercise and a stronger one than nothing. The distinction that matters is not the format. It is whether anything was put under pressure. A meeting where the plan is read aloud and everyone agrees it looks fine has tested the document. It has not tested the response.

The practical difference between reviewing and testing:

• A review asks whether the plan is current and correct. One person can do it at a desk.
• A test asks whether the people named in the plan would do what it says, under time pressure, with incomplete information. It needs those people in a room.

If nobody disagreed with anyone, it was a review.

Which definition are you actually being asked to satisfy?

One at a time, and the document in front of you tells you which.

If it is a cyber insurance application, you are answering the underwriter’s definition. What makes your answer hold up a year later is a dated record that somebody outside your own response is willing to confirm.

If it is an auditor’s evidence request, you are answering the artifact definition. What matters is that the file is complete and the findings were closed.

If it is neither, and you are running an exercise because a director asked, build to CISA’s definition. That one was written to make the session useful rather than provable.

The expensive mistake is answering the underwriter’s question with CISA’s definition in your head: running a genuinely good session, learning something real, and keeping nothing afterwards that a third party can confirm ever happened.