Passing Enterprise Due Diligence With a Lovable App

An enterprise procurement review is not a hostile exercise, but it is a thorough one. The reviewer's job is to find the gap you didn't document. This guide is the pack we hand over — the six documents, the questions buyers actually ask, and the honest answer to the objection every AI-assisted vendor eventually has to give.

The document pack a reviewer asks for

A reviewer wants six artefacts. Missing any one of them extends the cycle by a week each time it has to be requested; delivering all six in the first exchange is what shortens a review from months to weeks.

1. Security scan output. The latest automated scan of the application — dependency vulnerabilities, static analysis findings, exposed secrets check — with a status line per finding (accepted, mitigated, fixed) and dates. Reviewers don't expect zero findings; they expect that every finding has been read.
2. RLS policy summary. A short document listing every table with row-level security enabled, the policy that governs it, and the intent in one sentence. This is the fastest way to show that authorisation is designed, not assumed.
3. Secrets audit. A list of every credential the application uses — API keys, webhooks, service accounts — where it is stored, who can rotate it, and when it was last rotated. No values, no fragments; just the inventory.
4. Platform compliance references. Links to Lovable's SOC 2 Type 2 report and ISO 27001:2022 certificate on trust.lovable.dev (under NDA), plus the current sub-processor list and DPA. These belong in the pack as platform assurance — cited, not paraphrased.
5. Penetration-test results. A recent test scoped to the application (not just the platform), with the executive summary, the finding count by severity, and the remediation status per finding. If the client requires their own test, say so and describe the process for accommodating it.
6. Written security posture assessment. A short document — three to five pages — that ties the other five together: what is inherited from the platform, what the application owns, how incidents are handled, and how changes are reviewed. This is the document reviewers cite in their approval memo.

The questions buyers actually ask

The written questionnaire is one part of the review. The verbal call is where the decision gets made. The questions that decide it, from experience, are:

• "Where does our data live, exactly?" Answer with the region, the peripheral services that touch the data (email, error tracking, analytics, AI, CDN) and the region each of those services processes in. Vague answers here fail the review on their own.
• "Who can see our data internally?" Named roles, not "the engineering team". Least-privilege in principle, evidenced in practice.
• "What happens when a user asks to be erased?" Walk through the actual code path. If the answer is "we'd have to build it", the deal stalls.
• "How do you handle an incident?" A named responder, a stated response time, a communication plan, and evidence of a post-incident review from a past event — even a small one.
• "What's your change-management process?" Show a real pull request from staging to production with the reviewer, the scan output, and the approval trail attached.
• "What happens if the platform goes away?" Data export path, code ownership, portability posture. The honest answer is that migration is work, not a click, and reviewers respect that more than a claim of zero lock-in.

Answering the "you built this with AI?" objection

It comes up in almost every review, and defensiveness is what fails it. The answer that works is direct:

Yes. We use an AI development platform to accelerate writing code. It does not make design decisions, it does not approve pull requests, and it does not carry accountability for what ships. Every change to a client instance is reviewed by an engineer, scanned automatically, and — for security-sensitive surfaces like authentication, authorisation, payment, and personal-data flows — signed off by a named human. We are willing to walk you through a recent pull request end-to-end so you can see the process operate on real code.

Two things make this answer land. First, it names what AI assistance actually does and does not do, so the reviewer doesn't have to guess. Second, the offer to walk through a real change is the concrete evidence that turns a policy statement into an audit finding. Reviewers take that offer surprisingly often, and it is almost always the moment the review moves forward.

For the platform-side context that sits behind these answers, see Is Lovable secure enough for enterprise? and Building GDPR-compliant apps on Lovable.