GDPR Compliance for SaaS: A Practical Guide for Founders

If you run a SaaS company with users in Europe, GDPR is not optional and it is not something to defer until a customer's security questionnaire forces the issue. The good news: the regulation is more navigable than its reputation suggests. Strip away the legalese and it comes down to a handful of disciplined habits — knowing what data you hold, having a defensible reason to hold it, letting people exercise their rights, and being honest when something goes wrong.

This guide is for the founder or early operator who needs to understand what GDPR actually asks of a SaaS business, without a law degree. It will not make you a Data Protection Officer. It will tell you where the real obligations are so you can prioritize.

First: does it even apply to you?

A common and expensive misconception is that GDPR only binds EU companies. Article 3 says otherwise. If your SaaS offers services to people in the EU or EEA, or monitors their behaviour — analytics, profiling, behavioural ads — the regulation reaches you wherever you are incorporated. A Delaware C-corp with a few hundred European trial users is in scope.

The practical test is not "where is my server" but "whose data am I processing and where are they." If the answer includes the EU, UK, or EEA, keep reading.

The six lawful bases, and why you can only pick one

Every time you process personal data, you need a lawful basis. Article 6(1) gives you six, and exactly one has to fit each purpose:

• Consent — freely given, specific, informed, and revocable. The right basis for marketing emails and non-essential analytics. The wrong basis for things you need to run the product, because consent can be withdrawn.
• Contract — necessary to deliver the service the user signed up for. This covers account creation, billing, and core functionality.
• Legal obligation — you are required by law to process it, such as retaining invoices for tax.
• Vital interests — to protect someone's life. Rare in SaaS.
• Public task — for official functions. Almost never relevant to a private SaaS.
• Legitimate interests — a flexible basis for things like fraud prevention and network security, but it requires a documented balancing test (a Legitimate Interests Assessment) weighing your interest against the user's rights.

The discipline that auditors look for is one basis per purpose, written down. "We process this because we feel like we should" is not a basis. Sending a newsletter under "contract" because consent is inconvenient is the kind of shortcut that turns into a finding.

A separate, stricter regime applies to special-category data under Article 9 — health, biometric, genetic, racial or ethnic origin, political opinions, religious beliefs, trade-union membership, and data about sex life or sexual orientation. You need a lawful basis under Article 6 and a specific condition under Article 9(2) before you touch it. If your product handles any of these, that is the part of your compliance work to get right first.

Data subject rights: the operational core

GDPR gives individuals a set of rights you must be able to honour on request. These are not abstract — they show up as emails from users, and an auditor will ask to see one and how you handled it.

The rights, with their Articles:

• Access (Article 15) — a copy of their data and details of how you use it.
• Rectification (Article 16) — correct inaccurate data.
• Erasure (Article 17) — delete it, subject to exceptions like legal retention.
• Restriction (Article 18) — pause processing while a dispute is resolved.
• Portability (Article 20) — receive their data in a machine-readable format.
• Objection (Article 21) — stop processing based on legitimate interests or for direct marketing.
• Rights related to automated decisions (Article 22) — not be subject to solely automated decisions with legal or similarly significant effects.

You have one month to respond, under Article 12(3), extendable by up to two further months for genuinely complex requests as long as you tell the person within the first month. The mistake teams make is having no process at all, so the first request triggers a scramble through three databases and a CSV export at 11pm. Build the workflow before you need it: how you verify identity, where the data lives, who owns the response.

Know your data: records and processors

Article 30 requires most organizations to maintain a Record of Processing Activities — a structured inventory of what you process, why, on what basis, who receives it, and how long you keep it. It is the single most-cited gap in GDPR audits, and it is also the foundation everything else rests on. You cannot honour an erasure request for data you didn't know you had.

If you use third-party vendors that handle personal data on your behalf — Stripe, AWS, a customer support tool, an email platform — those are processors, and Article 28 requires a written contract with specific clauses governing how they handle the data. You are responsible for the processors you choose. "Our vendor lost the data" is not a defence; selecting and overseeing them is your job.

International transfers after Schrems II

If personal data leaves the EEA — which it does the moment you use a US-hosted analytics tool — Chapter V applies. You need a transfer mechanism:

• An adequacy decision (Article 45), where the European Commission has ruled a country's protection is sufficient.
• Standard Contractual Clauses (Article 46), the most common route, which since the Schrems II ruling must be paired with a transfer impact assessment and, where needed, supplementary technical measures.
• A derogation (Article 49) for specific, limited situations.

For US vendors specifically, the EU-US Data Privacy Framework adequacy decision from July 2023 provides a route — but only for recipients actually certified under it. Check the certification rather than assuming.

When something breaks: the 72-hour rule

A personal data breach is not just a hack. It is any accidental or unlawful destruction, loss, alteration, or unauthorized disclosure of personal data — including an employee emailing a customer list to the wrong address.

Three obligations:

• Log every breach (Article 33(5)), notifiable or not.
• Notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, if the breach is likely to risk people's rights (Article 33(1)).
• Notify the affected individuals when the breach is likely to result in a high risk to them (Article 34).

Seventy-two hours is short. It is not enough time to build an incident process from scratch, which is the whole point of having one ready.

Where to start if you have nothing

If your SaaS is starting from zero, the order that gives you the most protection for the least effort:

1. Build a Record of Processing Activities. Everything else references it.
2. Assign a lawful basis to each activity and write down the reasoning.
3. Stand up a data subject request process — even a documented manual one beats none.
4. Put processor contracts in place and confirm your transfer mechanisms.
5. Write a breach response plan with the 72-hour clock in mind.

None of this requires a six-figure consulting engagement to begin. It requires honesty about what data you actually hold and a willingness to write it down. If you want a structured first pass — a draft RoPA, a DPIA screen, a privacy policy, and a gap list generated from a description of your business — the GDPR Audit Prep tool produces one in a few minutes, with each lawful basis tied to its Article. Treat it as the draft you hand to a reviewer, not the final word. For the foundational document specifically, see what a RoPA is and how to build one.

GDPR rewards the boring virtues: write it down, have a reason, tell the truth. Get those habits in place early and the audit becomes a review of work you've already done, rather than a deadline you're racing.