TL;DR: A security questionnaire is a buyer’s way of checking if you are safe to trust with their data. Most of it is not about your answers. It is about your evidence. Answer honestly. Attach proof. Say “not yet, by this date” instead of a soft yes. Teams that build with AI tools trip on one question in particular, and the truth is easier than the cover story.
What a security questionnaire actually is
Your first real customer sends a spreadsheet. It has 120 rows. Each row is a question about your security. Some ask about encryption. Some ask about staff laptops. Some ask about a policy you have never heard of.
This is a vendor security review. The buyer’s security team runs it before your contract can be signed. It is the last gate on the deal, and it is the one founders prepare for the least.
Here is the part nobody tells you. The security team is not grading your product. They are grading your answers against a risk they have to sign off on. A small vendor with honest gaps and a written plan is easier to approve than a vendor whose answers all say yes and prove nothing.
So the goal is not a perfect score. The goal is a clean, checkable file.
The four things every questionnaire asks
Strip out the wording and every form asks the same four things. Can you keep our data safe? Will your service stay up? Will it slow us down? Will you know when it breaks?
Those four questions match the four things we scan for. That is not a coincidence. Both come from the same place: what an outside party can verify.
| Section on the form | What it means | Common questions |
|---|---|---|
| Access and data | Who can reach the data, and how is it locked | Auth, roles, encryption, secrets, patching |
| Service resilience | What happens when something fails | Backups, restore tests, error handling |
| Performance and limits | Can you hold up under load | Rate limits, load testing, database indexes |
| Detection and response | How fast you notice a problem | Error tracking, alerts, logs, uptime checks |
Map your answers to those four buckets before you start typing. Half the rows collapse into one paragraph each. If a report in that shape would help, we wrote a guide on how to read a security audit report.
The question that trips up AI-built teams
Buyers now add a row that did not exist two years ago. It reads something like: “Was any part of this codebase generated by AI coding tools? Which ones?”
Founders freeze on this one. They worry a yes will sink the deal. So they write something vague, or they leave it blank.
That is the wrong call, and here is why. It is easy to tell from the outside which tool built a product. Our scanner probes a live URL for leftover config files. A response from /.cursorrules marks the build as Cursor at 0.93 confidence, and that rule sits at platformFingerprintScanner.js:208. The scanner also reads the script paths in your page source and matches them to a platform, at platformFingerprintScanner.js:287. No code access. No login. Just the public site.
A buyer’s security team can do the same checks in ten minutes. If your form says one thing and your headers say another, the deal does not just slow down. Trust is gone.
“Yes. Parts of the codebase were generated with [tool]. All generated code is reviewed before merge. We had an independent security audit on [date], and the report is attached.”
That last sentence is the one that moves the deal. It turns a red flag into a controlled risk.
Never answer yes to something you cannot screenshot
This is the only rule you need. If a row says “Do you enforce rate limiting on public endpoints?” then before you write yes, open a terminal and fire 100 requests. If you do not see a 429, the answer is not yes. Our rate limiting guide covers the fix.
Security teams do spot checks. They pick three or four of your yes answers and test them. A single yes that falls apart makes them re-open every other row. One caught bluff costs more time than twenty honest noes.
So sort every row into three piles. Yes with proof. No with a date. Not applicable with one line of why. Nothing else goes on the form.
“No, and we plan to ship this by 15 August” reads as a team that knows its own product. “Yes” with nothing behind it reads as a team that does not.
The three documents that replace half the form
Most of a questionnaire is the same set of facts asked in eighty ways. Write those facts once. Attach them. Then point rows at the file.
A security overview page. One or two pages. Your stack. Where data lives. How auth works. Who has production access. Your backup schedule. Keep it current and put it behind a link you can share. If backups are on that page, make sure you have tested a restore — our backup guide explains why that line matters.
A recent audit report. An outside report answers the rows a buyer trusts least, because you did not write it. Our Launch Readiness Audit is $499 as a one-time report and lands in under two minutes. It covers all four sections above, with a score out of 100 and a fix list.
An AI policy. If your product has any AI feature, buyers will ask about the models and the data that reaches them. One short document covers it. We wrote the seven sections it needs.
Three files. Half the spreadsheet answered before you open it.
The two new rows nobody had last year
Forms are growing. Two sections turned up in 2026 that were rare before.
The first is data protection. If the buyer has EU users, they will ask where personal data sits, who processes it, and how a user gets it deleted. Our GDPR guide for vibe-coded apps walks the checks. One of them, row-level security on your database, is also the single most common reason a startup fails the access section. The builder scaffolds a table. It does not scaffold the rule that stops user A reading user B’s rows. Our guide to Supabase row-level security policies shows how to close it.
The second is AI. From 2 August 2026, Article 50 of the EU AI Act says users must be told when they are talking to AI, and AI-made content must be labelled. Fines in that tier reach €15 million or 3% of global turnover. The €35 million ceiling is for banned practices, not for a chatbot without a banner. Buyers know the date. They will ask before it lands. Our compliance checklist lists the rows in order.
What to do when they ask for SOC 2
Somewhere in the form sits a row that reads: “Do you hold a SOC 2 Type II report?” For a seed-stage team the answer is almost always no. That row is not a wall.
A buyer asks for SOC 2 because it is a shortcut. It saves their team from reading your answers closely. Take the shortcut away and give them something better: a recent third-party audit, a named owner for security, and a date you plan to start the SOC 2 process.
Be careful with the wording here. Nobody can hand you a SOC 2 certificate. An accredited auditor issues the report, and the work of getting ready for one takes months. Any vendor who tells you otherwise is selling you something. We prepare teams for SOC 2. We do not certify it, and we say so in our SOC 2 guide for AI-built startups. The same is true of ISO 27001.
Most security teams will take the swap. What they cannot take is silence, or a yes that is not true.
What our scans predict you will fail
We scanned 100 AI-built SaaS products, websites and apps. The average Launch Readiness Score was 42 out of 100.
The failures cluster. That means we can guess which rows of your questionnaire will hurt before you send it.
Detection and response. Most builds have no error tracking at all. So the row that asks “how quickly do you detect a production incident?” has no true answer. There is nothing watching. Start with the error monitoring basics.
Performance and limits comes next. Public endpoints with no rate limit are the norm, not the exception. That is one row on the form and one afternoon of work.
Access and data is uneven. Auth usually exists, because the builder scaffolds it. Row-level rules on the database often do not, because the builder does not.
Service resilience is the quiet one. Backups exist. Restore tests do not. A buyer who asks “when did you last restore from backup?” is not asking about backups. They are asking if you have tried.
None of this is a character flaw. AI builders ship features. They do not ship security defaults, and they do not fill in forms. The gap only shows when a buyer looks.
A one-week plan
Day 1. Read the whole form first. Do not answer anything. Sort the rows into the four buckets. Count how many you can prove today.
Day 2. Run a scan against your live URL. The free scan costs nothing and gives you a score out of 100 with the gaps named. Now you know which noes are real.
Day 3. Fix the cheap ones. Security headers take an hour. Rate limits on your public routes take an afternoon. Both turn a no into a yes with proof.
Day 4. Write the security overview page. Two pages, plain words, true.
Day 5. Fill the form. Yes with proof. No with a date. Not applicable with a reason. Attach the audit report and the overview page.
Day 6. Read it back as the buyer. Would you sign this? Where would you push?
Day 7. Send it, with a short note listing the three things you fixed while filling it in. That note does more for you than any single answer on the sheet.
Never sent one before? Walk the pre-launch checklist first. It covers the same ground on your own terms.
Find your gaps before the buyer does
Run the free scan on your live URL. A Launch Readiness Score out of 100, in about thirty seconds. No code access needed.
Run the free scan — $0Getting ahead of the next one
The first questionnaire is painful. The tenth is a copy and paste, if you build the file once and keep it fresh.
Founders who monitor their build keep the file honest without thinking about it. Daily scans catch the day a fix quietly regresses, which is the day a yes on your form silently becomes a lie. That is what our subscription tiers are for, from $149 a month. If the buyer’s form is heavy on GDPR and the EU AI Act, our Compliance Score runs 60 automated checks and hands you a report to attach.
The deal does not turn on a perfect score. It turns on whether a stranger can check what you wrote and find it true.
FAQ
What is a security questionnaire?
It is a form a buyer's security team sends before they sign a contract with you. It asks how you protect their data, how you keep the service running, and how fast you spot a problem. It is the last gate on most enterprise deals.
Do I have to tell a buyer my app was built with AI tools?
Yes. Say so plainly. Leftover config files and script paths make an AI-built product easy to spot from the outside, with no code access. If your form says one thing and your site says another, you lose the deal on trust, not on tooling.
What if I have to answer no to a question?
Give the no a date. "No, and we ship this by 15 August" reads as a team that knows its own product. A yes with nothing behind it reads as a team that does not. Security reviewers spot-check a few answers, so one bluff re-opens every other row.
Can a startup pass a security questionnaire without SOC 2?
Usually, yes. SOC 2 is a shortcut for the reviewer, not a legal requirement. Replace the shortcut with a recent third-party audit report, a named security owner, and a date you plan to start the SOC 2 process. Launch Ready Code prepares teams for SOC 2. We do not certify it.
What evidence should I attach to a security questionnaire?
Three files answer most of the form: a one-page security overview, a recent independent audit report, and an AI policy if your product has any AI feature. Write them once, keep them current, and point rows at them.
How much does an audit report for a questionnaire cost?
Our free scan is $0 and returns a Launch Readiness Score out of 100 in about thirty seconds. The Launch Readiness Audit is $499 as a one-time report and lands in under two minutes, with a fix roadmap you can attach to the form.