The email usually arrives after the commercial terms are settled. Your champion forwards it with an apology: their security team needs you to complete a questionnaire before legal can finish. Attached is a spreadsheet with 200 rows, a column marked Yes / No / N-A, and a due date that is already uncomfortable.
Nothing about the deal has changed. But it has just stopped moving, and the person who has to unstick it is usually a founder, a CTO, or whoever last touched the IT systems.
Here is how to work through it.
Before you answer a single question
The instinct is to open the spreadsheet and start typing. Resist it for a day. The first pass should be reading, not answering.
Read every question first, including the tabs people forget to scroll to. You are looking for three things: how many questions actually apply to what you sell, how many require a document you would have to write from scratch, and whether anything in there is a hard blocker — a control you genuinely do not have and could not stand up in the time available.
That read takes an hour or two and it tells you whether this is a two-day exercise or a two-week one. Committing to a date before you know which is the most common way these reviews go badly.
Sort the questions into four piles
Almost every questionnaire breaks down the same way:
- Things that are true and you can prove today. MFA is on, backups run, laptops are encrypted. The work here is evidence, not remediation.
- Things that are true but undocumented. You do the thing; nothing written says you do it. This is the biggest pile for most growing companies, and it is the one that makes an otherwise healthy company look unprepared.
- Things that do not apply. Questions about data centers you do not run, or hardware you do not own. These get a short explanation, not a blank cell.
- Things that are genuinely missing. Usually a handful. These need a decision, not a keystroke.
Sorting first is what keeps a review proportionate. Most of the work is in the second pile, and it is writing, not engineering.
The parts that make vendors want to throw the laptop
Spend ten minutes reading what engineers and founders say publicly about these reviews and the same four complaints come up every time. They are worth naming, because each one has a practical response.
"They gave us two days." The questionnaire often arrives late, from a team that has been waiting on procurement, with a turnaround that assumes you have a compliance department. You usually have more room than the date suggests. Reply the same day with a realistic date and a short reason — "we want the answers to be accurate and evidenced, so we'll have this back to you Thursday" — and most reviewers accept it. Silence is what creates pressure, not a considered date.
"Half the questions don't apply to us." Questionnaires get reused for years. A company running entirely on managed laptops and cloud services will still be asked which antivirus product runs on its Windows workstations, or how it secures its data center cages. Answer the intent rather than the literal question: say what you actually run, and what handles that risk in your environment. A one-line explanation reads as competence. A blank cell reads as evasion.
"We have a SOC 2 and they still sent the questionnaire." They usually will. The report answers the auditor's questions, not the reviewer's specific ones, and many buyers are required to collect their own answers regardless. Attach the report, reference it where it genuinely covers a question, and answer the rest. Treating the report as a reason to skip the work is the fastest way to get the whole thing bounced back.
"Nobody is going to read this anyway." Sometimes true. But the answers do not disappear — they get filed, and they resurface at renewal, during an incident, or when someone finally reads them closely. Everything you submit is a written representation about your company. That is the reason to answer carefully even when the exercise feels performative.
Find out what is actually driving the review
A questionnaire is a proxy for a concern. Someone on the buyer's side is accountable for the risk of bringing you in, and the spreadsheet is how that accountability gets documented.
Ask your champion two questions: what is the customer most worried about, and who on their security team is reviewing the answers? A fifteen-minute call with that reviewer is often worth more than fifty rows of the spreadsheet. It tells you which questions they care about, which ones are boilerplate from a template they bought, and whether a compensating control would satisfy them.
Buyers' security teams are rarely trying to fail you. They are trying to write down a defensible decision.
Answer only what you can support
Every answer should be something you could hand to an auditor, a customer, or a court and defend with a document, a screenshot, a configuration, or a log.
That leaves you four honest responses:
- Yes — and here is the evidence.
- No — and here is what we do instead, and why it addresses the same risk.
- Not applicable — and here is why, in one sentence.
- Planned — and here is the date, the owner, and what exists today.
A thoughtful "no" almost never kills a deal. An unsupported "yes" can, and it tends to surface at the worst possible moment: during an incident, at renewal, or when a real auditor asks for the evidence behind the answer you gave.
Three answers that cause problems later
Checking "yes" because it is nearly true. The control exists on one system, or for some of the team, or it was configured last year and nobody has verified it since. Partial truths become written commitments the moment you submit them.
Buying software mid-deal. A tool bought under deadline pressure tends to be the wrong tool, bought at the wrong price, and it will not be implemented deeply enough to survive the next review anyway. Very few questionnaire answers actually require a purchase.
Committing to a certification by a date. "We'll have SOC 2 by Q2" is easy to say in a stalled deal and hard to walk back. Audit timelines depend on your readiness, your auditor's calendar, and an observation window you may not have started. It is also worth knowing that an audit is not an exit from this process — companies with a current report still get questionnaires.
What to send back
Send more than the spreadsheet. A short cover note changes how the review reads: what your product does and what data it touches, a summary of how you handle the areas they care about most, the evidence you are attaching, and a clearly labeled list of anything in progress with dates.
Then keep the answers. The next customer will ask most of the same questions, and the second review should take a fraction of the time the first one did. Companies that keep an evidence folder and a maintained set of answers stop treating security reviews as emergencies.
When to bring in help
Handle it yourself when the questions are mostly familiar, the evidence exists, and you have the days to spend.
Bring in help when the questionnaire is long and unfamiliar, when the customer has asked for a call with your security team and you do not have one, when you are being asked to sign a security addendum with specific technical commitments, or when the honest answer to several questions is "I am not sure what they are asking."
That is the work we do. Security Questionnaire Rescue starts at $1,500: we translate the questions, draft answers grounded in your actual controls and evidence, flag the gaps, and mark anything that needs leadership or legal sign-off. If you would rather talk it through first, book a 30-minute deal-readiness call.