The EU privacy regulation that applies whenever an EU resident touches your product — and the practical 6-step path a solo founder can actually finish in a weekend.
Methodology and disclaimer. This is an educational summary of GDPR concepts for solo SaaS founders. It is NOT legal advice. Consult a privacy attorney for compliance decisions specific to your business. Citations point to the official regulation text at gdpr-info.eu and the EU’s legal database at eur-lex.europa.eu.
The General Data Protection Regulation came into force on May 25, 2018, replacing a patchwork of national privacy laws with a single regulation that has direct legal effect in every EU member state. The headline penalty cap is up to €20 million or 4% of worldwide annual turnover, whichever is higher (Article 83). That number is rarely applied to small operators, but GDPR is taken seriously by data-protection authorities and by the enterprise customers who will eventually want to buy your product.
The most common mistake is geographic. Founders assume that because their company is registered in Delaware, their servers are in Virginia, and their target market is North America, GDPR is somebody else’s problem. That is not how the regulation reads. Article 3 (full text at gdpr-info.eu/art-3-gdpr) applies the regulation to any organization that processes personal data of people located in the EU when offering goods or services to them, even with no physical presence in the EU.
If you run a public signup form, accept payments from European IP addresses, or have an analytics tag that records EU visitors, you are within scope. The signup is “offering services.” The analytics tag is “monitoring behavior.” For a typical solo SaaS shipping a public web app, GDPR applies on day one.
The second mistake is severity. The real risk surface for solo operators is not regulator-imposed fines — it is lost enterprise deals. A mid-market European customer cannot legally sign your contract if you cannot produce a Data Processing Agreement, a list of subprocessors, and reasonable evidence that you have a privacy program. The cost of non-compliance is the deal you cannot close, not the regulator’s letter you might never receive.
The GDPR text is 99 articles long. The good news for founders is that compliance hinges on five concepts. Once you can speak about each fluently, the operational checklist makes sense.
Article 4(1) defines personal data as any information relating to an identified or identifiable natural person. The definition is deliberately broad and significantly wider than most US privacy frameworks. An email address is personal data. So is an IP address (the European Court of Justice settled this in Breyer, Case C-582/14). So is a user-agent string combined with a timestamp and a coarse geographic region. The safer engineering default: treat everything your product logs about a user as personal data unless you can prove otherwise.
Article 6 says you may only process personal data if you have a lawful basis. There are six; for solo SaaS, three do almost all the work:
You pick a lawful basis per processing activity, not per company. Account storage is contract; the monthly newsletter is consent; PostHog session replays may be legitimate interest or consent depending on configuration. The privacy policy is where you tell users which basis applies where.
Articles 15–22 give EU residents rights over their data. The four solo founders must plan for:
The controller decides why and how data is processed; the processor handles data on the controller’s behalf. Your SaaS is a controller for your own users and a processor for your B2B customers’ end users. Most B2B SaaS is both at once.
This matters because Article 28 requires a written Data Processing Agreement (DPA) between every controller and every processor. You sign your subprocessors’ DPAs (Stripe, Vercel, Supabase, PostHog, Resend); your enterprise customers ask you to sign theirs. The chain of DPAs is what makes the flow legal.
Chapter V (Articles 44–50) restricts transfers of personal data outside the EU/EEA. The Standard Contractual Clauses (SCCs) — pre-approved contract language published by the European Commission — are the mechanism most US-based SaaS rely on. The Court of Justice’s Schrems II ruling (Case C-311/18, 2020) invalidated Privacy Shield and confirmed SCCs require a transfer impact assessment. The 2023 EU–US Data Privacy Framework provides an adequacy basis for certified US importers, but most founders still attach SCCs because adequacy decisions can be challenged. The European Data Protection Board’s guidance at edpb.europa.eu is the canonical reference.
If you ship a generic web SaaS, the following flows almost certainly process personal data and fall under GDPR:
Compliance is a continuous program, not a checkbox, but solo founders need a starting line. The following six steps cover what most small SaaS need to defensibly answer “yes, we have a GDPR program” on a vendor-security questionnaire.
Open a spreadsheet. List every place personal data enters your system (signup form, billing webhook, support widget). For each, capture the fields collected, lawful basis, destination (database, third party), and retention period. This is your Article 30 record of processing activities and the source-of-truth for everything that follows. Budget two to four hours.
Article 13 lists what the policy must contain: controller identity and contact, purposes and lawful basis, recipients, retention periods, data subject rights, and how to lodge a complaint with a supervisory authority. Write it in plain language at a reading level a typical user understands (Recital 39). Termly and Iubenda generate a defensible base policy for under $20/month; fact-check the output against your actual data flows.
A banner that says “by using this site you agree to cookies” is not GDPR consent. The EDPB’s Guidelines 05/2020 on consent require opt-in, granular by purpose, and as easy to withdraw as to give. The page must load with non-essential cookies off, present a meaningful choice (accept all / reject all / customize), and remember it. Cookiebot, Iubenda, and Termly all ship drop-in widgets for $10–$30/month; OneTrust is the enterprise option.
For a typical Next.js SaaS the subprocessor list is roughly: Stripe, Vercel, Supabase, PostHog, Resend or Postmark, Sentry, and Intercom or Crisp. All publish DPAs you can sign with one click — Stripe’s is at stripe.com/legal/dpa; the others are similarly accessible. Save signed copies. When an enterprise customer asks “who are your subprocessors?” you want to answer in five minutes, not five days.
Articles 15, 17, and 20 turn into code: two settings-page actions for the user. “Export my data” returns a JSON or CSV bundle. “Delete my account” removes the user row, anonymizes content where legal-obligation retention applies, and triggers cascading deletes in subprocessors. PostHog and Stripe both expose user-deletion APIs for this. Build the endpoints once; trying to handle requests by hand at scale is the path to founder regret.
Article 37 requires a Data Protection Officer in narrow circumstances — public authorities, large-scale monitoring, special-category data (health, biometrics, political opinions). Most solo SaaS do not meet the threshold. What you do need is a monitored contact for privacy inquiries listed in your privacy policy. privacy@yourdomain.com with a forwarding rule is sufficient. If you sell to EU public sector or process health data, get an attorney-led DPO assessment.
Once you have signed DPAs, publish your subprocessor list at a stable URL such as /subprocessors. The list should include the vendor name, the service they provide, the location of processing (US, EU, etc.), and a link to their DPA. This page does double duty: it satisfies the transparency requirement of Article 28(2), and it is the single page enterprise procurement teams will ask you for during a security review. A typical list for a Next.js SaaS looks like Stripe (payments, US), Vercel (hosting, global), Supabase (database, EU/US selectable), PostHog (analytics, US or EU Cloud), Resend (transactional email, US), Sentry (error tracking, US), and Cloudflare (CDN, global). Update the list whenever you add or remove a vendor and notify customers in advance per the contractual notice period.
If your hosting and processors are in the United States — the default for almost every Next.js SaaS — you are sending EU personal data to the US. Even with the 2023 EU–US Data Privacy Framework adequacy decision, the conservative posture is to attach SCCs to every processor relationship and document a transfer impact assessment. Most reputable subprocessor DPAs incorporate the SCCs by reference, so the work is confirming each DPA includes them and saving the signed copy. The European Commission publishes the current SCC text at commission.europa.eu; the EDPB’s Recommendations 01/2020 explain the transfer-impact-assessment requirement.
If your product is consumer SaaS with no enterprise sales motion, the six-step path plus a templated privacy policy from Termly or Iubenda is a defensible starting position. Apply public templates carefully, fact-check them against your actual data flows, and keep your subprocessor list current.
The moment you start receiving DPAs, SCC requests, or vendor security questionnaires from enterprise prospects, the calculus changes. Engaging a privacy attorney for a few hours to review your DPA terms and transfer mechanism is worth the cost — the alternative is signing terms you do not understand on deals that will be material to your business. Boutique privacy firms typically charge $300–$500/hour and can do a one-time review for under $5,000. If you are processing health data, children’s data, or any special category under Article 9, get an attorney from day one.
Termly, Iubenda, and PrivacyPolicies.com generate base policies and cookie banners under $30/month. Cookiebot is the strongest dedicated cookie-consent platform; OneTrust and TrustArc serve enterprise. Vanta and Drata are positioned as SOC 2 platforms but include GDPR program tooling, useful if you are pursuing both frameworks together. Plausible and Fathom are GDPR-friendly analytics that may eliminate the need for cookie consent entirely if they are the only tracking on your site.
GDPR compliance for solo SaaS is not the regulatory monster the headline fines suggest, but it is not optional. The minimum viable path is finite and finishable in a focused weekend: audit your data flows, write an honest privacy policy, add real cookie consent, sign your subprocessor DPAs, build deletion and export endpoints, and designate a contact. Doing this work earns you the regulatory baseline and the ability to close enterprise deals six months later when a procurement form lands in your inbox. Related work is covered in our SOC 2 explainer and our privacy policy. For the architectural pieces, see our breakdowns of multi-tenancy, the best payment processor for SaaS, and merchant of record.
The stack, prompts, pricing, and mistakes to avoid — for solo founders building with AI.