“Do you have an incident response plan?” How to answer it in a security questionnaire

Almost every security questionnaire has a block of rows about incidents. They usually look like this: “Do you have a documented incident response plan?”, “When was it last tested?”, “How quickly will you notify us of a breach affecting our data?”, “Who is your security contact?” and “Have you had a security incident in the last 24 months?”

For a small SaaS company these rows are tricky because the honest answer is often “sort of”. You know what you would do, but it isn’t written down, nobody has practised it, and the notification time in your contract was copied from a template. This guide covers what reviewers look for, example answers for each common row, and how to write a short plan you can stand behind if you don’t have one yet.

What the buyer is really asking

The buyer is not expecting a small vendor to never have an incident. They want to know three things: that you will notice, that someone is in charge when it happens, and that you will tell them quickly enough for them to meet their own obligations.

That last point matters more than most vendors realise. If you hold personal data for a buyer covered by the GDPR, the buyer is usually the controller and you are the processor. [Article 33 of the GDPR](https://gdpr-info.eu/art-33-gdpr/) requires the controller to notify its regulator “without undue delay and, where feasible, not later than 72 hours” after becoming aware of a personal data breach, and requires the processor to notify the controller “without undue delay”. The buyer’s clock depends on yours, which is why they ask for a number.

The frameworks behind the questionnaires ask the same thing in different words. The Cloud Security Alliance’s Cloud Controls Matrix, which the CAIQ is built on, has a whole domain for it (Security Incident Management, E-Discovery and Cloud Forensics, or SEF; CSA walks through it in [its own guide](https://cloudsecurityalliance.org/blog/2025/10/14/implementing-ccm-incident-response-controls)). In SOC 2, incident handling falls under the System Operations criteria (CC7) of the [AICPA Trust Services Criteria](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022). If you have seen these rows in our CAIQ guide or a SIG, they are the same questions.

Example answers for the common rows

Adapt these only where they are true for you. Brackets are for your own facts.

• Q: Do you have a documented incident response plan? A: “Yes. Our incident response plan names an incident lead and a backup, defines severity levels, and sets out the steps for containment, investigation, customer notification and review. It was last updated in [month, year].”
• Q: When was the plan last tested? A: “We ran a tabletop exercise in [month, year] using a [ransomware / leaked credential] scenario, and updated the plan based on what we found.”
• Q: How quickly will you notify customers of a breach affecting their data? A: “We notify affected customers without undue delay and within [the number in our DPA] hours of confirming a breach that affects their data, or sooner where the law or our contract requires it.”
• Q: Who is your security contact? A: “[security@yourcompany.com], monitored by [role] every business day. For an active incident we can also be reached at [phone or escalation route].”
• Q: Have you had a security incident in the last 24 months? A: “No incidents affecting customer data.” Or, if you have had one: “Yes, one in [month, year]: [one sentence on what happened]. Affected customers were notified, and we [fix you made]. We can share more detail under NDA.”
• Q: Do you keep logs that would support an investigation? A: “Yes. We keep [application, access and infrastructure] logs for [period], and access to them is restricted to [roles].”

Two details reviewers check. First, the notification time in your questionnaire must match the one in your DPA or contract. If the DPA says 72 hours and the questionnaire says 24, the buyer will hold you to the shorter one, or come back and ask which is right. Second, “confirming” a breach and “becoming aware” of one are not the same moment. Use the wording your DPA uses.

If you don’t have a written plan yet

Don’t answer “Yes” because you have a rough idea of what you would do. A reviewer may ask for the document, and then you are writing it under deadline pressure with a deal waiting. An honest answer works better:

“Our incident process is currently informal: [name or role] leads any incident, and we notify affected customers by email. We are writing it up as a formal plan and can share it when it’s complete.”

Better still, write the plan before you send the questionnaire. For a small team, a useful first version fits on one or two pages. A one-page plan you have actually read beats a 30-page template nobody has opened.

What a one-page plan needs

NIST’s current incident response guidance, [SP 800-61 Revision 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final) (April 2025), treats incident response as part of everyday risk management rather than a separate binder. You don’t need to adopt it in full. A small company’s plan should cover:

1. Who is in charge: an incident lead, a backup, and how to reach both outside working hours.
2. What counts as an incident, with two or three severity levels and an example for each (a leaked API key, a lost laptop, unauthorised access to customer data).
3. First steps: contain (revoke keys, disable accounts, take a system offline), keep evidence (don’t wipe logs or machines), and start a written timeline.
4. Who to tell and when: customers (matching your DPA), your hosting and other key providers, your insurer if you have cyber cover, a lawyer, and regulators where the law requires it.
5. How you communicate: who writes customer notices, which channel you use, and a short template so nobody starts from a blank page.
6. Recovery and review: how you confirm the fix, and a short write-up afterwards with what you’ll change.
7. Where the plan lives and when you review it (at least yearly, and after every real incident).

Keep it consistent with what your other answers say. If your plan says the CTO leads incidents, your answers about who owns security should name the same person.

Testing it with a tabletop exercise

“When was it last tested?” is the follow-up that catches most small vendors out. A tabletop exercise is the simplest honest way to say yes: the people named in the plan sit down for an hour, someone reads out a scenario step by step, and the group talks through what they would do. No systems are touched.

You don’t need to invent a scenario. CISA publishes [more than 100 Tabletop Exercise Packages](https://www.cisa.gov/resources-tools/services/cisa-tabletop-exercise-packages) with template scenarios, discussion questions and an after-action report template. Pick one close to your risks, such as ransomware or a compromised account, shorten it, and run it.

Write down the date, the scenario, who took part and what you changed afterwards. That note is your evidence, and the date goes into your answer.

What not to say

• “We have never had an incident, so we don’t need a plan.” Reviewers read that as “we have never looked”.
• “Our cloud provider handles incident response.” Your provider responds to incidents in its own platform. A leaked password, a bad deployment or a misconfigured storage bucket in your account is yours to handle.
• A notification time you can’t meet. “Within 1 hour” sounds strong until you remember you’re a five-person team and it’s 3 a.m. Choose a time you can keep, and make sure it matches your DPA.
• “Yes” to a tested plan when the only test was a real incident nobody wrote up. That can count as a test, but only if you documented what happened and what you changed.
• More detail than needed. A clear, accurate summary is enough; tools and alert thresholds can wait for a call.

Our guide to answers that invite follow-up has more on why vague or inflated answers bring more questions, not fewer.

A checklist before you send it

• The plan exists as a document, with a version date.
• It names an incident lead and a backup, and your answer names the same people or roles.
• The notification time matches your DPA, word for word where possible.
• You can give a date for the last test or review, or you say honestly that it hasn’t happened yet.
• The security contact email works and someone reads it.
• Your answer about past incidents is accurate, and someone senior has agreed to it.
• Today’s wording is saved in your answer library, so the next questionnaire is a copy, not a rewrite.

Answering it with Rendro

Rendro drafts questionnaire answers only from your own documents, such as your incident response plan and DPA, and shows the source for each answer. If your documents don’t support a row, for example nothing records a tabletop test, it marks the answer Needs review instead of guessing. There is a 14-day free trial on rendro.net with no card required.