One rule before the list. An honest no with a date attached beats a vague yes. Reviewers read hundreds of these. The vague ones are the ones they remember.
The twelve questions, for a vibe-coded app
1
Is multi-factor authentication enforced for all administrative access?
What they mean: can someone with your password alone reach the database, the host, the code and the domain.
The control: MFA on the Supabase organisation, the Vercel or Netlify team, the repository, the domain registrar and the payment account. Enforced, not available.
Evidence: a screenshot of the enforcement setting on each. A weekend's work.
2
How is access to production restricted and reviewed?
What they mean: how many people can take production down, and do you know who they are.
The control: a list of every account with production access, at least two owners on every critical account and no more than necessary, reviewed on a date.
Evidence: the list, with the date of the last review. If the list is "me", say so and add the second owner this week.
3
Is customer data segregated between tenants?
What they mean: can one customer read another's rows.
The control: row level security enabled on every table that holds user data, with a policy that names the user, and the same for storage buckets and Firebase rules. No policy that amounts to allow everything.
Evidence: the Security Advisor output with no open findings, and a test from an anonymous session that fails. See row level security mistakes in AI-built apps.
4
How are secrets and credentials managed?
What they mean: is there a service key in the browser bundle.
The control: no secret in a VITE_ or NEXT_PUBLIC_ variable, server-side secrets in the host's environment store, rotated if they were ever exposed.
Evidence: the environment variable list by name, and the rotation date for anything that was once public.
5
Is data encrypted at rest and in transit?
What they mean: the usual, and this one is mostly yes by default on the platforms you use.
The control: managed Postgres and object storage encrypt at rest; HTTPS everywhere, including the custom domain.
Evidence: the platform's documentation page for each, and your TLS configuration. Do not claim more than the platform does.
6
Are backups taken, and has a restore been tested?
What they mean: the second half. Everyone has backups. Few have restored one.
The control: a paid plan with daily backups, point-in-time recovery where the data warrants it, an off-platform copy, storage included, and a restore performed on a date.
Evidence: the restore log with a date. If the Free plan is in use, the honest answer is "no automatic backups; moving to a paid plan on this date". See Supabase backups and recovery.
7
Is there logging and monitoring, and who reviews it?
What they mean: would you know it was down, or breached, before a customer told you.
The control: uptime checks on the core workflow, error tracking, and a platform that ties front end, functions and database together, with alerts routed to a named person.
Evidence: the alert that fired last and who answered it. "Alerts go to an inbox" is a no.
8
Do you have an incident response plan?
What they mean: if the database leaks on a Saturday, what happens, in what order, and who tells us.
The control: one page. Who declares, who is contacted, on which channel, how customers are told, who signs off that it is over. Then run it once on paper.
Evidence: the page, and the date you walked through it. See what our own tabletop taught us.
9
How are vulnerabilities in dependencies managed?
What they mean: what happens when a package you use turns out to be malicious or flawed.
The control: dependency scanning in the pipeline, a committed lockfile, install scripts off by default, a minimum release age, and a named person who acts on critical findings.
Evidence: the last critical finding and when it was closed. See when the package you trust is the attack.
10
Has the application been penetration tested?
What they mean: has anyone outside the team tried to break it.
The control: a test by a specialist firm, scoped to the app and its backend, with findings fixed and retested. This is specialist work. Say who does it for you, or that it is scheduled, with a date.
Evidence: the summary report and the retest confirmation. An automated scan is not a penetration test, and reviewers know the difference.
11
Where is data stored, and who are your sub-processors?
What they mean: which regions, and which third parties touch the data.
The control: know the region of every data store, including the AI model provider if customer data reaches it, and list every service that processes customer data.
Evidence: the list with regions. The model provider's data terms, read and dated, if you send customer content to a model.
12
Do you hold any security certifications?
What they mean: usually ISO 27001, SOC 2 or Cyber Essentials.
The control: for a first questionnaire, probably none, and that is normal. Cyber Essentials is the realistic first step for a UK company and it is mostly the controls above.
Evidence: "not yet; the controls in questions one to eleven are in place and evidenced; Cyber Essentials planned for this date." That answer gets through more reviews than people expect.
Count the questions whose honest answer is about a setting or a process rather than the code. It is most of them. The app is not the problem. The operating around it is, and that is the half that was never in the prompt.
Where we fit
Critical Cloud turns the questionnaire into true answers. Critical Launch starts with a Launch Check that reviews exactly these controls on the stack you built with, fixes what it finds, and takes the app into production support: the monitoring, the person who answers, the backups that have been restored and the security review after every change. You keep the code and the product. For question ten we partner with a specialist rather than claim it ourselves. For question twelve, our own due-diligence pack is what a finished answer looks like, and it took us a while to get there too.
Frequently asked questions
Should I admit the app was built with AI tools on a security questionnaire?
Answer the questions that are asked, honestly. Questionnaires ask about controls, not about how the code was written, and the controls are what the reviewer is judging. If a question does ask about development practices, say what you use and what reviews the output: a scanner in the pipeline, a security review before each release, a named person who owns production. An honest no with a date attached beats a vague yes every time, because reviewers read hundreds of these and the vague ones stand out.
What if the honest answer to most of the questions is no?
Then the questionnaire is a backlog, and that is useful. Most of the twelve questions are settings, access and process rather than code: row level security, multi-factor authentication, a second owner on every account, a backup that has been restored, a person who answers at night. Half of that fits in a weekend. The other half is ongoing, and it is where a production support partner earns its place. Answer with what is true today and the date the rest will be.
Can Critical Cloud help us answer and then make the answers true?
Yes. Critical Launch starts with a Launch Check that reviews exactly the controls these questions ask about, on the stack you built with, then fixes what it finds and takes the app into production support. You keep the code and the product. For the questions about testing, we partner with a specialist rather than claim it ourselves, and for the questions about certification, we are honest that a startup's first questionnaire is answered with controls and evidence, not certificates.
Sources
- The twelve questions are the ones that recur across the customer and investor questionnaires we have helped founders answer, and the ones we answer ourselves. No questionnaire or customer is identified.
- Platform behaviours (backups by plan, public variables, row level security defaults) are as documented by Supabase, Vercel and Netlify at the time of writing, and covered in detail in the linked posts.