Your Deal Just Stalled on a Security Questionnaire: Here’s What to Do in the Next Two Weeks

A founder messaged me last month with a familiar kind of panic. His company had a six-figure enterprise deal that was, in his words, “basically closed.” Verbal agreement from the VP. Legal reviewing the contract. Then procurement sent over a security questionnaire, and the deal went quiet.

Not dead. Quiet. Which is almost worse, because nobody tells you why.

If you’ve been through this, you know the feeling. You built something people want to buy. You did the demos, handled the pricing negotiation, and got the internal champion on your side. Then a spreadsheet full of questions about encryption-at-rest and incident response retention periods shows up, and suddenly the deal that felt won is sitting in a queue you don’t control.

Here’s what I’ve learned watching this play out dozens of times: the questionnaire itself is rarely the real obstacle. How you respond to it is.

Prefer to read the full breakdown? Keep scrolling. Prefer to watch? Full video above.

The two ways companies get this wrong

There are two failure modes I see constantly, and they’re opposites of each other.

The first is overpromising. Someone on your team, often not security-minded, often just trying to keep the deal moving, sees a question like “Do you have a formal incident response plan?” and answers yes, because saying no feels like losing the deal. Except now that “yes” is in a document a lawyer might reference later, and if you get audited or something actually goes wrong, you’ve created a liability that didn’t need to exist. Optimism is not a control.

The second is going dark. The questionnaire lands, nobody on the team feels equipped to answer it, so it sits in someone’s inbox for two weeks while everyone hopes it resolves itself. It doesn’t. Silence reads as either incompetence or evasion to a security reviewer, and either read is worse than an honest gap.

Both of these come from the same place: treating the questionnaire as a test you either pass or fail, instead of what it actually is, a conversation about risk that you’re allowed to participate in.

What the questionnaire is actually checking for

Something worth knowing before you respond to anything: the person reading your answers usually isn’t trying to find a reason to kill the deal. They’re trying to build a defensible file. Somewhere in their organization, someone will eventually ask “why did we approve this vendor,” and the questionnaire response is the paper trail that answers that question.

That changes what “passing” actually means. You’re not being graded against a checklist of every control a Fortune 500 company has. You’re being evaluated on whether you understand your own risk posture and have a credible plan for the gaps. A well-reasoned “not yet, here’s our timeline” from a company that clearly knows what it’s doing will often land better than a vague “yes” that doesn’t hold up to a follow-up question.

I’ve watched reviewers wave through startups with real, acknowledged gaps, and slow-walk companies whose answers felt rehearsed or evasive. Confidence about what you don’t have yet is more valuable than confidence about what you claim to have.

The triage, in the first 48 hours

When one of these lands, the instinct is to answer question one, then two, then three, in order. Don’t. Read the whole thing first and sort it into three piles.

Pile one: things you actually have. Answer these cleanly and move on. Don’t over-explain something that’s genuinely fine.

Pile two: things you don’t have, but the absence isn’t a dealbreaker. Most questionnaires have a long tail of items that matter in aggregate but won’t sink a deal on their own: a specific certification, a formal policy for something low-risk, a nice-to-have monitoring tool. For these, an honest “we don’t have this in place yet; here’s our plan and rough timeline” is almost always sufficient. Don’t pad these with jargon trying to sound more mature than you are. Reviewers see through that quickly.

Pile three: the two or three questions that actually matter. Usually these cluster around data handling, access control, and incident response, the things that would actually hurt the buyer if you got them wrong. These are where you spend your real time. If you have a gap here, it’s worth a short internal conversation before you respond: is this something you can close in the next two weeks, or does it need a longer-term plan you can describe credibly?

That third pile is usually three to five questions out of fifty. Everything else is faster to handle than it feels in the moment of first opening the document.

Write the plan before you write the answer

For any real gap (pile three, sometimes pile two) resist the urge to write a one-line answer and move on. A short, specific plan does more work than a vague reassurance.

Compare:

“We are working on formalizing our incident response process.”

versus

“We currently handle incidents through [existing informal process]. We are formalizing this into a documented IR plan, targeted for completion by [date], which will include defined roles, an escalation path, and a communication plan for affected customers.”

The second version doesn’t claim anything you don’t have. It just proves you’ve actually thought about it, which is usually what the reviewer is trying to determine in the first place.

Don’t let this become a solo project

The other mistake I see is one person, usually the founder or the most technical person on the team, trying to answer the entire questionnaire alone, at midnight, because it feels faster than pulling other people in. It’s rarely faster. Questions about HR practices, physical security, or vendor management often need input from someone who isn’t the person answering the engineering questions, and guessing at those answers creates the exact inconsistency a careful reviewer will flag.

Fifteen minutes spent assigning sections to the right two or three people usually saves hours of rework later.

The deal that stalled isn’t dead

Coming back to the founder I mentioned at the start: the deal wasn’t lost. It had stalled because his team’s first-draft answers were vague in exactly the places that mattered, which triggered a second round of follow-up questions and another two weeks of delay. Once we went back through it, triaged the real gaps from the noise, wrote specific plans instead of vague reassurances, and got the right people answering the right sections, the deal closed within three weeks.

Nothing about the underlying security posture changed in that process. What changed was how clearly it was communicated.

If you’re staring at a questionnaire right now and it feels like it’s blocking a deal you’ve already won, it probably isn’t. It’s asking you to show your work. Do that clearly, honestly, and with a real plan for the gaps, and most of these move a lot faster than they feel like they will on day one.

---

I put together a fuller playbook for working through security questionnaires end to end: how to triage the full document, language for common gap answers, and what to do when a reviewer pushes back. If that would help, you can access the Security Questionnaire Response Playbook here.