In brief
The problem. Your first big deal stalls on a security questionnaire with hundreds of questions, and nobody at your company owns security.
What most vendors do. They answer "yes" to nearly everything. In a survey of 154 third-party risk professionals, 81% said at least three-quarters of their vendors claim perfect compliance. Only about a third said they believe the answers.
What works instead. Answer like someone who expects to be checked. For every control, give the claim, the proof and the limit. Declare your gaps with a compensating control and a date. And shrink the questionnaire before you answer a single question.
Somewhere inside your customer's company, a person you will never meet is reading your security questionnaire. They read questionnaires like yours all the time, and most of them say the same thing: yes, yes, yes, fully compliant, yes.
That person mostly doesn't believe them.
When RiskRecon and the Cyentia Institute surveyed 154 third-party risk management professionals, 84% said their programs rely on questionnaires to assess vendors. Yet 81% said at least three-quarters of their vendors come back claiming perfect compliance, only about 34% said they believe the responses, and just 14% were highly confident their vendors actually do what they say. The survey is from 2020, but the way questionnaires are sent and answered has barely changed since.
This changes what a good answer is. If you're a 20-to-200-person company facing your first enterprise questionnaire, your goal is not to look perfect. Perfect is what everyone else sends, and it's exactly what the reviewer has learned to discount. Your goal is to be believable. That's a much easier standard for a small company to meet, if you know how.
What the reviewer is actually doing
A questionnaire looks like an exam you pass by answering every question correctly. It isn't. For the reviewer, it's a triage tool: they're deciding how much risk you add, whether anything needs a follow-up call, and whether they can sign off and move on.
Because they don't trust the answers, most reviewers check them. In the same research, 69% of organisations back up questionnaires with documentation review: policies, reports, screenshots, certificates. And their scepticism didn't fall as questionnaires got longer. Adding more questions doesn't buy the reviewer more confidence. Proof does.
So when your answers land on their desk, the reviewer is really reading for four things:
- Specificity. "We take security seriously" tells them nothing. "MFA is enforced for all 34 staff accounts at the identity provider" tells them a lot.
- Evidence. Can they see it, or are they taking your word for it?
- Consistency. Does your answer on access control in section 4 match your answer on offboarding in section 11?
- Honest limits. Did you declare anything at all? A vendor with zero gaps is either very mature or not being straight with them, and at 50 people, they'll assume the second.
Shrink the questionnaire before you answer it
The single most valuable hour you'll spend is the one before you write any answers.
Find out what you've actually been sent. Many questionnaires are standard formats in disguise. The Cloud Security Alliance's CAIQ v4 has 261 questions, down from 310 in the previous version, and a CAIQ-Lite version with 124. Shared Assessments' SIG Lite is commonly around 126 questions and SIG Core several hundred, depending on the year and how the buyer scopes it. A standard format means standard answers you can reuse with your next customer.
Ask what would replace it. Before answering line by line, ask the customer: "Would a security overview document, a recent penetration test or our SOC 2 report cover some of these sections?" Often the answer is yes. After FundApps completed its SOC 2 audit, questionnaires that "regularly took weeks" were frequently completed in half a day, and the CTO estimated it shortened the sales cycle by as much as a month. You may not have SOC 2 yet, but a clear two-page security overview does a smaller version of the same job. One founder in a Hacker News discussion of exactly this problem said that sharing documented security and data policies "works 99% of the time for me."
Ask two more questions: what's the real deadline, and who reviews the answers? A security analyst and a procurement coordinator read very differently, and a "due Friday" often turns out to mean "before the contract is signed next month."
Claim, proof, limit: how to write an answer that gets believed
Every answer you write should do three things:
- Claim: what you do, stated specifically enough to be checked.
- Proof: where the evidence is, or that it's attached.
- Limit: where the control stops, if it stops anywhere.
The limit is the part almost everyone leaves out, and it's the part that makes the rest believable. Here's what the difference looks like on common questions (illustrative examples):
| Question | The answer reviewers discount | Claim, proof, limit |
|---|---|---|
| Is MFA enforced for all users? | Yes. | Yes. MFA is enforced at the identity provider for all staff accounts; admin console screenshot attached. Two legacy service accounts use long random keys instead, rotated quarterly. |
| Is customer data encrypted at rest? | Yes, we use industry-standard encryption. | Yes. Our database and file storage use the cloud provider's AES-256 encryption at rest (configuration screenshot attached). Laptop disk encryption is enforced through device management for all company laptops. |
| Do you perform periodic access reviews? | Yes, regularly. | Yes, quarterly. The founder and head of engineering review access for every system in our tool inventory; the last review was 3 October (log attached). Leavers lose access the same day via a checklist owned by operations. |
| Do you assess your own vendors? | Yes, we have a vendor management process. | Partly. We keep a register of the 23 vendors that touch customer data, with each one's data, region and security documentation. We don't yet send questionnaires to them; we review their SOC 2 reports instead. |
Notice the last row. Questionnaires increasingly ask how you manage your suppliers, because your customer is doing vendor risk on you, and you are part of their supply chain. A short, real vendor list answers that better than any policy document.
How to say "no" without losing the deal
You will have gaps. No penetration test yet. No formal disaster-recovery exercise. One engineer who can both write and deploy code. The temptation is to blur these into a vague yes. Don't. A vague yes that falls apart on a follow-up call, or in a breach, does far more damage than a clear no.
A good "no" has three parts:
- Say it plainly. "No, we have not yet commissioned an external penetration test."
- Say why the risk is smaller than it sounds, if it is: your architecture, your size, what data you actually hold.
- Say what you do instead, and by when you'll close it. "We run automated dependency and vulnerability scanning on every deploy. Our first external test is booked for March 2027."
Buyers accept more of these than founders expect. In that Hacker News thread, a former third-party risk auditor explained that when a business genuinely wants the product, buyers often sign a risk acceptance rather than demand full compliance. A founder of a six-person company said that "the CEO / sales was able to work around the SOC2 requirement every time." Another founder simply wrote the gap down and owned it, accepting a separation-of-duties risk in writing: "due to our size we accept them at this time." And Thomas Ptacek, a well-known security engineer, pointed out that when the deal is real, a customer will often sign a purchase order conditional on a SOC 2 Type I report, which "can issue in a matter of weeks."
One warning from the same thread, and it's the one to remember. Another founder said exceptions were usually granted, "although the % started shrinking over time." Treat every gap you declare as a debt with a due date. The first customer forgives it; the fifth may not.
What you must never do: claim a certification you don't hold, describe a policy that exists only in someone's head, or shade the truth about past security incidents. Those are the answers that end relationships, not just deals.
Your first week
| Day | Do this |
|---|---|
| 1 | Read the whole questionnaire without answering. Identify the format. Ask for the real deadline, the reviewer's role, and whether a security overview or existing reports can replace sections. |
| 2 | Tag every question: have it, have it but need proof, don't have it. Collect the proof into one folder: screenshots, policies, your vendor list. |
| 3–4 | Write answers using claim, proof, limit. Write every "no" with a compensating control and a date. |
| 5 | One person reads every answer against the evidence folder, checking for consistency across sections. Send it with a short cover note that lists your declared gaps up front. |
The second questionnaire is where you win
The first questionnaire costs you a week. The real cost is answering the next twenty from scratch, because every enterprise customer will send one, and most will ask the same things in different words.
So before you close the spreadsheet, save every answer in one place: one answer per topic, the evidence linked beside it, one owner, and a date for when it was last checked. Add a short security overview you can send before anyone asks. Keep your vendor list current, because it goes stale fastest.
Reviewers have read a thousand perfect questionnaires. Give them a believable one.
Sources
- RiskRecon and Cyentia Institute survey of 154 third-party risk professionals (2020): Help Net Security summary; RiskRecon, "The Problem with Security Questionnaires"
- Cloud Security Alliance, CAIQ v4 released: changes from v3.1
- Drata, SIG questionnaire overview
- AWS Startups Blog, The impact of compliance on the SaaS sales cycle (FundApps)
- Hacker News, Ask HN: How to be SOC 2 Type 2 compliant as a solo entrepreneur?