What do enterprise security questionnaires ask about incident response testing?

Enterprise vendor questionnaires ask about incident response testing more directly than insurance applications do. The cloud industry’s control framework has a dedicated control for it, SEF-04, Incident Response Testing, and the body that publishes it says in its own words that plans should be tested through tabletop exercises or simulations. No carrier application we have read goes that far. If you sell to large organisations, the questionnaire is more likely to force this conversation than your renewal is.

What does the questionnaire actually ask?

The widely used cloud framework is the Cloud Security Alliance’s Cloud Controls Matrix, which underpins the CAIQ questionnaire that enterprise buyers send to software suppliers. Its incident management domain runs to eight controls, and one of them exists only for this.

Control SEF-04, Incident Response Testing, requires you to Test and update as necessary IR plans at planned intervals or upon significant organizational or environmental changes for effectiveness. The Cloud Security Alliance’s own guidance adds that organisations should test those plans periodically, either through paper walk through/table top exercises or simulations (Cloud Security Alliance, Cloud Controls Matrix, SEF domain, 2025).

Read what that does and does not say.

It names the activity. Tabletop exercises appear by name, which they do not on any insurance application we have read.

It names a cadence, loosely. Planned intervals, plus a trigger on significant change. Not a fixed twelve months.

It does not name who runs it. Same as everywhere else.

One honest limitation on that quote: it is the control specification as the Cloud Security Alliance publishes it, not the questionnaire’s own question wording. The questionnaire restates each control as numbered questions, and the spreadsheet sits behind a free account we did not open. So treat the control as what your customer is assessing against, and expect the question in front of you to be a rephrasing of it.

How is that different from a carrier’s question?

	Vendor security questionnaire	Cyber insurance application
Names tabletop exercises	Yes, in the framework’s own guidance	No, on any form we have read
Names a cadence	Planned intervals, plus on significant change	Rarely. One Canadian form asks about the last twelve months
Names who must run it	No	No
What happens to a weak answer	Escalation, remediation plan, sometimes a contract condition	Priced in, and read again at claim
Who reads it	A security reviewer whose own framework obliges them to assess you	An underwriter
Evidence usually requested	The report, or a summary of it	Usually nothing, until it matters

The last two rows are the practical difference. An underwriter mostly takes your answer. A security reviewer at an enterprise customer frequently asks to see something, because their own framework requires them to manage supplier risk and your answer is their evidence.

That makes the questionnaire the more demanding of the two in day-to-day terms, even though the insurance answer carries more weight when something goes wrong.

Which other frameworks will you meet?

Three, depending on who your customers are.

Higher education. The HECVAT workbook is the standard instrument for selling to universities and colleges in North America, now consolidated into a single workbook. We could not read its current incident response wording, because it is distributed as a spreadsheet rather than a web page, so we are not going to characterise it. If a university is asking you, read their copy.

Financial services and large enterprise. The Shared Assessments SIG is licensed and proprietary. We can tell you it exists, that it is thorough, and that its incident management section is where this lands. We cannot quote it, and neither can anyone else without a licence.

Sector-specific supplements. Increasingly common, usually assembled by the customer’s own security team out of the frameworks above plus whatever their regulator expects of them.

The pattern across all of them is consistent. Does a plan exist, is it current, has it been tested, how often, and what happened afterwards.

What evidence actually satisfies a reviewer?

The same file that satisfies an auditor, which is convenient.

A dated after-action report naming the scenario and the roles in the room. The findings. Something showing the findings went somewhere. If you cannot share the whole report, a one-page summary carrying the date, the scenario type, participant roles and the fact that findings were tracked will usually pass.

What tends not to pass: a calendar invitation, a policy document describing how you would test if you tested, or a yes with nothing behind it. Security reviewers see a lot of questionnaires and they are good at spotting the difference between a control that operates and a control that is described.

What does the room actually get wrong?

The failure the exercises behind this template surface most often is not a missing control. It is that accountability stops at the edge of security operations.

Inside that team, ownership is clear and people know what they are doing. Outside it, nobody owns anything in particular, and the join between the executive and the technical side is where things fall through. Executives take sensible steps without telling their peers or their own teams, which is how two people end up giving the same vendor different instructions within twenty minutes of each other.

That matters here specifically because a questionnaire asks about your organisation, not your security team. A reviewer asking whether your incident response plan was tested is asking whether the company rehearsed, and an exercise attended only by IT answers a narrower question than the one being put to you.

Who is actually reading your answer?

Not a machine, and not usually a lawyer. A security analyst on the customer’s third-party risk team, working through a queue.

That shapes what lands. They are assessing dozens of suppliers against a framework their own auditors will check them on, so what they need from you is something they can attach to a file and move on. A clear yes with a document behind it does that. A long explanation of why the question does not quite apply to your situation does not, and it moves you from the fast queue to the slow one.

It also means a no is survivable in a way people do not expect. Reviewers see remediation plans constantly. A no with a date and an owner reads as a company that knows its own position. A yes that unravels under a follow-up question reads as something worse, and the follow-up question is usually just “can you send us the report?”

The other thing worth knowing: their framework obliges them to manage supplier risk, so your weak answer becomes their finding. That is why questionnaire answers get escalated rather than quietly filed. You are not being audited for its own sake. You are a line item in somebody else’s control.

The practical sequence

If a questionnaire is in front of you now, answer it against what you can evidence, and put a date against anything you cannot. Reviewers are used to remediation timelines and they are not used to being told everything is fine.

If you are preparing for the questionnaires you know are coming, run the exercise before the first one lands, get the report, and keep a shareable summary of it in the same folder as your policies. It converts a recurring scramble into a lookup, which is most of the value of doing it early.