A GDPR Compliance Checklist for SaaS Startups

If your SaaS has a single user in the EU, GDPR already applies to you. Being incorporated in Delaware or London does not change that. Below is the actual work, in roughly the order a founder should do it, with the GDPR article behind each step so you can see why it is on the list rather than just that it is.

First, confirm GDPR applies to you

Article 3 sets the territorial scope. In plain terms: if you offer your service to people in the EU, or you monitor their behaviour (analytics, tracking, and profiling all count), the regulation applies even when your company and your servers sit outside the EU. Most SaaS products with any EU signups are in scope. If you are established outside the EU and clearly caught by this, Article 27 can also require you to appoint an EU representative, a contactable person or firm inside the EU who acts as a local point of contact. Sort that out early, because it changes what your privacy notice has to say.

Map the personal data you actually hold

You cannot protect or disclose what you have never written down. Article 30 requires a record of processing activities, usually called a ROPA: what data you hold, why, who it goes to, and how long you keep it. There is a narrow exemption for organisations under 250 staff, but it evaporates the moment your processing is regular or includes special-category data, which covers essentially every SaaS running customer accounts day to day. Treat the ROPA as mandatory. It is also the document that makes every later step faster, because your privacy notice, your vendor list, and your breach plan all read from it.

Pin a lawful basis to each purpose

Article 6 says every use of personal data needs one of six lawful bases, picked before you process rather than justified afterwards. For a typical SaaS: performance of a contract (Article 6(1)(b)) covers running the core service your customer signed up for; legitimate interests (Article 6(1)(f)) can cover security, fraud prevention, and basic product analytics, as long as you can show you weighed your interest against the user's; consent (Article 6(1)(a)) is what you need for marketing email and non-essential cookies. Resist the urge to label everything "consent." It is the hardest basis to obtain properly and the easiest to invalidate.

Write a privacy notice that matches what you do

Articles 13 and 14 list what a privacy notice must contain: your identity and contact details, the purposes and lawful basis for each use, who receives the data, any transfers outside the EU, retention periods, the rights available to users, and the right to complain to a supervisory authority. The error we see constantly is a notice copied from another company that describes processing the startup does not do and omits processing it does. A regulator reads your notice against your real systems, not against how polished it sounds.

Put a DPA in place with every processor

Article 28 requires a written data processing agreement with every vendor that handles personal data on your behalf: your cloud host, your email provider, your analytics tool, your payment processor, your support desk. Most large vendors publish a standard DPA you can accept in a few clicks. The obligation is on you to have actually accepted it and to keep the list of who is on it current. Each of those vendors is a processor, and their own subprocessors sit under the same contractual chain.

Handle transfers outside the EU

If any of those processors store or access data in the US or another non-EU country, Chapter V applies. For US vendors the two main routes are the EU–US Data Privacy Framework, if the vendor is certified under it, or Standard Contractual Clauses if it is not. The Framework is currently valid: the EU General Court upheld it in September 2025 in the Latombe case, though an appeal to the Court of Justice is pending, so this is an area to keep an eye on rather than treat as permanently closed. Note which of your subprocessors depend on it.

Secure the data and plan for a breach

Article 32 requires security measures appropriate to the risk: encryption, access controls, backups, and a tested way to restore. Articles 33 and 34 set the breach rules. You have 72 hours from becoming aware of a breach that risks people's rights to notify your supervisory authority, and you must tell affected users directly when the risk to them is high. Write the procedure before you need it. Who phones the regulator at 2am is not a question to answer for the first time at 2am.

Build the data subject rights process

Articles 15 to 22 give individuals rights over their data: access, correction, erasure, portability, and objection. You have one month to respond to a request. For a small SaaS this rarely needs dedicated software. It needs a named owner, a written process, and the practical ability to find, export, or delete one person's data across all your systems. That last part is where teams discover their data map had holes in it.

Want to see which of these you are missing before you start?