Security questionnaires
A customer sent you a security questionnaire.
Your app was built on Lovable, Replit or Base44. Here's how you decide between what you can answer yourself and what the platform gives you.
You can answer most of a security questionnaire by simply pointing to what your AI coding platform already does. Lovable, Replit and Base44 all encrypt data in transit and at rest, and all three hold SOC 2 (a high-level industry standard for compliance and security) attestations of their own. The questions that could stop you now are the ones about the application you built on top: who can reach which customer's records, where the API keys live, whether anyone reviewed the code, and whether a third party has ever tested it. You can find those answers too, but this is where guessing or relying on the platform to catch you can lead to contractual consequences.
What a security questionnaire is, and why you got one
You're a business genius. You discovered a new niche in the market, found a better way to optimize internal processes, or finally had enough of Bezos and decided you're gonna be the next Amazon. Then you put your nose to the grindstone and vibecoded an app that locks in that opportunity.
Now you're selling it, and your first big customer has dropped a security questionnaire on your desk and said that, until you can satisfy their board that your cool thing won't leak their customers' data, they can't sign that sweet contract.
A security questionnaire — whether in a standardised form like a Shared Assessments SIG or CSA's CAIQ, or in a slapped-together spreadsheet — is a very routine ask for software vendors from their customers. Where those customers have compliance, privacy or security concerns of their own, it is their responsibility to ensure that the companies with whom they do business maintain a high standard of protection.
If you install a top-end security system in your house, but then hand the keys to the first shady dude to offer to clean your windows, your security as a whole is not high quality. Because this is common-sense best practice, there's no reason to fret. Although these questionnaires can be intimidating, with SIG's Core assessment coming in at 855 questions across 21 risk domains, it's a routine ask, and your customer is not looking for you to fail.
The three kinds of question, and which ones you can actually answer
Although the questions you're expected to answer will differ, for your purposes you can divide them into three buckets.
Bucket A — Your platform’s problem
Physical security, hosting, infrastructure, encryption, sub-processor certifications. Answer these the best you can, then point the reader to the platform and their own attestations. This is basically free, and usually about a third of the form.
Bucket B — Missing paperwork
An incident response plan, an access review policy, a data retention schedule, a named security contact. These are items where it matters much more to have the thing than for the thing to be flawless. Right now you are probably missing most of them, and that is fine. Either answer “no” and make clear you will build each one in due time, or draft and implement a first version and answer “yes.” The key is that you must actually implement the process documentation you draft.
Bucket C — Nobody knows until somebody checks
Cross-tenant data access, secrets in the client bundle, endpoints that check authentication but not authorisation, absent audit logging. These are real code problems the platform cannot solve for you — the things your coding agent built under the hood, usually without much oversight or particular direction.
Bucket C is where AI-built apps actually fail. You can give general instructions like “make sure to never build secrets into the distribution bundle,” but asking for best practice is not the same as getting it. This is where you'll need to pop the hood, go through everything, and make sure nothing's amiss. This is where the work really starts, and where it may be worth delegating to a third party. Business geniuses love to delegate.
What your platform already answers for you
Take the free answers. All three major platforms publish a great deal of information on this topic. Look at them first.
Lovable
ISO 27001:2022 certified and SOC 2 Type 1 and Type 2 compliant as of August 2025, with AES-256 encryption at rest, TLS 1.3 in transit, and a separate Supabase project per Lovable project — a real answer to the infrastructure-level tenant isolation question.
Lovable — security overviewReplit
A SOC 2 Type 2 attestation, audited annually, with AES-256 at rest and TLS 1.2+ in transit, running on Google Cloud infrastructure that carries its own ISO 27001 certification.
Replit — information securityBase44
SOC 2 Type II and ISO 27001 certified, GDPR-compliant with a DPA on request, AES-256 at rest, TLS 1.2+ in transit, PCI DSS-certified providers handling payments, plus data residency options, regular penetration testing and a bug bounty.
Base44 — securityIf that reads like a bunch of word soup, good news: the security questionnaire is a bowl. Put the soup in the bowl and let ‘em slurp.
All told, that's a large share of a standard questionnaire. However, there's a very important distinction you need to be aware of.
Your platform's certification is not your certification.
It answers for the platform's infrastructure. It says nothing about the access rules in your database, and the questionnaire is asking about both.
Two of the three platforms make that distinction explicitly clear themselves. Lovable's Founder's Guide calls out row-level security, secret management, scanner findings and third-party penetration testing as the responsibility of the builder. Base44's security documentation is real blunt: “You are responsible for your app's security settings. Base44 provides the tools, but always review your permissions and run a security scan before you publish.”
Replit's information-security documentation covers the platform only and doesn't address the split at all. That's worth knowing if you built there, as it means less guidance about your half — not less responsibility for it.
What is the questionnaire really asking about your app?
These are the areas where AI-built apps often let things slip. Going through these types of questions and detailing real answers will tell you a lot about your app. If there's a place where you can expect to find some oopsies, it's here.
Can one customer reach another’s data?
Lovable and most Base44 apps use row-level security in Supabase. With RLS, the rules about who can read what are written and checked right in the database — an excellent policy when done properly, because the database knows who may read a given piece of data at the point where it is read. When the policies are not meticulously managed, users get access to data they should not have.
In May 2025 an extremely critical vulnerability was filed with the National Vulnerability Database detailing how Lovable apps were allowing remote attackers to read from or write to arbitrary database tables. If you follow that link you will notice Lovable has disputed the claim, on the grounds that “each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application.” Before you got this questionnaire, could you have detailed your RLS policy?
Where are the API keys?
API keys serve as proof of identity when your application talks to different parts of itself, or to third parties. If they are included in the parts of your application that run in the user’s browser, an attacker can copy them right out of there. At that point the attacker can do whatever they like, including running up hefty bills under your name with third-party vendors.
Does every endpoint check authorisation, not just authentication?
Authentication is how software determines who is asking for something. Authorisation determines what that person is allowed to do. A valid authentication check tells you “this user is person@email.com”, but without a robust authorisation scheme nothing says “person@email.com can only look at this account, not the one owned by dog@email.com.” In many AI-built applications only the first is checked, meaning anyone who has successfully logged in may be able to do a lot of damage and see a lot of private material.
Is anything logged?
In many compliance regimes, when you are handling private data under the auspice of a governing entity — such as HIPAA under HHS — audit logs are a requirement to verify who had what information, or performed what actions. Getting it right is simple but not easy, and many vibecoded apps miss it entirely.
Did anyone review the code?
Questionnaires ask about secure development lifecycle, code review and change management — meaning, who decided that this particular code should be the code that got shipped. If the answer is “the model wrote it and I deployed it,” that is worth knowing before you write it down.
Veracode’s Spring 2026 GenAI update found that across 150+ models, roughly 45% of AI-generated code still ships with known security vulnerabilities.
If you'd rather not find out the answers to these five while a buyer is waiting, that is the whole of what we do: 1 week, fixed price at $499, and a severity-ordered report you can answer the form from.
Learn more about your app before you send the formDo you need SOC 2 or a penetration test to answer this?
If you've just received your first security questionnaire, probably not.
SOC 2 takes months to implement and significant money to certify, and it's completely voluntary. Although it's one of the most visible trust signals for enterprise software, there's no industry in which it's legally required. A penetration test is a much faster and more reasonable ask. Lovable ships an Aikido integration for exactly that purpose.
Is either of those items going to block your deal? The only way to learn is to ask your customer. As one SaaS attorney puts it, many enterprise customers will proceed without SOC 2 if you can directly and honestly address their concerns. Filling out your questionnaire with answers that clearly present your limitations, your processes and your plans will get you much further than scrambling after SOC 2.
What happens if you answer “yes” and it isn't true
I am not a lawyer! If you have real contract questions, find a billboard and call the guy with the catchy phone number. But I can tell you that these questionnaires aren't for show. They form part of the contractual record, and an inaccurate “yes” on encryption, logging or incident response creates the same exposure as an itemised security clause that you aren't meeting.
Remember that many customers are happy to work with “no, but here's how we're going to address it.” So why put “yes, we do it exactly that way” if you don't? You don't want a lawyer reading this back to you after some major breach and be completely unable to defend yourself.
How to answer honestly when the answer is “no”
Honesty, forthrightness, and a real plan. Again, this questionnaire is not a scantron test to be aced or failed. This is about establishing the current state of the software, and where you are going. “Not yet, but here's when” is a perfectly reasonable answer.
The pattern the customer will be happy with is scope, then status, then a date.
- “This feature has been enforced for production systems. Staging is on the same roadmap, with delivery targeted this quarter.”
- “This requirement is partially fulfilled via MFA for admin accounts. End-user MFA is on the backlog; we will be pulling it into the official roadmap later this year.”
- “Not yet. Our platform provides RLS at the database level today; we’re building application-layer auth filtering now, with a delivery date later this month.”
The trick is to give answers you can defend. The customer doesn't expect to buy a perfect system, but they do need to trust that you can back up what you say.
What to do this week
Read the whole form first
Do not start answering at question one. You need the shape of the document before you can judge how much of it is genuinely hard.
Sort every question into A, B or C
This turns an intimidating document into three short lists — one you can answer for free, one that is paperwork, and one that needs checking.
Answer bucket A from your platform’s trust page
Attach the certification documentation they provide where it is available, or point the reader to their trust or security page.
Start bucket B
Write the policies. They are short, and they are yours to keep.
Get bucket C checked before you write anything down
By whoever built it, or by someone external. These are the answers that are expensive to get wrong.
Tell the customer your timeline
Buyers accept “you will have this by next Friday” far more readily than founders expect.
Before you send that form
- Can the right people access the right parts of the app—and nobody else?
- Is customer information kept private and separated correctly?
- Are passwords, payment keys, and other sensitive information protected?
- Could someone reach data or features they shouldn’t be able to?
- What could break, expose customer information, or become costly as you grow?
Talk to software professionals with decades of experience, or consider a security and production-readiness audit of your Lovable, Replit, Bolt or Base44 app. It takes one week (of our time, not yours), costs $499, and includes a report of items listed by severity.
$499 fixed price · 1 week
Learn more about your app before you send the formCommon questions
- Do I need to be SOC 2 compliant to answer a security questionnaire?
- Usually not. Most buyers will happily proceed without SOC 2 if you can honestly convey the state of your application and your plans for improvement. To be sure, ask your customer.
- My app was built on Lovable. Does their ISO 27001 certification cover my app?
- No. It covers Lovable’s platform and infrastructure. But your application — meaning your database access rules, API keys, and auth checks — are your responsibility. Lovable’s own documentation makes that very clear. The questionnaire is asking about both halves.
- Can I just answer yes to everything to get the deal through?
- No. What you write down and provide to them as part of this process is part of the record. If you lie, you are exposed. Consult with your lawyer if you’re concerned about your answers.
- How long does an audit take, and will it hold up my deal?
- One week. Most questionnaire timelines are longer than that, and we can work on this end while you work through other pieces. If your timeline is tight, reach out and we can chat through options.
- What if the audit finds nothing I need to disclose?
- Then you get a report saying so, while also detailing the architecture and design of your app. And there’s no such thing as perfect software. If you don’t have any critical security vulnerabilities, there are still ways to improve.