Security questionnaire: what buyers ask and how to answer without a security team

What a security questionnaire is, and why a buyer sends one

A security questionnaire is the list of questions a customer's security or procurement team sends before signing, to find out how you will handle their data. It arrives as a spreadsheet, a form in a vendor risk portal, or a standard document. The two standards you are most likely to meet are the Cloud Security Alliance's CAIQ (Consensus Assessments Initiative Questionnaire), whose version 4 has 261 questions, and the SIG (Standardized Information Gathering questionnaire) from Shared Assessments, best known in its short Lite and long Core versions. The first questionnaire a small SaaS receives is usually shorter, written by the buyer, and borrows from both.

Buyers are not asking out of curiosity. In Europe, a customer who stores personal data in your app is the controller and you are their processor. Article 28 of the GDPR requires the contract between you to make the processor provide the information needed to demonstrate compliance, and to allow audits. Article 32 asks both of you for "a process for regularly testing, assessing and evaluating the effectiveness" of your security measures. A questionnaire is how the buyer checks that on paper, which is why the testing questions are never optional.

If you built the product with Lovable, Bolt, Cursor or Claude Code, the first questionnaire usually comes with the first company customer. You do not need a security team to answer it. You need to know what is true about your app today, say it plainly, and attach proof. A specific answer with a date usually closes the question.

The questions you will be asked, in five groups

Questionnaires differ in length more than in substance. Almost every question falls into one of five groups.

Two groups have legal deadlines behind them in Europe. Under GDPR Article 33, a processor must tell the controller about a personal data breach "without undue delay", and the controller then has 72 hours after becoming aware of it, where feasible, to notify its supervisory authority, unless the breach is unlikely to put people at risk. Under Article 28, you may not bring in another processor without the controller's prior written authorisation. Buyers ask for your notification delay and your subprocessor list because their own deadlines depend on yours.

Expect more questions about AI: the 2026 SIG workbook, released in September 2025, added references to ISO 42001, the standard for AI management systems. The honest answer names the model provider, what data is sent to it, and the setting that governs whether it can be used for training.

How to answer a security questionnaire without a security team

1. 1

   Ask what is in scope

   Ask which product, environment and data the review covers, and whether the buyer accepts a document you already have, such as a test report, a trust page or a completed CAIQ, in place of some answers.

2. 2

   Answer the question asked, then prove it

   Start with Yes, No, Partially or Not applicable. Add one or two sentences on how, then the evidence: a document, a link, a date. Every extra sentence is something a reviewer can follow up on.

3. 3

   Separate your controls from your providers' controls

   Your host encrypts disks, guards data centres and runs backups. You decide who can read which rows. The CAIQ itself asks for this split: for each control, whether the cloud provider owns it, the customer owns it, a third party runs it, or it is shared. Cite the provider's report for its layer and answer for yours yourself.

4. 4

   Mark gaps honestly

   If a control does not exist yet, write No or Partially, what you do instead, and the date you will close the gap. Use Not applicable only with a reason, for example: "Not applicable: we have no office or server room; production runs at [provider], whose report covers its data centres."

5. 5

   Keep an answer file

   One sheet: question, answer, evidence, date, who checked it. The next questionnaire reuses most of it, and the dates show which answers to check again.

The third row matters most for an app built with AI, and it is the one founders most often answer from memory. In apps generated on Supabase, the gap we see most is a table with row level security (RLS) off, or a policy that lets any signed-in user read every row. That is the flaw behind CVE-2025-48757: a researcher found missing or weak RLS in 170 of the 1,645 Lovable apps he analysed, about one in ten. Before you send the sentence "users only see their own data", test it. The query below lists the tables with RLS off; the Supabase RLS guide and the IDOR guide show how to test the policies on the rest.

-- Supabase SQL editor: tables in the public schema with row level security off
select tablename
from pg_tables
where schemaname = 'public' and rowsecurity = false;

How to answer the testing questions truthfully

The testing section is where honest founders get nervous, and where a false answer does the most damage. Every answer in it needs four facts.

• What was tested. The live app at its address, the API, the admin area, as an anonymous visitor and as a signed-in user. Say what was out of scope.
• When. The date of the last full test and of the last retest. A test from before your last big rewrite says little about the app you ship today.
• By whom, or by what. A human tester at a named firm, an automated attack service, or your own team. Each is a fine answer when it is the true one.
• What is still open. Open findings by severity, and the date each serious one will be fixed. Zero open findings only means something next to a date and a scope.

Use the buyer's words with their real meaning. The NIST glossary defines penetration testing as a test methodology in which assessors "attempt to circumvent or defeat the security features of a system". A dependency scanner or a header check does not do that: call it a vulnerability scan. A service that attacks the live app and proves each finding with the request that worked is automated penetration testing; a person doing it with judgment about your business is a manual test. See pentest vs vulnerability scan and automated penetration testing.

On frequency, most buyers have an external test at least once a year in mind. CIS Control 18 asks for periodic external penetration tests "no less than annually", for findings to be fixed through a documented process, and for security measures to be validated after each test. An app that ships every day changes a lot between two annual tests, so testing on every deploy is a strong answer to "do you test after significant changes?". It does not replace a manual test when the buyer explicitly requires one.

Template answers for the testing section

Copy the version that matches your situation, replace every bracket, and delete any sentence that is not true for you. These are starting points for your own words, not text to paste unchanged.

Do you perform penetration testing? When was the last test?

If you have not tested yet:
No penetration test has been performed yet. Our database provider's security
advisor runs [frequency] and dependency alerts are enabled on our repository.
An external test of the production application is scheduled for [date]. We will
share the dated results, including any open findings, when it completes.

If an automated service attacks your app:
Yes, automated. Our production application ([URL]) is attacked from the outside
by [service] [on every deploy / on date], as an anonymous visitor and as two
signed-in test accounts. Last full test: [date], [N] attacks. Each finding is
proven by the request that worked and retested after the fix. We have not had a
manual penetration test by a third party; one is planned for [date or event].

If you had a manual test:
Yes. [Firm] performed a [black box / grey box] penetration test of [scope] from
[date] to [date]. Findings: [n] high, [n] medium, [n] low. All high findings were
fixed and retested on [date]. We test at least once a year and after major
changes.

Are there open critical or high findings?

As of [date]: [0] critical, [0] high, [n] medium open.
[One line per medium finding, without technical detail], fix planned by [date].
A finding is closed only after a retest shows the attack no longer works.

What are your remediation timelines?

Confirmed findings are fixed or mitigated within: critical [N] days,
high [N] days, medium [N] days, low at the next planned release.
A finding is closed only when a retest confirms the fix. Exceptions are
recorded with a reason and a new date.

Pick numbers you have already met, not the ones that look best. A careful reviewer may ask for the dates of your last few critical fixes, and your retest history should match the policy.

Can you share the report?

Yes. A summary is attached: scope, test dates, findings by severity and their
status. The full report contains technical detail and is available under NDA.
Our public trust page shows what was tested and when: [URL].

Do you test against the OWASP Top 10?

The OWASP Top 10 is a ranked list of web application risks, and its 2025 edition puts Broken Access Control first. Say which categories your tests cover rather than claiming all ten.

Our tests cover the OWASP Top 10:2025 categories that apply to our stack, with
most effort on A01 Broken Access Control (users reading or changing other users'
data, tested with two accounts) and A02 Security Misconfiguration (exposed files,
missing headers, open storage). Out of scope: [list]. Last tested: [date].

How can someone report a vulnerability to you?

Publish a security.txt file, then point to it. RFC 9116 places the file at /.well-known/security.txt, served over HTTPS, with two required fields, Contact and Expires, and recommends an expiry date less than a year ahead. Your answer: "Yes. Reports go to [address], published in our security.txt at [URL]. We reply within [N] business days."

Contact: mailto:[email protected]
Expires: 2027-10-31T23:00:00.000Z
Preferred-Languages: en

Evidence that shortens the back-and-forth

A reviewer who receives proof stops asking. These documents answer the most questions per page.

• A dated test report. Scope, dates, each finding with its severity, the proof that it was real, and its status. The request that worked convinces more than a list of possible issues. The penetration test report sample shows what a good one contains.
• The retest history. For each finding: found on, fixed on, retested on, and the result. It answers "how fast do you fix?" with facts instead of a policy.
• A public trust page. A stable address that shows what was tested and when. Prospects can read it before sending the questionnaire, and you can paste its link into every testing question.
• Your providers' reports. Supabase, for example, states that it encrypts all customer data at rest with AES-256 and in transit with TLS, and that Team and Enterprise customers can download its SOC 2 Type 2 report from the dashboard.
• A subprocessor list and a one-page incident plan. Short, dated and true, they answer most of the vendor and incident groups.

One limit to state plainly: Supabase's documentation says its SOC 2 compliance "does not transfer to environments outside of the Supabase product or Supabase's control". The access policies you write on your tables and the API routes you build are your responsibility, at every host. That layer is what an outside test of your app covers.

An outside test cannot answer the rest: your backups, who on your team has access, how you remove it, your incident plan, or flaws in your own business rules. Those answers are yours to write, and a manual test is the better tool for business logic.

What not to claim in a security questionnaire

A questionnaire answer is a written statement to a customer, and a buyer can make it part of the contract. These are the claims that cause trouble later.

• Absolute statements. "We have no vulnerabilities" or "our platform cannot be breached" cannot be proven by anyone. Write what was tested, when, and which attacks failed.
• Certifications you do not hold. A SOC 2 report is issued by a CPA firm after it examines the controls of your company. If no auditor has examined yours, the answer is "No SOC 2 report yet", followed by what you have instead. Your host's report does not make you compliant.
• A pentest that was a scan. If the test was a dependency scan or a header check, call it that.
• Policies that exist only on paper. "MFA is enforced for all staff" has to be true for every account, including the domain registrar and the email inbox that can reset all the others.
• Answers nobody checked. AI tools draft questionnaire answers fast, and they draft confident yeses. Check each one against your app and your accounts before it leaves.

Get ready before the next questionnaire arrives

Most of the work happens once, before any buyer asks. This list covers what a first questionnaire usually checks.

• MFA on every account that reaches production: code host, database, hosting, domain registrar, email.
• A list of who holds each of those accounts, and how access is removed when someone leaves.
• A subprocessor list with the purpose and region of each, AI model providers included.
• Row level security on every table, or the equivalent rules on your backend, tested with two accounts.
• No secret key in the JavaScript your app ships. Check with the API key leak checker.
• A dated test of the live app, the fixes, and the retest showing each attack now fails.
• A security.txt file, and a one-page incident plan that says who tells customers, and how fast.
• An answer file with every answer, its evidence and its date.

If you have never tested your app, start with penetration testing for startups, which covers what to test first and when a manual test is worth buying, and penetration testing cost for budgets.

Keybrum is built for the testing section. It runs more than 100 attacks against your live app, as a stranger and as two signed-in accounts: open tables and storage, users reading each other's data, secret keys in the bundle, unsigned webhooks, exposed files, and known Next.js and React flaws proven by behaviour. It only attacks apps whose owner has proved ownership. The €49 one-time report gives you a dated document to attach; the plans attack every deploy, keep retests open, and add a public trust page that shows what was tested and when.