Lovable Compliance: What a Customer Can Actually Be Sent

A customer, an investor or an acquirer has asked in writing for your SOC 2 report, meaning the report an outside firm writes about a software vendor’s own systems rather than SOC 1, SOC 3, the accounting sense of the word or a security operations centre. Alongside it they have asked for a signed data processing agreement, meaning the contract between a customer and the company running the app rather than a data protection authority, a power of attorney or a prosecution deal. They want the list of who else touches the data, and they want to know where that data sits, because the privacy regulation asks these questions of the company running the app and not of the person whose data it is.

Compliance here is the procurement sense of the word, not the HR, finance or tax sense. And the app was built on Lovable.

Lovable publishes four things a buyer asks for, and they do not line up. The SOC 2 report comes under NDA through an account manager. The data processing agreement ships on the Business and Enterprise plans. Four Lovable pages point at the subprocessor list, and none of them prints it.

What each document is, and who can get it, read on 3 September 2026:

• Lovable’s SOC 2 Type II report reaches a customer only on request and under NDA, and its March 2026 founder post routes that request through your account manager.
• The ISO 27001:2022 certificate is named in the same post and travels in the same request.
• The data processing agreement is published in full, and its own opening line puts a signed version on the Business and Enterprise plans.
• The subprocessor list is promised at four Lovable addresses and printed at none of them.
• Data residency is a choice between the three regions the security page names today, and the choice is made once per project.
• Your app can now publish a trust page of its own, off by default, which Lovable’s documentation says is not a certification.

This page is a documented read of Lovable’s own pages: the security page, the data processing agreement, the subprocessor page, the privacy policy, the trust centre address and the product documentation, each fetched twice on 3 September 2026, once as a plain request and once shaped like a browser, and each quoted or described as it stands. AxonBuild did not build, host, audit, sign, draft or test anything named here, and nothing on this page is legal advice or a verdict about whether your app complies with anything.

What your customer is actually asking for when they say “your SOC 2”

Four separate requests travel under that phrase, and they have four different answers on Lovable’s side. Sort them before you reply, because two can be answered from published pages and two depend on which plan you are on.

The first is the platform’s report. That is a document Lovable holds about its own systems, and getting a copy is a request with conditions attached rather than a download. The AICPA’s own landing page for the SOC suite of services says CPAs can use those offerings to provide assurance reports, which is why the thing that eventually lands in your customer’s inbox is a report about a period of time rather than a certificate anybody holds up. Whether to go after one of these reports for your own company is a decision of its own, taken on another page.

The second is a signed data processing agreement. Lovable publishes the full text, so you can read every clause before you ask for anything, and the plan you are on decides whether a signed copy is part of what you already pay for.

The third is the list of who else touches the data. Your customer wants company names for their own vendor file, and this is the request where Lovable’s pages disagree with each other.

The fourth is the region. Lovable’s security page names the regional hosting it supports, and the choice a project made when its backend was switched on is the answer, not a preference you can revise during the deal.

Two requests that often arrive in the same email belong elsewhere. A penetration test is a separate purchase with its own decision behind it, and what a customer or an auditor means when they ask for a penetration test works through that one. Health records are a different question again: which platform will enter into the agreement a health record needs, on which plan, and what that agreement then leaves to your app is set out for the whole set on one page.

What Lovable says about its own status, and the words it uses

Lovable describes the same SOC 2 status in four different ways across its own properties, and the data processing agreement turns it into a contractual promise. None of the five is wrong. They are aimed at different readers, and a buyer who reads two of them will notice.

The August 2025 post is the one most people have already seen, and it uses the plainest word of the four. It is quoted with its date in what Lovable’s platform controls reach, and where your own rules take over, so there is no reason to re-quote it here.

The March 2026 founder post is more careful. It says Lovable “is ISO 27001:2022 certified and SOC 2 Type II aligned, with security controls aligned to the SOC 2 Trust Services Criteria”, and adds that “the platform is GDPR compliant with a Data Processing Agreement available”. The same post gives the EU AI Act classification it says Lovable’s own AI usage was assessed at, Low Risk, in one line, and no page on this site opens that subject.

The security page today answers its own FAQ question about SOC 2 and the privacy regulation with a third formulation: “Lovable supports SOC 2 and GDPR requirements and provides security documentation and data protection agreements for enterprise review.” One heading on that page, “Compliant and certified”, carried no readable text at all in the document returned to either request shape on 3 September 2026, so whatever sits under it is carried by images rather than by words a reader or a crawler can quote.

The data processing agreement is the one document of the four that binds anybody. Its security section says Lovable “shall maintain SOC 2 Type II and ISO 27001 accreditations for the duration of the term of the Agreement”, which is a contractual commitment rather than a description.

What the spread does mean is that you should quote one of these pages by name and date when you answer, and say which one. What it does not mean is anything about your own app, in either direction. The same four words read against a different builder’s pages reach the same boundary from the Base44 side. What else Lovable names about itself, on the page it uses to introduce the product, is set out where that product is reviewed in full.

Can you send a customer Lovable’s report?

Lovable’s SOC 2 report reaches a customer through a request with conditions on it. The March 2026 founder post routes that request through your account manager and puts the report under NDA, and the agreement says Lovable may provide access on request, on approval, and on acceptance of confidentiality obligations.

Lovable’s founder post on security, published 24 March 2026 and read on 3 September 2026, puts it in one line: “The SOC 2 report is available under NDA through your account manager, and the Trust Center is publicly accessible at trust.lovable.dev.” The data processing agreement says the same thing in contract language, adding that “upon request, approval and acceptance to confidentiality obligations, Lovable may provide access to the recent SOC 2 Type II & ISO 27001 reports”.

Read those two together and the practical shape appears. An account manager is something a plan gives you. Approval is somebody’s decision. The word in the agreement is may, not shall. So the honest answer to give a customer on day one is that the report exists, that it comes under a confidentiality agreement, and that you have asked for it, with the date you asked.

There is a second constraint people miss until they are holding the file. A report that arrives under NDA is a report you cannot simply forward, which means the useful move is often to ask your customer’s reviewer whether Lovable’s trust centre and the published agreement close their platform rows, and to save the report request for the rows that stay open.

And the reviewer will come back. The rows that Lovable’s report answers are the rows about Lovable. The rows about who can read another tenant’s records in your database, who still has production access, and what your app logs when something goes wrong are answered by you, from your own app, whatever the platform’s paperwork says.

What Lovable’s data processing agreement covers, and what it leaves with you

The first line of Lovable’s data processing agreement is the surprise, and it is a plan gate: “If you’re on a Business or Enterprise plan, your usage includes our Data Processing Agreement (DPA). A signed version is available here.” The page carries its own date, last updated 6 November 2025, and was read here on 3 September 2026. Lovable publishes the four plan names Free, Pro, Business and Enterprise on lovable.dev/pricing, whose readable text on the same date carried no plan-by-plan comparison of compliance documents.

The roles are set out plainly. For EU personal data the agreement says “the Customer acts as a controller and Lovable acts as a processor”, with the equivalent split under the UK regulation and the business and service-provider pairing for US personal data. It also states that it “does not establish a joint controllership arrangement”, and that each party remains responsible for its own compliance in respect of its separate processing. That matters because Article 28 of the regulation is written around exactly that arrangement: a controller choosing a processor, and a contract that sets out what the processor may do.

Two clauses do more work than the rest.

The first is Service Data. Section 9 says Lovable may collect, use and disclose it for its own business purposes, and the list it gives includes “training or tuning proprietary machine-learning models used to deliver the Services”. The same section then states: “For the avoidance of doubt, Service Data is not ‘Customer Personal Data’ and the obligations set out in this DPA do not apply to Lovable’s Processing of Service Data.” Section 10 of the same agreement says the opposite thing about the other category, ruling out the use of customer personal data for training, retraining or fine-tuning any model. Both are true at once because they describe two different buckets, and a founder who has only read the training answer on the security page has not read the sentence that puts one of those buckets outside the agreement.

The second is the breach clause. Section 6 says Lovable will inform the customer “without undue delay after confirming a data breach” that meets the agreement’s definition, and that definition expressly excludes unsuccessful attempts, pings, port scans and failed logins. The clause also asks that if you decide to notify anyone in a way that names Lovable, you tell Lovable in advance and consider corrections it recommends. Lovable’s own privacy policy, read the same day, states a different number for its own practice, saying it will notify affected customers within 72 hours of confirming a notifiable breach. Both sentences are Lovable’s. Only one of them is in the contract.

Transfers are short. The agreement says transfers out of the European Economic Area run under the EU standard contractual clauses, Module Two where the customer is a controller and Module Three where the customer is itself a processor, and transfers out of the United Kingdom run under those clauses as amended by the UK addendum.

One mechanism has a price attached and no number. If you ask Lovable to help with a data protection impact assessment, section 4 says Lovable “shall be entitled to charge the Customer its professional services fees on a time and material basis for such assistance”. No figure for that appears anywhere on the page.

One more thing worth reading before you sign it. The agreement defines Lovable as “Lovable Labs Incorporated, registered at 1 Lincoln St, Boston, MA 02111”, while the data protection officer block at the top of the same page gives a contact address at Lovable Labs AB in Stockholm. Two entity names on one page is normal for a company with a European presence, and it is also the sort of detail a customer’s legal reviewer will ask you to explain, so have the answer ready rather than discovering the question.

Health records are one of the categories the agreement rules out by name. Section 3 says the customer “shall not provide any data to Lovable which is classified as sensitive”, and spells out that this means not uploading protected health information under HIPAA, or other sensitive categories such as financial account numbers, government identifiers or biometric data. Lovable’s privacy policy says the same thing in its own words on the same date. Whether health records can go into a Lovable app at all, and what the platform’s own pages say about the agreement one would need, is answered on its own page.

The other direction, where the customer is the one holding out an agreement for you to sign, is its own subject.

Where Lovable’s subprocessor list actually is

Lovable’s subprocessor list has four published addresses and no published list. The agreement points at lovable.dev/subprocessors, that page points at the trust centre, the trust centre returns no readable text to an automated read, and the security page says a current list is available on request.

Section 7 of the agreement sets the promise precisely. Lovable says it will inform the customer of intended additions or replacements “through updating the sub-processor list available at lovable.dev/subprocessors”, that the list “is updated at least annually”, that a customer who does not consent may object “within twenty (20) business days” by writing to a named privacy address, and that if the parties cannot agree, the customer’s “sole and exclusive remedy” is to terminate and receive a refund of prepaid fees. That is a real mechanism. It only works if you can read the list.

Each of those readings has a scope, and the scope is the point.

Read against the whole raw document on 3 September 2026, including its legal navigation and its site footer, the page at lovable.dev/subprocessors names no subprocessor. Its own header dates it Effective: January 14, 2026, and its entire body says that Lovable engages third-party subprocessors and that “the full list can be found in our Trust Center”.

As of 3 September 2026, Lovable’s trust centre returns no readable body text to an automated read: a plain request and a browser-shaped request both returned the same document, which carries a page title and a page description and loads everything else from script. That is a statement about two automated reads on one date, not a statement that the page is empty in a browser.

The security page answers its own FAQ question about subprocessors this way: “Lovable works with a limited set of infrastructure and AI subprocessors. All subprocessors are covered under contractual data protection agreements. A current list of subprocessors is available upon request.”

The privacy policy takes a fifth route. Its subprocessor section lists four categories of purpose rather than a roster, one of which names two companies as integrations, and it then says that “the current list of authorized sub-processors is available at https://trust.lovable.dev and includes the sub-processor’s name, location, and processing purpose”. It also gives a different objection window from the agreement, ten business days rather than twenty.

So the request you send is a written one, and it is worth sending early rather than at signature. Ask for the current list with each entry’s name, location and purpose, in the wording the privacy policy already uses, and ask which of the two objection windows applies to your plan.

The reason your customer wants names is that a vendor file is built from them. Article 30(1)(d) of the regulation asks a controller’s own record of processing to describe the categories of recipients that personal data has been or will be disclosed to, and a customer’s agreement is usually what turns those categories into company names. Your side of that record is separate work with its own pages: what a deletion request has to reach, the retention limit that applies to it, and what has to be inside a data export.

Where the data sits, and what choosing a region does not settle

Lovable’s security page named three regions on 3 September 2026, and a project’s region is settled when its backend is switched on rather than during a deal. Choosing one answers a question about location. It does not answer the transfer, contract and retention questions that sit on top of it.

The wording on Lovable’s security page that day, under its own Data residency heading, gave the supported hosting regions for Lovable Cloud as “the EU, US, and Asia Pacific”, and the sentence after it said a customer’s data stays in whichever of the three a project chose, with no movement between regions by default. Its FAQ repeats the same three regions in its own answer about storage.

The constraint underneath that sentence is that the choice is made once per project, so a customer contract naming a region cannot be satisfied later by changing a setting. The region is fixed when the built-in backend is switched on covers what the documentation says about that lock and what moving actually involves.

Two things a region does not settle. The agreement still governs transfers out of the European Economic Area and the United Kingdom through the standard contractual clauses named in its section 8, which is a separate question from where a database sits. And a region says nothing about how long you keep the data or what your own privacy notice promised about it.

If the customer’s real requirement is the app running on their infrastructure rather than in a named region, that is a different ask with a different answer, and what moving a Lovable app onto infrastructure you control involves treats it directly. Whether any of this is a reason to leave the platform at all is weighed in when to move off your AI builder.

The trust page Lovable can now publish for your app

There is one document on this list that is yours rather than Lovable’s, and it is new. Lovable’s product documentation for the Trust center, read on 3 September 2026, describes a security page for an externally published app, served at two addresses on the app’s own domain: a page for people at /.well-known/trust.html and a machine-readable file at /.well-known/trust.json.

It is off unless you turn it on. The documentation says the Trust center is disabled by default and is enabled in a project’s publishing settings by a project admin or owner, that it applies to the currently published version, and that disabling it takes both addresses offline again. The docs FAQ says it is available for externally published apps regardless of plan.

What it shows is grouped into four sets of checks, and your app only shows the ones Lovable can confirm for it: connection and browser security, deployment and runtime security, access control and authorization for apps using the built-in backend, and security scanning and remediation. The deployment set includes a software inventory in a standard format, and the same page says trust.json “discloses that an SBOM exists for the current deployment. The list itself is not publicly downloadable.”

The limits are written by Lovable, which is the most useful part of the page for anybody answering a buyer. The documentation says the Trust center “is not SOC 2, ISO 27001, a penetration test report, or a compliance attestation, and it doesn’t substitute for any of them”. It says only current positive facts appear, and that “a reviewer can’t tell from the Trust center alone whether an omitted check failed or was never evaluated”. It says the Trust center “is not a full security assessment of your app’s own code and logic”. Its FAQ answers the question directly, saying a customer who requires a formal certification such as SOC 2 still requires it. And the page is excluded from search engines, so it is shared by link rather than found.

Somebody in the corpus behind this blog, writing as a person who does not code, asked the question underneath all of this in one line: “As a non coder, is lovable security sufficient for my app?” Lovable’s own documentation answers that more honestly than any marketing page does, by listing what its page cannot tell a reviewer.

Two things worth keeping straight. Lovable’s corporate trust centre and your app’s trust page share almost the same name and are different objects: one is about Lovable’s own systems, and what a platform’s trust centre does and does not establish about one app’s access rules works through that from the incident side. And the connected penetration-test product Lovable’s security page and founder post both describe is a third-party service with its own bill and its own report, which belongs in the pen-test decision rather than in this list.

So the practical use of the trust page is narrow and real. Turning it on gives a reviewer something current, under your own domain, that you did not write about yourself, and it closes a handful of rows on a vendor form. It does not close the rows a report closes, and Lovable says so in writing.

The rows these documents never answer

The four documents answer questions about Lovable. Not one of them says anything about whether a customer of yours can read another customer’s rows, who still has production access to your project, or what your app records when a payment fails. That gap is the shape of the split rather than a criticism of the platform, and every vendor review eventually arrives at it.

The safety review takes the platform side of that boundary, and whether paying somebody to check the app is worth it is the decision on the other side. When the request arrives as a spreadsheet with a row for every one of these, the form itself has its own page. A customer who asks for the report usually asks for six other things in the same email, and the whole list is triaged elsewhere.

Common questions about Lovable’s compliance documents

Does Lovable have a data processing agreement, and who gets one?

Yes, and it is published in full at lovable.dev/data-processing-agreement. Its own opening line, read on 3 September 2026, says that if you are on a Business or Enterprise plan your usage includes the agreement and a signed version is available. The text is readable by anybody, so you can review every clause before deciding whether the plan is worth it.

How do I get Lovable’s SOC 2 report to send to a customer?

You ask for it, and the route is named on Lovable’s own pages. The March 2026 founder post says the report is available under NDA through your account manager, and the agreement’s security section says that upon request, approval and acceptance of confidentiality obligations, Lovable may provide access to the recent SOC 2 Type II and ISO 27001 reports. Send the request with a date, because a report under NDA is not a file you can pass on freely.

Where is Lovable’s subprocessor list?

Four Lovable pages point at it and none of them printed it on 3 September 2026. The agreement names lovable.dev/subprocessors, that page says the full list is in the trust centre, the trust centre returned no readable text to either a plain or a browser-shaped request that day, and the security page says a current list is available upon request. The privacy policy describes what the list contains, name, location and processing purpose, and points at the trust centre too.

Does signing Lovable’s agreement make my app compliant with the privacy regulation?

The agreement says what it covers and what it does not. It states that Lovable acts as processor for EU personal data with the customer as controller, that it does not establish joint controllership, and that each party remains responsible for its own compliance in respect of its separate processing. Article 28 of the regulation is written around that arrangement, and the obligations it leaves with a controller stay with a controller.

What is Service Data in Lovable’s agreement, and why does it matter?

Service Data is the agreement’s name for data about the use and operation of the service, and section 9 says Lovable processes it as an independent controller for its own purposes, including training or tuning proprietary machine-learning models used to deliver the services. The same section states that Service Data is not Customer Personal Data and that the agreement’s obligations do not apply to it, which is a different statement from the plan-level training answer on the security page.

Is the trust page Lovable publishes for my app a certification?

No, and Lovable’s documentation says so twice. It states that the Trust center is not SOC 2, ISO 27001, a penetration test report or a compliance attestation and does not substitute for any of them, and its FAQ adds that a customer who requires a formal certification such as SOC 2 still requires it. It reports checks Lovable ran or recorded for your current deployment.

Which Lovable plan do the compliance documents come with?

The agreement’s own first line ties a signed copy to the Business and Enterprise plans, and the founder post ties the report request to an account manager. Lovable publishes four plan names, Free, Pro, Business and Enterprise, and the readable text of its pricing page on 3 September 2026 carried no plan-by-plan comparison of compliance documents, so the agreement itself is the clearest published statement of which plan gets what.

Who is the controller and who is the processor for a Lovable app?

For EU personal data the agreement puts the customer in the controller role and Lovable in the processor role, with the equivalent split under the UK regulation and a business and service-provider pairing for US personal data. Your own users’ data flows through you first, so your customers’ agreements with you sit on top of this one rather than replacing it.