It usually arrives as a spreadsheet with somewhere between eighty and three hundred rows, from someone in procurement you have not spoken to, with a due date. Your champion at the customer is enthusiastic and cannot help. Nothing in the sheet is about whether your product is good.
For a founder whose app was built in a builder six months ago, the first read is genuinely alarming, because a lot of the questions have no answer yet. This is the guide we give clients when it happens, and the encouraging part is at the top: most of the sheet is answerable today, and the part that is not is a smaller list than it looks.
What the questionnaire is actually for
It is not a test you pass. It is a risk file. Someone at the buyer has to be able to show that they asked, wrote down what you said, and made a judgement. A clear “no, and here is our plan and date” is a usable answer for that purpose. A vague “yes” that falls apart under a follow-up question is not, and it is the thing that actually kills deals - because once one answer looks unreliable, every answer needs re-checking, and that is when the file goes quiet.
The six sections, and what is behind each one
1. Access control
Who can reach production, how they authenticate, and how access is removed when someone leaves. For a two-person company the honest answer is short and perfectly acceptable - provided that it is true and that the mechanism exists.
- Multi-factor authentication on every account that can reach production, including the cloud console, the database, the domain registrar, and the email provider.
- Named accounts rather than a shared login. The shared
admin@account is a specific finding reviewers look for. - A written offboarding step, even if it has never been used. "We have never had a leaver" is fine; "we have not thought about it" is not.
2. Data protection
Where the data lives, what is encrypted, and who else can see it. Managed cloud providers give you most of this for free, so most of the work is being able to say precisely which ones you use.
- Encryption at rest and in transit - on by default with any managed database and any modern host, but you need to be able to name the provider and the region.
- A subprocessor list: every third party that touches customer data. Analytics, email, error tracking, AI providers. This one catches people out, and AI subprocessors are the row reviewers now read most closely.
- Data residency. If the buyer is European and your database is in
us-east-1, that is a conversation to have early rather than in week six.
3. Tenant isolation
How you prevent one customer from seeing another's data. This is the section where AI-built apps most often have a real problem, because the app authenticates well and authorizes poorly, and it is exactly the question a reviewer is best equipped to probe.
Before you answer it, test it: create two accounts, and from the second one call your API directly with the first one's record ids. If anything comes back, that is your answer and it needs fixing before the sheet goes back. Doing this before the customer's security team does is the entire game.
4. Availability and recovery
Backups, recovery objectives, and what happens during an incident. Reviewers are not expecting a nine-figure availability story from a startup; they are checking that you have thought about it in numbers rather than in adjectives.
- Backup frequency, retention, and - the row people skip - the date of the last successful test restore. Restore one into a scratch database, time it, write the number down. Now you have a recovery time objective rather than a hope.
- A one-page incident response plan: who is notified, how customers are told, and within how long. One page is enough; nothing is not.
- Uptime monitoring that alerts a human. "We would notice" is not a monitoring strategy and reviewers know the phrase.
5. Secure development
How code gets from someone's head into production. This is where an AI-built app either looks careful or looks improvised, and the difference is mostly mechanical.
- Version control with pull requests and review. "Deployed from the builder's editor" is a very difficult answer to give well.
- Automated tests and dependency scanning in the pipeline. Both are free on any major CI provider and take an afternoon.
- Separate development and production environments with separate credentials. Reviewers ask this directly and it is the answer that most often reveals everything else.
6. Certifications
The SOC 2 row. If you do not have one, say so, and say what you do have and when you plan to start. A pre-SOC-2 vendor with a named security owner, a documented control set and a target date is a normal thing for procurement to process. A vendor who is evasive about it is not.
Worth knowing before you spend money: SOC 2 certifies that the controls you claim to have are the controls you actually operate. Buying the audit before the controls exist just means paying someone to document their absence. The controls come first, and most of them are the six sections above.
What to fix first if the deal is live
Ranked by how much of a typical sheet each one unblocks, against how long it takes:
| Control | Effort | Rows it unblocks |
|---|---|---|
| MFA everywhere, named accounts | Half a day | Most of the access-control section |
| Separate dev and production, no shared credentials | 1–2 days | Access control and secure development |
| Tenant isolation tested and fixed | 2–10 days | The section that would otherwise stop the deal |
| Backups tested, recovery time measured | Half a day | Most of availability and recovery |
| CI with tests and dependency scanning | 1 day | Most of secure development |
| Subprocessor list and a one-page policy set | 1 day | Data protection, plus the certification narrative |
That is roughly one to three weeks of hardening work on a small AI-built app, and it converts the majority of a standard questionnaire from “no” to “yes, and here is how it works”. It is also, almost line for line, the work that makes the app safe independently of anyone asking.
The part nobody tells you
A questionnaire is a good sign. It means someone with a budget wants to buy your product and is now doing the paperwork required to be allowed to. The failure mode is not answering a row badly; it is going quiet for three weeks because the sheet felt impossible, by which time your champion has lost momentum internally.
Reply within a couple of days with the honest version, including the gaps and the dates you will close them by. Buyers are used to that from early-stage vendors. What they are not used to, and what wins, is a founder who clearly already knew the answers before the sheet arrived.
Written by Kato Chojiro
Takes AI-built MVPs to production: security, data, and the infrastructure underneath.
Connect on LinkedIn