SaaS compliance guide
GDPR Privacy Policy for SaaS Companies
A SaaS privacy policy is more complex than a content website's. You're operating as both a data controller for your own marketing data and a data processor for your customers' users. Most generic privacy policy templates miss the processor side entirely.
- Your two roles
- Data Processing Agreements
- Sub-processors
- International transfers
- Lawful basis for analytics
- What your policy must include
- Common SaaS mistakes
- Generate yours free
- FAQ
Your two GDPR roles as a SaaS company
The most common SaaS GDPR mistake is writing a privacy policy that only covers one role. Every B2B SaaS operates in two distinct capacities under GDPR, and each has different obligations.
For your own marketing and billing data
When you collect email addresses for newsletters, run analytics on your marketing site, or store payment details — you decide why and how this data is processed. You are the data controller for this data. Your privacy policy must explain what you collect, why, the lawful basis for each processing activity, and how visitors can exercise their GDPR rights against you.
For your customers' end-user data
When your application stores names, emails, activity logs, or any other data that your customers input about their own users — your customer is the data controller for that data, and you are the data processor acting on their instructions. You must process that data only as directed, maintain appropriate security, and not use it for your own purposes (such as training ML models without permission).
Both roles must be addressed in your documentation. Most generic privacy policy templates only address the controller role, leaving the processor relationship entirely undisclosed — which means your policy is incomplete for any EU customer or EU end-user whose data passes through your system.
Data Processing Agreements (DPAs)
GDPR Article 28 requires that whenever you process personal data on behalf of a customer (as a processor), that relationship must be governed by a written contract — the Data Processing Agreement. This is not optional. Without a DPA:
- Your customer is in breach of GDPR Article 28 places the obligation on the controller (your customer) to only use processors that provide sufficient guarantees via a binding contract. If you can't produce a DPA, enterprise and regulated-sector customers legally cannot use your product.
- You cannot accept EU enterprise deals Enterprise procurement teams, especially in financial services, healthcare, and government sectors, require a signed DPA before contract execution. No DPA means no deal — and increasingly, mid-market SaaS buyers ask for one too.
- Your processing has no lawful basis Processing customer data without a DPA means you're processing without the contractual framework GDPR requires. Supervisory authorities treat this as a distinct violation separate from any substantive data protection failures.
A DPA does not need to be hundreds of pages. At minimum it must specify: the subject-matter and duration of the processing; the nature and purpose of the processing; the type of personal data and categories of data subjects; and the controller's obligations and rights. It must also include provisions for sub-processors, security measures, breach notification to the controller, and deletion or return of data at contract end.
Sub-processors: what they are and what you owe customers
A sub-processor is any third party you engage to process your customers' personal data on your behalf. When you use AWS to host your database of customer data, or Sentry to collect error reports that include user identifiers, those providers are your sub-processors.
GDPR Article 28(2) requires that you obtain your customer's general or specific authorization before engaging a sub-processor. In practice, "general authorization" (the standard approach) means disclosing your sub-processor list upfront in your DPA, and notifying customers before adding new sub-processors — giving them the opportunity to object.
| Category | Common examples | Processes customer data? |
|---|---|---|
| Infrastructure & hosting | AWS, Google Cloud, Azure, Hetzner, Fly.io | Yes — stores all customer data at rest |
| Error monitoring | Sentry, Datadog, Rollbar, New Relic | Yes — error payloads often contain user IDs, emails, or session data |
| Customer support | Intercom, Zendesk, Help Scout, Front | Yes — support tickets may contain end-user personal data |
| Email delivery | Postmark, SendGrid, AWS SES, Resend | Yes — if you send transactional emails to your customers' end-users |
| Product analytics | Mixpanel, Amplitude, PostHog, Heap | Yes if user identifiers are passed; No if fully anonymous |
| Payment processing | Stripe, Paddle, Braintree | Usually No — payment data goes directly to the processor, not through your system |
| CDN / static assets | Cloudflare, Fastly (static files only) | Usually No — if only serving static assets without user context |
| Authentication | Auth0, Clerk, Firebase Auth | Yes if you delegate identity storage to them |
The test for whether something is a sub-processor: can this vendor access, store, or process personal data that belongs to your customers' users? If a tool only sees server-level metrics with no user context (CPU load, network bytes), it likely isn't a sub-processor. If error payloads include user IDs or the vendor stores user activity, it is.
International data transfers: SCCs for US-based SaaS
If your SaaS is based in the US and you have EU customers or EU end-users, you are transferring personal data from the EU to the United States. The EU-US adequacy framework (currently the EU-US Data Privacy Framework, adopted in 2023) allows transfers to certified US organizations. However, for SaaS companies that have not self-certified under the DPF, Standard Contractual Clauses (SCCs) remain the primary mechanism for legitimizing EU-to-US transfers.
The 2021 modular SCCs, approved by the European Commission, replaced the older SCC sets. For a SaaS company processing customer data:
- For your customers' data transfers to your US infrastructure: use Module 2 (Controller-to-Processor) — your customer is the controller transferring data to you as a US-based processor.
- For your own EU-to-US transfers (e.g., EU marketing data going to your US analytics stack): use Module 1 (Controller-to-Controller) if the US vendor processes the data for their own purposes, or Module 2 if they process it on your behalf.
SCCs are incorporated as an annex to your DPA. You also need to perform a Transfer Impact Assessment (TIA) — a documented analysis of whether US surveillance law (FISA 702, EO 12333) creates risks to the data subjects that the SCCs cannot adequately protect against, and what supplementary measures you have in place.
Lawful basis for product analytics
If you use tools like Mixpanel, Amplitude, or PostHog to track how your users interact with your product, you need a lawful basis for that processing under GDPR Article 6. The two most common choices for SaaS product analytics are legitimate interest and contract performance.
| Lawful basis | When it applies | What you must do |
|---|---|---|
| Legitimate interest (Art. 6(1)(f)) | Understanding how users interact with the product to improve it; fraud detection; security monitoring | Document a Legitimate Interests Assessment (LIA). Disclose it in your privacy policy. Provide an opt-out mechanism. |
| Contract performance (Art. 6(1)(b)) | Data strictly necessary to deliver the service the user contracted for (session state, authentication, saving user settings) | Strictly limit to data required for the service. No opt-out required. Cannot be used for analytics beyond what the user expects as part of the service. |
| Consent (Art. 6(1)(a)) | Optional, enhancement-level analytics; marketing profiling; cross-site tracking | Obtain affirmative, granular consent before collecting. Must be withdrawable. Records of consent required. |
Most SaaS product analytics (understanding feature adoption, funnel analysis, error rates) are defensible under legitimate interest — the interest in improving your product is genuine, the processing is necessary for it, and it doesn't override users' fundamental rights when done with pseudonymized identifiers. Document the LIA and keep it on file. Supervisory authorities can request it.
Where legitimate interest does not apply: using product analytics data to build behavioral profiles for ad targeting, or sharing event data with advertising platforms for retargeting, typically requires consent under GDPR and a "Do Not Sell or Share" disclosure under CCPA.
What your SaaS privacy policy must include
In addition to the standard disclosures that any website privacy policy requires (what you collect, why, who you share it with, retention periods, how to exercise rights, contact information), a SaaS privacy policy needs:
- Controller vs. processor distinction A clear explanation of which data you control as a data controller (marketing, billing, sign-up data) and which data you process as a data processor on behalf of your customers. The rights and remedies available to data subjects differ depending on which role applies.
- Sub-processor list or reference to one Either a table of current sub-processors in the policy itself, or a link to a maintained sub-processor list page. Include the sub-processor name, country/location, and what category of data they process.
- DPA availability statement A statement that a DPA is available for EU customers, and how to request or access it (link to your DPA page or account settings).
- International transfer safeguards State the mechanism you use for EU-to-US transfers (SCCs, DPF certification, or EU-hosted infrastructure). For SCCs, state the relevant module and where the full text can be found.
- Security measures Describe the technical and organizational measures in place to protect customer data: encryption at rest and in transit, access controls, penetration testing cadence, and incident response commitments.
- Data retention for customer data How long customer account data and end-user data is retained while the account is active, and what happens at contract end (export window, deletion timeline).
- Breach notification procedure How and how quickly you will notify customers of a security incident affecting their data. GDPR requires you to notify your customer (the controller) promptly — they have 72 hours to notify their supervisory authority once they know.
Common GDPR mistakes SaaS founders make
- Only addressing website visitor data, not customer account data. A policy that describes your marketing analytics and contact form but says nothing about how you handle the data your customers input into your application leaves the processor relationship entirely unaddressed. This is the single most common gap.
- No DPA, or a DPA that hasn't been updated since you added new sub-processors. Enterprise customers will ask for it during procurement. Not having one is a deal-blocker; having one that lists sub-processors you no longer use or omits ones you've added since is a breach of the DPA's own terms.
- Listing "consent" as the lawful basis for product analytics. If you state consent in your policy but don't actually collect and record consent — no consent banner, no opt-in mechanism — you're claiming a basis that doesn't exist. Legitimate interest is the correct basis for most SaaS usage analytics, and it doesn't require a consent banner.
- No mention of international transfers or SCCs. If you collect EU user data and store it on US infrastructure without documenting your transfer mechanism, you're in breach of GDPR Chapter V regardless of the quality of the rest of your policy.
- Omitting sub-processors from the DPA. A DPA that says "we use sub-processors" without naming them doesn't satisfy Article 28(2). Customers need to know who they're authorizing to touch their data.
- No process for data deletion at contract end. GDPR requires data to be deleted or returned to the controller when the processing relationship ends. If your policy or DPA doesn't address the contract-end deletion window, customers have no way to confirm you'll delete their data — and you have no documented commitment to hold yourself to.
Generate a GDPR-compliant policy with ComplyKit
ComplyKit generates privacy policies that address GDPR, CCPA, and CalOPPA from a single form. When you select GDPR as a covered jurisdiction, the generated policy includes lawful basis disclosures for each processing category, EU/UK data subject rights, and a controller identification section.
Generate my SaaS privacy policy free →
For the processor-side obligations (DPA template, sub-processor list structure, SCC annexes), ComplyKit's generated policy includes the required disclosures and language — you'll still need to populate your specific sub-processor list and adapt the DPA to your product. For a legally vetted DPA for high-stakes enterprise deals, consult a privacy attorney. For the long tail of customers who just need a signed document, a well-structured standard DPA covers the requirement.
Also relevant: Which privacy laws apply to your website covers the full decision tree for when GDPR, CCPA, and CalOPPA are triggered, including the size thresholds that determine whether CCPA applies alongside GDPR. And if you're building a SaaS with a public-facing client portal or user-facing interface, ShipSafe can audit that interface for ADA/WCAG accessibility gaps — a separate compliance obligation from privacy law that plaintiff firms frequently check alongside missing privacy policies.
Frequently asked questions
Does my SaaS need a Data Processing Agreement (DPA)?
Yes, if you have customers in the EU or process EU residents' data on behalf of your customers. GDPR Article 28 requires that processor relationships be governed by a written contract specifying the subject-matter, nature, and purpose of the processing, plus processor obligations. Enterprise and government customers will not proceed without one. Publish a standard DPA and make it available in your account settings or on request.
What is the difference between being a data controller and a data processor for my SaaS?
You are a data controller when you decide why and how personal data is processed for your own purposes — marketing analytics, billing data, newsletter subscribers. You are a data processor when you handle your customers' end-user data on their behalf, acting on their instructions. Most SaaS companies are both simultaneously: controller for their own marketing and billing data, processor for customer data stored in the application. Your privacy policy must address both roles.
Do I need separate privacy policies for website visitors and my customers' end-users?
No — a single document can cover both if it clearly distinguishes the two contexts. A common approach is to use separate sections: one for "Website Visitors and Prospective Customers" (where you are the controller) and one for "Customer Data" or "Service Data" (where you are the processor). Some companies add a separate Data Processing Policy page for detailed processor disclosures linked from the main privacy policy. Either structure works as long as both roles are addressed.
What sub-processors do most SaaS companies need to list?
The most common are: infrastructure and hosting (AWS, GCP, Azure, Fly.io), error and performance monitoring (Sentry, Datadog, New Relic), customer support (Intercom, Zendesk, Help Scout), email delivery (Postmark, SendGrid, AWS SES), product analytics (Mixpanel, Amplitude, PostHog), and authentication providers (Auth0, Clerk, Firebase Auth). The test is whether the vendor can access, store, or process personal data belonging to your customers' users. A CDN serving only static files is usually not a sub-processor; a monitoring tool that receives error payloads containing user IDs is.
Can I use legitimate interest as the lawful basis for product analytics?
Yes, for product usage analytics (feature adoption, funnel analysis, error rates). Legitimate interest is a recognized lawful basis under GDPR Article 6(1)(f) and doesn't require a consent banner. You must document a Legitimate Interests Assessment (LIA) showing that your interest is genuine, processing is necessary for it, and it doesn't override data subjects' rights. Keep the LIA on file — supervisory authorities can request it. Where you use analytics data for ad targeting or cross-site behavioral profiling, consent is required instead.
What are Standard Contractual Clauses and do I need them?
SCCs are template contracts approved by the European Commission that legitimize personal data transfers from the EU to countries without an EU adequacy decision — including the United States. If your SaaS is US-based and you collect personal data from EU residents or customers, you need SCCs (Module 2: Controller-to-Processor for customer data transferred to you; Module 1: Controller-to-Controller for EU marketing data sent to US-based analytics vendors). SCCs are incorporated as an annex to your DPA. Alternatively, self-certify under the EU-US Data Privacy Framework (DPF) at dataprivacyframework.gov.
How often should I update my sub-processor list?
Update it whenever you add or remove a sub-processor, and notify customers in advance — typically 30 days before adding a new sub-processor that processes their data. Your DPA should state the notice period and customers' right to object. In practice: maintain a dated sub-processor list page on your site and email customers when it changes. Review the list every time your infrastructure changes — a new monitoring tool, a new hosting region, a new support platform.
Also in the Copper Bay Labs ship-safety suite
Privacy compliance is one of several things to audit before you ship a SaaS product. These free tools cover security, accessibility, and exposed secrets:
Checks your live site for accessibility and privacy-law gaps that attract ADA demand letters.
Secret scanning LeakCheckPaste code or a config file and see exposed API keys and tokens flagged before they reach the repo.
Security headers HardenCheckScan your live site's HTTP headers for missing CSP, HSTS, and other security hardening flags.
Post-deploy ExposureCheckScan your live URL for exposed .env files, .git directories, and bundled secrets.