You've been told you need to be GDPR compliant. Here's what that actually means for a SaaS founder — the business obligations, the legal requirements, and the five things that cover 80% of what you need to do.
At some point, someone told you your SaaS needed to be "GDPR compliant." Maybe it was a European customer during due diligence. Maybe it was a lawyer. Maybe it was an investor who'd seen a portfolio company get fined.
The phrase is accurate — GDPR does apply to most SaaS products with European users — but it's not very useful by itself. "GDPR compliant" is a destination, not an instruction. This guide gives you the instructions: what GDPR actually requires of you as a founder, what the most common gaps are, and what you can do in a week that covers most of it.
If you're looking for the technical implementation — what your engineers need to build — there's a separate guide at /guides/gdpr-compliant-saas-technical-guide. This one is for you.
Almost certainly yes, if you have any European users.
GDPR's territorial scope (Article 3) applies to any organisation that:
The "monitoring" clause is broader than most founders realize. If your product uses analytics to track user behaviour, and any of those users are in Europe, GDPR applies. If your public website has tracking pixels and European visitors land on it, that's covered.
The short version: if you have European users, GDPR applies to you. Country of incorporation is irrelevant.
Under GDPR, you cannot process personal data unless you have a "lawful basis" for doing so. There are six:
| Lawful basis | When it applies |
|---|---|
| Consent | The user has explicitly agreed to a specific use of their data |
| Contract | Processing is necessary to perform a contract with the user |
| Legal obligation | You're required to process data by law |
| Vital interests | Necessary to protect someone's life (narrow, rarely applicable) |
| Public task | For public authorities (doesn't apply to most SaaS) |
| Legitimate interests | Your interest in processing outweighs the user's privacy interests |
For most SaaS companies, the primary lawful basis is contract necessity — you need a user's email address to give them access to the product. You need their payment details to process their subscription. These are clearly necessary to fulfill the contract.
Legitimate interests is the second most-used basis for SaaS. You can rely on it for things like fraud prevention, security monitoring, or internal analytics — activities where your interest is real and doesn't override the user's rights. In October 2024, the European Data Protection Board published updated guidelines on legitimate interest that clarified how this basis should be applied. The key requirement: the interest must be clearly articulated, necessary, and balanced against the user's rights in a documented assessment.
Consent is often overused. Founders reach for consent because it feels safe, but GDPR consent has strict requirements — it must be freely given, specific, informed, unambiguous, and withdrawable at any time. If someone can't use your product without consenting, the consent isn't "freely given." Most core product functionality should be justified by contract necessity, not consent. Consent is appropriate for marketing emails, optional analytics, and tracking technologies.
The practical consequence: identify the lawful basis for each type of data you collect before you collect it. Document it. This is what regulators ask for when they investigate.
A Data Processing Agreement (DPA) is a contract between you (the data controller) and a vendor who processes personal data on your behalf (a data processor). GDPR Article 28 makes them mandatory.
If a vendor receives, stores, or processes your users' personal data — they need a DPA with you.
Here's what that looks like in practice:
| Vendor type | Examples | DPA required? |
|---|---|---|
| Cloud hosting | AWS, GCP, Azure | Yes |
| Payment processing | Stripe, Paddle | Yes |
| Customer support | Intercom, Zendesk | Yes |
| Email / marketing | Mailchimp, Sendgrid, Hubspot | Yes |
| Analytics | Mixpanel, Amplitude, Google Analytics | Yes |
| Error tracking | Sentry, Datadog | Yes |
| CRM | Salesforce, Pipedrive | Yes |
The good news: most major SaaS vendors have standard DPAs you can sign, often through their self-serve portals. AWS has a DPA available through AWS Artifact. Stripe's DPA is part of their standard terms. Intercom, Hubspot, Sendgrid — all have them.
The bad news: most early-stage startups haven't signed them. Signing your vendors' DPAs is one of the highest-leverage compliance actions you can take in an afternoon.
One nuance: a DPA doesn't make all data transfers to a third country (like the US) automatically lawful. For transfers outside the EU/EEA, you also need a separate legal mechanism — typically Standard Contractual Clauses (SCCs), which most major US vendors now include in their DPAs automatically.
Most privacy policies are boilerplate. They satisfy the visual check — "yes, we have one" — without satisfying the legal requirements.
GDPR Articles 13 and 14 specify what a privacy policy must include when you collect personal data directly from users:
Common things that boilerplate misses: named third-party processors (rather than generic categories), specific retention periods per data type, and the right to lodge a complaint with a regulator.
The test: can a non-technical European user read your privacy policy and understand exactly what you do with their data, why, and how long you keep it? If not, it needs work.
Cookie consent is where most SaaS companies are actively non-compliant — not because they haven't tried, but because the implementation is wrong.
In January 2023, the EDPB published guidelines on cookie banners that clarified what's required. European regulators — particularly France's CNIL — have been actively enforcing these, fining companies including TikTok (€5 million) and Yahoo (€10 million) for consent failures.
What non-compliant looks like:
What compliant looks like:
The technical implementation matters. Many cookie consent tools claim GDPR compliance while implementing patterns regulators have specifically flagged as violations. Check what your tool actually does, not just what it claims.
One note on analytics: if you're using Google Analytics with default settings, you're almost certainly loading tracking before consent on EU visits. This has been specifically called out by multiple EU data protection authorities.
A Data Subject Access Request (DSAR) is a right every EU user has: they can ask you, at any time, to tell them all the personal data you hold about them, how you use it, who you share it with, and how long you keep it.
You have 30 days to respond. The response must be provided in a commonly used electronic format. You cannot charge a fee for a standard request.
The challenge for startups is the operational side. Do you know, right now, how to pull together all the data you hold on a single user? That means your primary database, your analytics platform, your support tool, your email list, your CRM, your logs. All of it. Within 30 days.
Most startups don't have this process. It's usually a scramble. And regulators have been specifically active in enforcing DSAR compliance — the UK ICO alone has issued enforcement notices to companies for failing to respond properly.
Build the process before you get a request. It doesn't need to be automated initially — a documented manual procedure is fine for small volumes. But you need to know where all your user data lives.
The GDPR right to erasure (Article 17) — also called the "right to be forgotten" — allows users to request that you delete their personal data in certain circumstances.
This is not a simple database delete. The engineering problem is that user data typically lives in many places: your primary database, your backups, your email provider's list, your analytics platform, your support ticketing system, your CRM, your error tracking logs. A complete erasure requires coordinating deletion across all of these, including your third-party processors.
The right is not absolute — you can retain data you're legally required to keep (financial records for tax purposes, for example) and data necessary to establish or defend legal claims. But the default is deletion.
The practical recommendation: implement a soft-delete pattern in your primary database that marks users as deleted and strips personal data while retaining anonymised records for analytics. Maintain a documented process for cascading the deletion request to your third-party processors. This is an engineering task, and doing it right takes some thought. The technical GDPR guide covers the implementation in more detail.
Most startups don't need a dedicated DPO. GDPR requires a DPO if you:
"Large scale" is intentionally undefined, but the EDPB guidance suggests it means something like a hospital processing patient records, not a 20-person SaaS company processing customer emails. A DPO is not required for typical B2B or B2C SaaS products unless health or biometric data is a core part of what you do.
What you do need is a clear internal point of contact for privacy matters — someone whose job it is to respond to DSARs, manage DPA signing, and handle privacy questions from customers. This doesn't have to be a dedicated hire; it's often the CEO, COO, or a product manager. What matters is that someone owns it.
GDPR fines scale with company size. In 2023, Meta received a €1.2 billion fine for unlawful EU-US data transfers. Amazon received €746 million in 2021. These numbers make GDPR sound like an existential risk.
The reality for startups: supervisory authorities regularly issue five and six-figure fines to small and medium-sized businesses, but they also prioritize cases with the most users affected and the most egregious violations. A startup with 5,000 European users that has a good-faith privacy policy but hasn't quite gotten the cookie consent right is not the same risk profile as Meta deliberately ignoring transfer restrictions.
That said, DSAR non-compliance, failure to notify after a breach, and having no privacy policy at all are areas where small companies do get enforcement action. The risk is not zero; it's proportionate.
Sign your vendor DPAs. Go through every vendor that processes your users' data and sign their DPA. AWS Artifact, Stripe's terms, Intercom's settings. This takes a few hours and closes a major gap.
Update your privacy policy to include named third-party processors, specific retention periods, and your users' rights clearly stated. If you're using boilerplate, it almost certainly doesn't meet these requirements.
Fix your cookie consent implementation. Make sure tracking doesn't fire before consent, and that rejecting is as easy as accepting. Test it yourself in an incognito window.
Document your lawful bases. Create a simple internal document — a spreadsheet is fine — mapping each type of data you collect to its lawful basis. This is your answer if a regulator ever asks.
Create a DSAR process. Write down where all your user data lives and how you'd pull it together if someone requested it. Test it by running a mock DSAR for a test account.
None of these are engineering projects. They're administrative tasks. They don't make you perfectly compliant, but they address the most common enforcement areas and demonstrate good-faith effort — which matters in how regulators approach any investigation.
Hunchbite audits SaaS products for GDPR gaps, data handling issues, and compliance blind spots — giving you a clear, prioritised list of what needs to change.
Call +91 90358 61690 · Book a free call · Contact form
If this guide resonated with your situation, let's talk. We offer a free 30-minute discovery call — no pitch, just honest advice on your specific project.
A practical guide for non-technical founders on how to split equity with a technical co-founder — what factors should drive the number, what vesting protects you both, and how to have the conversation before it becomes a crisis.
11 min readChoosing a PartnerAn honest comparison of fixed-price and hourly billing for software development — when each model makes sense, the hidden risks of both, and how to structure an engagement that protects you.
10 min read