Short answer
Answer only what is true, attach evidence where you have it, and say plainly what you have not done yet and when you will. Buyers send security questionnaires to find out whether you understand your own risks, not to catch you without an audit report. You do not need SOC 2 to answer one well, and you must not imply you have it. A short set of accurate, dated answers, backed by records of what you checked, gets through review faster than polished claims that invite follow up questions.
What is a security questionnaire, and why do buyers send one?
Before a company lets a new supplier near its data, its security or procurement team assesses the risk. The questionnaire is how they collect the facts. Some use a standard format; the Cloud Security Alliance’s CAIQ, for example, is a set of yes or no questions a customer may ask a cloud provider about the controls in its service. Many send their own spreadsheet, which is usually a standard set with the company’s favourite questions added.
The reviewer on the other side is not expecting a five person company to look like a bank. They are checking whether you know what you have done, what you have not, and whether what you say matches what you can show.
Do you need SOC 2 before you can answer?
No. A SOC 2 report is an independent auditor’s report on a service organisation’s controls relevant to security, availability, processing integrity, confidentiality or privacy, as the AICPA describes it. It covers the organisation and its processes over a period, takes months, and many early stage companies do not have one. Buyers know that.
When the questionnaire asks for it, say what is true: “We do not have a SOC 2 report. Here is what we can show today,” followed by your evidence and, if it is real, your plan. What you must not do is hint that an audit exists or is nearly done when it is not. That is the answer that ends deals when it is discovered, and in a regulated buyer it gets discovered.
Which questions come up for an app built with AI tools?
The wording varies but the topics repeat. Expect most of these:
- Authentication: password rules, multi factor authentication, session expiry, single sign on.
- Access control: how you stop one customer seeing another’s data, and who on your team can reach production.
- Encryption: in transit (HTTPS everywhere) and at rest.
- Secrets: where API keys live and how you rotate them.
- Dependencies and vulnerabilities: how you find and fix known flaws, and how fast.
- Logging and incidents: what you log, who is alerted, and how you would tell the customer about a breach.
- Data: where it is stored, which subprocessors touch it, retention and deletion.
- AI use: whether customer data is sent to model providers, and whether it is used for training.
- Testing: whether you have had a penetration test, and when.
How do you write a good answer?
Use three kinds of answer, and be consistent:
- Yes, with evidence. “Yes. All traffic is HTTPS with HSTS. Header check from 2 October attached.”
- Partly, with the scope stated. “Multi factor authentication is required for all staff accounts on production systems. It is available but optional for customer accounts.”
- Not yet, with a plan you will keep. “No penetration test has been performed. We run an automated check of the application each week and review findings within the deadlines in our policy. A test is planned before we pass 50 customers.”
Keep each answer to what was asked. Volunteering a paragraph of adjacent practice reads as evasion. Date anything that can change. And answer in your own words: an answer copied from another company’s published responses will not match your stack, and reviewers notice.
What counts as evidence?
Evidence is anything a reviewer could check, or that you produced at a stated time without knowing they would ask. Good examples for a small team:
- Dated results of the checks you ran on the application: access control tests with two accounts, database rules, a header check, a secrets search.
- Your published privacy policy and subprocessor list.
- A one page incident plan: who is called, in what order, and how customers are told.
- Your fix deadlines by severity, and a record showing you meet them.
- A reference to the published standard you checked against. Saying you reviewed your app against the requirements of the OWASP Application Security Verification Standard tells a reviewer what “checked” meant. Claiming you meet the standard is a different statement, and one only an assessment supports.
What should you never write?
- Absolutes: “fully secure”, “unhackable”, “military grade encryption”. They are unfalsifiable and they signal inexperience.
- Any claim that you are certified or compliant with a framework you have not been assessed against.
- A penetration test you have not had, or a policy that exists only as a plan.
- “Not applicable” for something that applies. If you store customer data, data deletion applies to you.
Who should fill it in, and how long should it take?
At an early stage, whoever built the system answers, and one person signs off the whole document so the answers agree with each other. Inconsistency is what reviewers catch most easily: “all data is encrypted at rest” in one row and “we are evaluating encryption options” three rows later tells them nobody read the whole thing.
Before you start, ask the buyer three questions: which parts are mandatory, whether they accept existing documents in place of answers, and who to contact with clarifying questions. Many teams will accept a short security overview plus answers to the rows that matter most to them, which turns a week of work into an afternoon.
Set aside time to check claims rather than type them. If an answer says multi factor authentication is enforced on production systems, open the settings and confirm it before you send. A questionnaire is a written statement to a customer, often referenced in the contract that follows, so treat each row as something you may be asked to show.
How do you make the next one easier?
Keep every answer you give in one place, with the date and the evidence it relied on. The next questionnaire will ask most of the same questions in different words, and answering from a library is far quicker than starting again. Review the library every quarter, because a dated answer that has gone stale is worse than none.
The investor version of this conversation is shorter but has the same rule; we wrote about it in the security question in the fundraise. The guide answer “is it secure?” with evidence shows how to build the record by hand today, and the free Vibe Coding Security Checklist gives you the list of application checks to run and date.
VibeLock keeps that record for you: every check with its scan date, and every finding with its fix. Rescans that confirm each fix, and a public trust page with a live verification link you can send instead of a screenshot, come with the Founder plan, which cannot be bought yet.
Sources
- STAR Level 1: Security Questionnaire (CAIQ v4), Cloud Security Alliance
- SOC 2: SOC for Service Organizations, AICPA and CIMA
- OWASP Application Security Verification Standard, OWASP Foundation