GDPR hits SaaS companies differently. You're not just a website — you're a data processor for your customers and a data controller for yourself at the same time. Here's what that actually means and what you need to do about it.
Why GDPR Is More Complex for SaaS Than for a Content Site
If you run a blog or a marketing website, GDPR is about one thing: what you collect from your own visitors. Cookie banners, privacy policies, analytics consent. It's a real compliance burden, but it's relatively contained.
If you run a SaaS company, you have all of that — plus an entirely different layer on top of it.
When your customers use your product, they upload data, create records, and interact with features that process personal information about their own users. That data passes through your infrastructure. Which means you're not just responsible for your own data collection practices — you're responsible for how you handle your customers' data on their behalf.
This creates two distinct compliance obligations that many SaaS founders conflate or ignore entirely:
You are a data controller for data you collect directly — your marketing site visitors, trial signups, newsletter subscribers, account holders.
You are a data processor for data your customers bring into your product — the end-user records, contact lists, employee data, and whatever else flows through your platform.
Both roles carry GDPR obligations. Both carry liability. And the rules for each are meaningfully different. Most SaaS founders have done some work on the controller side (they have a privacy policy, maybe a cookie banner) and almost nothing on the processor side.
That's the gap this guide is designed to close.
The Controller vs. Processor Distinction — What It Means in Practice
The controller decides why personal data is collected and how it's used. If you collect email addresses for your newsletter, you're the controller of that data. You decide the purpose, the retention period, the processing. GDPR's user rights obligations — access requests, deletion requests, corrections — run to the controller.
The processor handles personal data on behalf of a controller, following the controller's instructions. When your customer uploads their user base into your analytics tool, your CRM, your support platform — you're the processor. The customer is the controller. They decide what happens to that data. You execute.
In practice, this means:
Your customers — especially B2B customers — are the data controllers for the personal data they store in your product. They have compliance obligations to their own users. When they sign up for your SaaS, they're asking you to process that data on their behalf. Under GDPR Article 28, they are required to have a written agreement with you that governs that processing.
That agreement is called a Data Processing Agreement. And if you don't have one ready, you're blocking enterprise deals before they even start.
Data Processing Agreements (DPAs) — What They Are and Why You Need One
A Data Processing Agreement is a legally binding contract between a data controller (your customer) and a data processor (you) that specifies how personal data will be handled. GDPR Article 28 makes them mandatory. Without a DPA in place, your customer is technically out of compliance for using your product.
What a DPA must contain:
- The subject matter, duration, nature, and purpose of the processing
- The type of personal data being processed and categories of data subjects
- Your obligations and rights as a processor
- A requirement that you only process data on documented instructions from the controller
- Confidentiality requirements for anyone who processes the data
- Appropriate security measures (Article 32)
- Your sub-processor obligations (more on this below)
- Data subject rights assistance — you must help controllers fulfill access and deletion requests
- What happens to the data after the contract ends (deletion or return)
- Audit rights for the controller
The enterprise sales reality: Any customer with a legal team — and increasingly, mid-market customers who've been through procurement processes before — will send you a DPA to sign before closing. If you don't have your own template, you'll sign theirs. Their template will have unfavorable terms. Experienced founders publish their own DPA and make it the starting point.
Getting a DPA template right requires a real legal resource — a privacy lawyer or a specialized firm. This is one place where cutting corners is genuinely risky. The investment in a solid DPA template pays for itself the first time an enterprise customer asks for it and you can turn it around in hours instead of weeks.
Sub-Processors — Every Tool You Use Is On the Hook
When you process customer data, you almost certainly use third-party services to do it. Your hosting provider stores the data. Your monitoring service sees stack traces that may contain personal data. Your support tool logs conversations with customer information. Every one of these is a sub-processor.
GDPR Article 28(2) requires that before you engage a sub-processor, you have either general written authorization from your controller customers (set in your DPA) or specific written authorization for each one.
In practice, what this means:
- Maintain a published sub-processor list — a public page listing every third party that may touch customer personal data, what data they receive, and where they're located
- When you add a new sub-processor, notify customers in advance (30 days is standard) and give them the right to object
- Your DPA must flow data protection obligations down to sub-processors — meaning you need your own DPAs with AWS, Stripe, Intercom, Sentry, and any other service that processes customer data
Common sub-processors for a typical SaaS: AWS or GCP (hosting), Stripe (payments), Intercom or Crisp (support), Datadog or Sentry (monitoring), SendGrid or Postmark (transactional email).
Not having a sub-processor list is one of the fastest ways to lose an enterprise deal. Procurement teams check for it. Publish it at /legal/sub-processors and link to it from your privacy policy and DPA.
Your Own Website Compliance — This Part Is Non-Negotiable Too
Your marketing site — where you run your blog, capture trial signups, and run ads — is where you're a data controller. The rules here are the same as for any website under GDPR.
Cookie consent: Non-essential cookies (analytics, ad pixels, retargeting) cannot fire until the visitor actively consents. Not a banner that loads cookies and says "by continuing, you agree." An actual opt-in that blocks scripts before consent is given.
Privacy policy: Must describe what data you collect, why, the legal basis, who you share it with (specific third parties, not just "partners"), how long you keep it, and how EU visitors can exercise their rights. A generic template that doesn't mention your actual tools is not compliant.
This is the stuff that's easy to deprioritize while you're focused on product. Don't. Your marketing site is the front door. If a privacy-conscious prospect scans it and finds trackers firing without consent, that's a credibility problem before the conversation even starts.
User Data Within Your SaaS Product
Beyond the controller/processor dynamic with your customers, you also manage data about your own end-users — people who create accounts, log in, and use the product. For them, you're the controller. That comes with obligations.
Data minimization: Only collect what you need. If you're asking for a phone number at signup but never call anyone, remove the field. Audit your onboarding flow and integrations with fresh eyes.
Retention policies: Set them and enforce them. How long do you keep logs? What happens to data when a user cancels? When does a trial account get purged? Write the policies, build the deletion jobs, document them in your privacy policy.
DSAR handling: Any EU user can request a copy of all personal data you hold, request deletion, or ask you to stop processing. You have 30 days to respond. Know where user data lives — across which databases, third-party tools, backup systems — before the first request lands.
International Data Transfers — If You're US-Based, Read This
If your infrastructure is in the US and you process EU residents' personal data, you have an international data transfer issue. The EU considers the US a third country without adequate data protection, so you need a legal mechanism to transfer data there.
The primary mechanism for most SaaS companies is Standard Contractual Clauses (SCCs) — contractual terms approved by the European Commission that provide a legal basis for the transfer when incorporated into your agreements.
In practice:
- Your DPA with customers should incorporate SCCs for the applicable transfer scenario (controller-to-processor is Module 2; processor-to-controller is Module 4)
- Your sub-processor agreements should also incorporate SCCs
- EU-US Data Privacy Framework (DPF) certification is an alternative — it functions as an adequacy mechanism for certified companies, but requires annual renewal
Storing EU data in EU-region infrastructure (AWS eu-west, GCP europe-west) reduces the transfer exposure but doesn't eliminate it — you still need to account for where your team accesses the data and where your sub-processors operate.
Get a privacy lawyer to review your transfer setup before signing enterprise DPAs. This is not an area to wing.
Common SaaS GDPR Mistakes
1. No DPA Template Ready When an Enterprise Customer Asks
The most common deal-killer. A prospect's legal team requests a DPA as part of procurement. You don't have one. You scramble for a lawyer. The deal stalls. Have your DPA template ready before you need it — not as a blocker but as a proof point that you're a serious vendor.
2. Not Maintaining a Sub-Processor List
Without a published list, you can't give the required notice when you add new tools. You're also out of compliance with every DPA you've signed. Create it, publish it, and maintain a process for updating it when you adopt new tools.
3. Marketing Site Out of Compliance While the Product Gets All the Attention
Engineering time goes into the product. The marketing site's cookie banner from two years ago quietly loads trackers without consent. Regulators don't distinguish between your product and your marketing site.
4. Ignoring DSAR Requests from End-Users
A request lands in your support inbox. It gets triaged as a "weird legal email" and sits. Thirty days pass. You're non-compliant. Build a simple intake process before the first request comes in, not after.
5. Assuming SCCs Are Someone Else's Problem
If you're US-based, international data transfers are your problem — not just your customers'. If your DPA doesn't address SCCs and you process EU data, your DPA is incomplete.
A Practical GDPR Starting Checklist for SaaS Founders
- Scan your marketing site. Find every cookie, pixel, and tracker loading with and without consent. You can't fix what you can't see.
- Implement a proper consent banner that blocks non-essential scripts before consent is given. Test it in incognito before and after accepting.
-
Draft a DPA template with a privacy lawyer. Publish it at
/legal/dpa. Make it your starting point in enterprise negotiations, not theirs. - Publish your sub-processor list — names, locations, and what data each service receives. Link to it from your DPA and privacy policy.
- Set and document retention policies for logs, user data, and backups. Write them down, build the deletion automation, and put them in your privacy policy.
- Create a DSAR intake process — a public form or email, a designated owner, and a 30-day deadline tracker.
- Address international data transfers in your DPA. If you're US-based and processing EU data, incorporate SCCs. Consider EU data residency for customers who require it.
How Custodia Helps SaaS Companies
Several of these compliance requirements are things Custodia can handle directly. A few are things we're honest about requiring a legal resource.
Website scanner: Custodia crawls your marketing site like a real EU visitor — detecting every cookie, tracker, pixel, and third-party script that's running, with or without consent. SaaS marketing sites are often the compliance blind spot. This gives you the complete picture in minutes.
Consent banner: Generated from your actual scan data, not a template. Blocks non-essential scripts before consent. Jurisdiction-aware — GDPR opt-in for EU visitors, CCPA opt-out for California visitors. Supports Google Consent Mode v2. Exactly what your marketing site needs.
Privacy policy: AI-generated from your real data practices. Specific to the tools you actually use, updated automatically when your site changes. Both a public-facing visitor policy and a product privacy policy.
DSAR management: Built-in intake form, deadline tracking, and AI-assisted data discovery across your systems. When an end-user submits a request, Custodia helps you find the data, draft the response, and meet the 30-day deadline.
What Custodia doesn't replace: A DPA template requires a real privacy lawyer. Sub-processor agreements, SCC incorporation, and international transfer analysis need legal expertise we don't provide. Custodia handles the operational and technical compliance layer — the part that's ongoing, repeatable, and benefits most from automation.
Plans start at $29/month. Most SaaS teams get full value from the Growth plan at $79/month.
Scan your marketing site free →
No signup required. See what your marketing site is collecting — and what's firing without consent — in 60 seconds.
Last updated: March 2026
Top comments (0)