Which rules your product actually has to meet

Which rules apply depends on three things: where your users are, what you store about them, and who buys from you; privacy laws follow your users wherever your company is registered. Those include the EU GDPR, the UK GDPR and California's CCPA.

HIPAA follows health information handled for US health plans, clearinghouses and healthcare providers. PCI DSS follows payment card data. SOC 2 and ISO 27001 are not laws at all: larger customers ask for them. The EU AI Act adds duties when your product uses AI, from telling people they are dealing with a machine to strict rules for high-risk uses.

This page is an overview, checked against the regulators' and standards bodies' own pages on October 6, 2026, and listed under Sources.

Which rules apply to my app?

It depends on your users, your data and your buyers. Users in the EU or UK bring the GDPR, card data brings PCI DSS, health information handled for US health plans or providers brings HIPAA, and larger customers ask for SOC 2 or ISO 27001. Start with this table, then read the section for each rule it names.

What does the GDPR require?

The General Data Protection Regulation, Regulation (EU) 2016/679, is the EU's privacy law, and it requires a lawful basis for each use of personal data, clear notice, user rights, appropriate security, processor contracts and extra care with special categories such as health data.

Under Article 3 it also applies to companies outside the EU when they offer goods or services to people in the EU or monitor their behavior there. Personal data is any information about a person who can be identified: a name, an email address, an online identifier such as an IP address, or a record of what someone did in your app.

In practice, it asks for six things:

• A lawful basis for each use of personal data, such as a contract with the user or their consent (Article 6).
• Clear information about what you collect and why, usually in a privacy notice (Articles 13 and 14).
• Rights for each user: to see their data, correct it, delete it and take a copy with them (Articles 15 to 20).
• Security appropriate to the risk (Article 32), and a report to the regulator within 72 hours of a personal data breach where feasible, unless the breach is unlikely to put people at risk (Article 33).
• A written contract with every processor that handles personal data for you, such as your database, email and AI providers (Article 28).
• Extra care with special categories of data, such as health data (Article 9).

Fines for the most serious breaches can reach €20 million or 4% of worldwide annual turnover, whichever is higher (Article 83). A company with no office in the EU may also need to appoint a representative there (Article 27).

Is the UK GDPR different?

Only a little, mostly in where it applies and who enforces it. The UK kept the GDPR in its own law as the UK GDPR, which sits alongside the Data Protection Act 2018, and the Information Commissioner's Office (ICO) enforces both.

The Data (Use and Access) Act 2025 amends, but does not replace, the UK GDPR and the 2018 Act, and the ICO says all of its data protection provisions are now in force. If you have users in both the UK and the EU, plan to meet both, and use the ICO's guidance for where the UK rules now differ.

Does California's CCPA apply to a startup?

Often not yet. California's Attorney General says the California Consumer Privacy Act applies to for-profit businesses that do business in California and meet any one of three tests: gross annual revenue over $25 million; buying, selling or sharing the personal information of 100,000 or more California residents or households; or earning 50% or more of annual revenue from selling it.

The California Privacy Protection Agency publishes the current monetary thresholds.

Where it applies, California residents can ask to know what you collect about them, to delete it, to correct it, to opt out of its sale or sharing, and to limit the use of sensitive personal information, and you may not penalize them for asking. The CPRA, which California voters approved in 2020, added the rights to correct and to limit from January 1, 2023. The Agency's current regulations took effect on January 1, 2026.

When does HIPAA apply to a health app?

Less often than founders expect, and strictly when it does. HIPAA's rules apply to covered entities, which the regulations define as health plans, health care clearinghouses, and health care providers that transmit health information electronically in connection with the transactions the rules cover.

They also apply to business associates: companies that create, receive, maintain or transmit protected health information on a covered entity's behalf.

If a clinic or an insurer uses your software to handle patient data, you are probably a business associate, and the rules require a business associate agreement (BAA) between you. A consumer wellness app that people use on their own may sit outside HIPAA, but in the US it can still be covered by the Federal Trade Commission's Health Breach Notification Rule.

The HIPAA Security Rule asks for safeguards including access control, audit controls that record activity, protection against improper changes to data, verification of who is signing in, and security for data in transit. It marks encryption as addressable, which means you must use it where it is reasonable and appropriate, or document why not and use an equivalent measure. Every vendor that handles protected health information for you needs a business associate agreement.

If your app runs on Lovable, our guide to whether Lovable is HIPAA compliant covers what this means for Lovable Cloud and for your own Supabase project.

For a Lovable app, this is decisive. Lovable's documentation says it is not HIPAA-compliant and does not sign business associate agreements, and that its standard terms do not allow protected health information in the apps you build; for regulated data, it says to contact its sales team before you build. Supabase does sign BAAs. Its documentation says an organization handling protected health information needs both a signed BAA and its HIPAA add-on, with point-in-time recovery, SSL enforcement, network restrictions and connection logging switched on. So protected health information cannot live in Lovable Cloud. It needs a backend covered by a signed BAA, and a lawyer's review of every other vendor it passes through.

Does PCI DSS apply if I use Stripe?

Yes, but lightly if card numbers never touch your app. The PCI Security Standards Council says PCI DSS applies to entities that store, process or transmit the data on payment cards, including merchants. Stripe's integration security guide says a business accepting payments must do so in a PCI-compliant manner and attest to that every year.

It also says its low-risk integrations send payment details straight to Stripe without passing through your servers, which reduces your PCI obligations. A business that handles card numbers itself, Stripe warns, may have to meet more than 300 security controls.

So in a Lovable app, collect payments through a Stripe-hosted integration such as Checkout, and never put card numbers in your own forms or your own database. Lovable's standard terms do not allow payment card data in the apps built on it anyway. Our Lovable Stripe integration guide covers the rest of a safe payment setup.

Do I need SOC 2 or ISO 27001?

Not by law. Both describe how your company manages security, and customers ask for them. A SOC 2 report, under standards set by the AICPA, covers an examination of a service organization's controls relevant to security, availability, processing integrity, confidentiality or privacy.

ISO/IEC 27001:2022 sets out the requirements for establishing, implementing, maintaining and continually improving an information security management system, and companies can be certified against it. Our glossary entry on SOC 2 explains the difference between a Type 1 and a Type 2 report.

Your vendors' certificates do not transfer to you. Supabase has a SOC 2 Type 2 report, and Lovable says it holds SOC 2 Type II and ISO 27001:2022 certifications. But Supabase's documentation says its SOC 2 compliance does not extend outside its product, and that a customer who needs to be SOC 2 compliant must implement the controls itself and undergo its own audit. Your vendors' reports are evidence for your own vendor review, not a substitute for it.

You rarely need either to launch. The time to start is usually when a larger customer's security questionnaire arrives. Being ready for it is mostly ordinary engineering done early: access control, an audit log, reviewed changes and tested backups.

What does the EU AI Act mean for an app with AI features?

For a typical startup feature, the AI Act means transparency rules, such as telling people they are dealing with a machine, while high-risk uses face strict rules. The EU AI Act, Regulation (EU) 2024/1689, sorts AI systems by risk. It entered into force on August 1, 2024, and has applied generally since August 2, 2026, with exceptions.

Most of its bans on unacceptable practices, such as social scoring, and its AI literacy duties have applied since February 2, 2025, and the rules for general-purpose AI models since August 2, 2025. Under an amendment known as the AI Omnibus, which entered into force on July 27, 2026, the rules for high-risk uses in sensitive areas apply from December 2, 2027, and those for AI built into regulated products from August 2, 2028.

Like the GDPR, it can reach companies outside the EU: it covers AI systems placed on the EU market, and in some cases systems whose output is used in the EU (Article 2). For a typical startup feature, the transparency rules are the ones to know. The European Commission's own example is a chatbot: people should be told they are interacting with a machine. Providers of generative AI must also make AI-generated content identifiable, and deepfakes and AI-written text published to inform the public on matters of public interest must be clearly labeled.

The high-risk list is specific. It includes, among others, CV-sorting software for recruitment, scoring exams in education, and credit scoring that can deny someone a loan. If your product does anything like that, get legal advice before you build it.

An AI feature also brings the GDPR with it. If it sends personal data to a model provider, that provider usually acts as your processor, so you need its data processing terms and a mention in your privacy notice. Lovable says Enterprise workspaces can keep AI requests on EU endpoints. Our guide to the Lovable OpenAI integration covers keeping keys and other users' data out of an AI feature.

How do these rules apply to a Lovable and Supabase app?

They come down to where data lives, signed processor contracts, row-level security, an audit log, real deletion and export, Stripe-hosted payments, no protected health information in Lovable, secrets on the server and a written record. Most of the work is the same whichever rule applies, and most of it is decided early, in how data and permissions are built:

• Choose where data lives before you build. Lovable Cloud offers Americas, Europe and Asia Pacific regions, and Lovable's documentation says the region cannot be changed once Cloud is enabled. On your own Supabase project, the region you choose decides where its primary data is stored. Supabase advises a specific region rather than a general grouping when data must stay in one jurisdiction, and says region selection is not proof of compliance.
• Sign the processor contracts. Lovable and Supabase both publish a data processing agreement. Do the same for every other service that receives personal data, such as email, payments and AI, and keep the list current.
• Enforce access in the database. Turn on row-level security for every table and test it with two accounts, so one user can never read another's data. HIPAA names access control outright, and privacy laws expect it as part of appropriate security.
• Record who did what. HIPAA's Security Rule requires audit controls that record activity in systems holding health data, and an audit log of sign-ins, admin actions and data exports is the evidence you will want after any incident.
• Make deletion and export real. A request to delete or download someone's data has to reach every table and every service that holds it, including file storage and your email provider.
• Keep card data and health data out unless the whole path allows them. Use Stripe-hosted payments, and keep protected health information out of Lovable entirely.
• Keep secrets on the server. API keys belong in server-side secrets, never in the browser.
• Write it down. A privacy notice, a list of the services that receive personal data, and a short record of what you hold and why answer the first questions a customer or a regulator will ask.

When should you talk to a lawyer?

Before you launch in a regulated area, and whenever one of these is true: you handle health, financial or children's data; you sell to hospitals, banks or governments; your AI feature makes decisions about people, such as hiring or credit; or a customer sends a contract with a data processing agreement or a security schedule attached.

This page tells you which questions to ask. A lawyer who knows your product and your markets tells you the answers.

For the security side of a Lovable app, work through our Lovable security checklist. To see where your app stands overall, take the free production-readiness check. If your AI-built app is already misbehaving, our vibe coding rescue starts with an architecture review of what exists, then fixes what is risky, such as access rules and secrets.

Sources

All checked on October 6, 2026.

• European Union: Regulation (EU) 2016/679, the General Data Protection Regulation, Articles 3, 6, 9, 13 to 20, 27, 28, 32, 33 and 83 (eur-lex.europa.eu/eli/reg/2016/679/oj).
• Information Commissioner's Office: UK GDPR guidance and resources (ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/).
• Information Commissioner's Office: The Data (Use and Access) Act 2025, what it means for organizations (ico.org.uk/about-the-ico/what-we-do/legislation-we-cover/data-use-and-access-act-2025/the-data-use-and-access-act-2025-what-does-it-mean-for-organisations/).
• UK legislation: Data Protection Act 2018 (www.legislation.gov.uk/ukpga/2018/12/contents).
• State of California, Department of Justice: California Consumer Privacy Act, who it applies to and consumers' rights (oag.ca.gov/privacy/ccpa).
• California Privacy Protection Agency: Laws and regulations, monetary thresholds and the regulations effective January 1, 2026 (cppa.ca.gov/regulations/).
• Electronic Code of Federal Regulations: 45 CFR 160.103, definitions of covered entity and business associate (www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103).
• Electronic Code of Federal Regulations: 45 CFR Part 164, Subpart C, the HIPAA Security Rule, including addressable specifications and business associate contracts (www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C).
• Federal Trade Commission: Health Breach Notification Rule (www.ftc.gov/legal-library/browse/rules/health-breach-notification-rule).
• PCI Security Standards Council: PCI DSS, who it applies to (www.pcisecuritystandards.org/standards/pci-dss/).
• Stripe documentation: Integration security guide, annual attestation and low-risk integrations (docs.stripe.com/security/guide).
• AICPA & CIMA: System and Organization Controls (SOC) suite of services, listing its SOC 2 guide on reporting on an examination of controls at a service organization relevant to security, availability, processing integrity, confidentiality or privacy (www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services).
• ISO/IEC 27001:2022, Information security management systems: Requirements, as listed by the IEC (webstore.iec.ch/en/publication/79694).
• European Commission: AI Act, the regulatory framework for AI, last updated August 3, 2026, on risk levels, the timeline and the AI Omnibus (digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai).
• European Union: Regulation (EU) 2024/1689, the Artificial Intelligence Act, Article 2 on scope (eur-lex.europa.eu/eli/reg/2024/1689/oj).
• Lovable documentation: FAQ, on HIPAA, business associate agreements, certifications, the data processing agreement and data its terms do not allow (docs.lovable.dev/introduction/faq).
• Lovable documentation: Lovable for Enterprise, on EU inference (docs.lovable.dev/introduction/lovable-for-enterprise).
• Lovable documentation: Lovable Cloud, on region selection (docs.lovable.dev/features/cloud).
• Supabase documentation: HIPAA projects, on the BAA, the HIPAA add-on and the required settings (supabase.com/docs/guides/platform/hipaa-projects).
• Supabase documentation: SOC 2 compliance, on its report and the shared responsibility (supabase.com/docs/guides/security/soc-2-compliance).
• Supabase documentation: Available regions, on data residency (supabase.com/docs/guides/platform/regions).
• Supabase: Data Processing Addendum (supabase.com/legal/customer-resources/data-processing-addendum).

This page is an overview, not legal advice: ask a lawyer which rules apply to your product.