The security questionnaire arrives: what a five-person software vendor can honestly answer
Your first large customer sends a spreadsheet with two hundred rows: SOC 2, penetration tests, sub-processors, and now a section on AI. Which answers a tiny team can give truthfully, how to write a no that keeps the deal alive, what to fix in the first week, and what SOC 2 really costs.
The demo went well. The buyer's team likes the product, the price is agreed in principle, and someone says procurement will be in touch. Two days later an email arrives from a person you have never met, with a spreadsheet attached. It has two hundred rows. Row 14 asks for your SOC 2 Type II report. Row 61 asks when your last penetration test was. Row 118 asks whether your security operations centre is staffed around the clock.
There are five of you. Nobody has a job title with "security" in it.
This article is about that spreadsheet: what it is, who reads it, which rows a very small vendor can answer yes to without stretching anything, how to write the others, and what to fix before the next one comes. The short version is that an honest, specific no does less damage than most founders fear, and a yes you cannot back up does far more.
What you have been sent
A vendor security questionnaire is how a larger company checks a supplier before letting it near its data. It usually comes in one of three forms.
The SIG. The Standardized Information Gathering questionnaire, sold by a membership body called Shared Assessments and updated every year. Buyers pick a subset to send; the short version, SIG Lite, runs to well over a hundred questions and the full one to several hundred. The 2026 edition added no new risk areas, but it did add a mapping to ISO 42001, the standard for managing AI, so that a buyer can ask about a vendor's use of AI across its whole life cycle rather than in one line (Mitratech).
The CAIQ. The Cloud Security Alliance's questionnaire for cloud services. Version 4 has 261 questions, cut from 310 in the version before (CSA). It is free to download, which matters later in this article.
The house spreadsheet. Written by the buyer's own security team over the years, often by copying rows from the two above. This is the commonest kind and the least tidy. Expect questions written for a company with its own data centre, and the same question asked three times in different words.
Whichever one arrives, the person reading your answers is usually a risk analyst with a queue of vendors and a scoring sheet. They are not trying to catch you out. They need to put you in a tier, low, medium or high, mostly according to what data of theirs you will hold, and they need enough on file to defend that choice if something goes wrong later. Your job is to make that easy for them.
Before you type anything: three rules
1. Every yes is a promise with your name on it
A completed questionnaire is often attached to the contract or referred to in it. If you tick "yes, all staff complete annual security training" and there is a breach, that row will be read again, this time by a lawyer. Answer only what you could show evidence for on a screen-share tomorrow: a setting, a log, a document with a date on it.
2. There are more than two answers
Most sheets have a yes/no column and a comments column, and the comments column is where a small vendor wins or loses. Five answers are available to you, not two:
3. Ask which tier you are in
Before filling in two hundred rows, reply to the analyst with three sentences: what data of theirs your product will hold, where it is stored, and who can reach it. Then ask whether a shorter version applies. A tool that holds work email addresses and nothing else should not be answering the same sheet as a payroll processor, and analysts will often agree, because it is less reading for them too.
What a five-person team can truthfully say yes to
More than you might think, provided the work has actually been done. A useful yardstick is the Minimum Viable Secure Product, a public checklist of 25 controls in four groups that Google, Salesforce, Okta and others put together as a baseline for business software (MVSP). It was written to be short enough for a small company to meet. Much of a typical questionnaire maps onto it.
Several of these lines come straight from the checklist. It asks vendors to "maintain a list of third-party companies with access to customer data", to store logs "for at least 30 days", to "securely backup all data to a different location than where the application is running", and to notify people of a breach "no later than 72 hours upon discovery".
Notice the first row. A large share of any questionnaire is about buildings: guards, cameras, fire suppression, visitor logs. If your product runs entirely on a major cloud platform, those controls exist and are audited, just not by you. Say exactly that, once, and refer back to it. Do not answer "yes" as if they were your guards, and do not answer "no" as if nobody were guarding anything.
What you cannot say yes to, and what to write instead
These are the rows where founders are tempted. Here is wording that is true for most very small vendors and still reads as a company that knows what it is doing.
Three things make those answers work. Each one states the fact first. Each says what you do in place of the thing you lack. And each date is one you intend to keep, because the analyst will put it in a calendar and ask again.
What not to do: leave a row blank, write "N/A" on something that plainly applies, or answer a different question from the one asked. Analysts read hundreds of these. Evasion is the pattern they are best at spotting, and it moves you up a risk tier faster than any single no.
The first week: what to fix before you send it back
Most questionnaires allow a couple of weeks. Use the first one to turn some of your "not yet" rows into "yes". In rough order of how much they change the sheet for the effort:
Enforce two-step sign-in everywhere staff log in. An afternoon. It is the row most likely to be marked as a blocker.
Write the access list. Who can reach production data, the cloud console, the code and the billing system. Remove anyone who no longer needs it, including the contractor from last year.
Restore a backup. Onto a spare database, with a stopwatch. You now have a tested backup and a recovery time, which answers four or five rows at once.
Publish a sub-processor list and a security contact. One page on your site naming your cloud host, email sender, payment processor, error tracker and any AI model provider, and an address such as security@ where a flaw can be reported. The checklist above calls the second part a vulnerability disclosure policy.
Write four short policies. Access, incident response, backups, and acceptable use. One page each, describing what you really do. A policy nobody follows is worse than none, because it is a written yes that is false.
Book the penetration test. You do not need the result this week. You need a date. Ask two firms for a quote on your actual scope.
If your product was built quickly with AI tools, check the basics underneath all this first: access rules on every record, keys out of the browser, limits on sign-up. We listed them in six things to check before customers log in. No policy covers for a table that any signed-in user can read.
SOC 2: what it is, what it costs, and when to start
SOC 2 is a report by an independent accounting firm on a company's controls for security and, optionally, availability, confidentiality, processing integrity and privacy. It comes in two types. Type 1 says the controls were designed properly on one day. Type 2 says they actually operated over a period, typically three to twelve months, and it is the one enterprise buyers ask for.
Drata, which sells software for the process, puts the auditor's fee at $7,500 to $15,000 for a Type 1 and $12,000 to $20,000 for a Type 2 at small and mid-sized companies, and says most startups spend $25,000 to $50,000 in all once tools and preparation are counted (Drata). Those are a vendor's figures, so treat them as a range to check against real quotes. The larger cost for five people is time: someone senior loses weeks to collecting evidence.
So do not start one because a single questionnaire asked. Start when the arithmetic says so:
One buyer asks, and accepts your answer above: carry on without it.
A buyer makes it a condition, and the contract is worth several times the cost: agree a Type 1 by a date written into the contract, and begin the Type 2 period the day the Type 1 is done.
The third buyer in a year asks: it is now a cost of selling to this market. Budget for it as you would for a salesperson.
What to offer in the meantime
Two things cost nothing but time. Fill in the Minimum Viable Secure Product checklist against your own product and keep it as a dated document. And complete the CAIQ once: the Cloud Security Alliance accepts it as a self-assessment and publishes it on its public STAR registry at no charge (CSA). It is your own word, not an audit, and you should say so. But a buyer who sees that you have already answered 261 standard questions in public will often take that file instead of their own sheet.
The new section: questions about AI
Sheets written or revised in the last year have a block that older ones did not. The standard questionnaires now carry it too: the SIG maps to ISO 42001, and the Cloud Security Alliance has a separate AI questionnaire with its own registry level. The questions are new, but the honest answers are mostly facts you can look up in an afternoon.
Does your product use AI, and for what? List each feature in a line. "Drafts a reply for the agent to edit" is a different risk from "decides whether a claim is paid", and the analyst needs to know which you are.
Which model providers receive our data? They are sub-processors. Put them on the list with the others. If you call a model through a cloud platform, name both.
Is our data used to train models? Two answers are needed: yours and your provider's. For yours, say plainly whether you train or tune anything on customer content. For the provider's, quote its terms and link them. OpenAI's documentation, for example, says data sent to its API "is not used to train or improve OpenAI models" unless the customer opts in, and that abuse-monitoring logs are "retained for up to 30 days" (OpenAI). Read the page for the plan you are actually on. Consumer chat plans and API plans often differ, and "we use the API" is only a good answer if nobody on the team pastes customer data into a personal chat account.
Can a customer switch the AI features off? If yes, say where. If no, say so; it may be a cheap thing to add and it removes a whole class of objection.
Is there human review of AI output before it reaches our customers or changes our data? Describe the real flow. "A person approves every message" and "sent automatically, logged, reversible for 30 days" are both respectable answers. "Yes" with nothing behind it is not.
Do your developers use AI coding tools, and does our data or code pass through them? Almost certainly yes to the first part, and you should say so. Then state which tools, on what plan, and that customer production data is not put into them. If changes are written with these tools, the buyer's next question is who reviews them, which we cover in who reads the AI's code.
What is your role under the EU AI Act, and do you meet the transparency duties? Since 2 August 2026, Article 50 requires that people are told when they are dealing with an AI system unless it is obvious, and that generated audio, images, video and text are marked as such in a way software can detect (Article 50). Buyers with European customers now ask their vendors to confirm this in writing. Whether you are a provider or a deployer for each feature decides which duties are yours. We went through that in what the AI Act asks of a small software vendor, and there is a short tool that produces a one-page answer you can attach.
Eight yes-or-no questions: your role for each AI feature, the Article 50 duties that apply, and a one-page answer for a customer's questionnaire.
Open the AI Act quick checkKeep the answers: the second questionnaire should take two hours
The first one takes days. Do not let that work vanish into one buyer's portal. Keep a single document with every question you have been asked, the answer you gave, the evidence behind it and the date. Review it every quarter and whenever something changes: a new sub-processor, a new AI feature, a person leaving.
Two rules for that file. One person owns it, by name. And the "not yet" rows live in the same place as your work plan, so that the dates you gave to a customer are dates somebody is working towards. A year on, most of them should have moved up a column, and the next analyst will see a small company that does what it says. For a first enterprise deal, that is most of what they were looking for.
Sources
Minimum Viable Secure Product, the control list (the 25 controls and the quoted wording); Cloud Security Alliance, CAIQ v4 released: changes from v3.1 to v4 (7 June 2021) and STAR (the free self-assessment, the public registry and the AI level); Mitratech, SIG 2026: key updates and considerations (5 March 2026); Drata, How much does a SOC 2 audit cost (dated 25 March 2026); OpenAI, Your data; EU AI Act, Article 50. Pages read on 12 and 13 October 2026. The SIG itself is available only to members of Shared Assessments, so its question counts are given loosely here; the figures published by third parties disagree with each other. The table of answers, the sample wording and the first-week list are our own suggestions; they are not legal advice, and wording that goes into a contract deserves a lawyer's eye.