GDPR and SaaS: Why It's Complicated
GDPR wasn't written with SaaS in mind. It was designed around a world where a company collects data, processes it, and stores it — a linear model. SaaS breaks that model: you're processing data on behalf of your customers, who are processing data on behalf of their users, across multiple jurisdictions, through interconnected systems.
This creates a web of responsibilities that's genuinely confusing. Are you a data controller or processor? Both? When do you need consent from your customers' users? What happens when a German user's data flows through your US-hosted infrastructure?
This guide untangles it.
Controller vs. Processor: Getting the Basics Right
When You're a Data Processor
In most B2B SaaS scenarios, you're a data processor. Your customer (the business using your software) is the data controller — they decide what data to collect and why. You process it on their behalf.
Examples:
A project management tool storing customer team data
A CRM holding customer contact records
An analytics platform processing website visitor data
A communication tool transmitting customer messages
As a processor, you must:
Only process data according to the controller's documented instructions
Ensure staff handling data are under confidentiality obligations
Implement appropriate technical and organizational security measures
Not engage sub-processors without the controller's authorization
Assist the controller in responding to data subject requests
Delete or return all personal data when the contract ends
Make information available for audits
When You're a Data Controller
You're also a controller for some data — specifically, data you collect for your own purposes:
Customer account information (billing contacts, admins)
Website visitor data (your marketing site analytics, contact forms)
Employee data
Marketing contacts
For this data, you have full GDPR controller obligations: legal basis, privacy notices, data subject rights handling, and more.
When You're Both
This is common. You're a processor for customer-submitted data within your platform and a controller for your own business data. Your privacy documentation needs to address both roles clearly.
The GDPR Compliance Checklist for SaaS
1. Data Mapping and Records of Processing
GDPR Article 30 requires both controllers and processors to maintain records of processing activities. For a SaaS company, this means documenting:
As a processor:
Categories of processing performed on behalf of each customer
International data transfers
Technical and organizational security measures
Sub-processors used
As a controller (for your own data):
Categories of data subjects and personal data
Purposes of processing
Legal basis for each processing activity
Recipients of data (including third parties)
International transfers and safeguards
Retention periods
How to actually do this:
Start with a spreadsheet. For every system and process that touches personal data, document: what data, whose data, why, where it's stored, who accesses it, and how long you keep it.
Better yet, use PrivaBase's automated data mapping to discover personal data flows across your systems. It's faster, more accurate, and stays current as your infrastructure changes.
2. Legal Basis for Processing
Every processing activity needs one of six legal bases. Here's what typically applies in SaaS:
Contractual necessity (Article 6(1)(b))
Processing customer account data to deliver the service
Managing billing and payments
Providing customer support
Legitimate interest (Article 6(1)(f))
Product analytics to improve your service (must pass the balancing test)
Fraud prevention and security
Internal operations
Consent (Article 6(1)(a))
Marketing emails (in most jurisdictions)
Non-essential cookies and tracking on your website
Optional data collection beyond what's needed for the service
Legal obligation (Article 6(1)(c))
Tax records retention
Responding to lawful legal requests
Important: Document the legal basis for each processing activity before you do it, not after. If a DPA asks, "On what basis do you process this data?" you need an immediate, documented answer.
3. Privacy Notices
You need clear privacy notices for different audiences:
Website visitors: A comprehensive
privacy policy covering cookies, analytics, forms, and marketing.
Customers: A privacy notice covering account data, usage data, support interactions, and billing. This can be part of your website privacy policy or a separate document.
Your customers' end users: As a processor, you generally don't need a separate notice for your customers' users — that's the controller's responsibility. But if your platform has direct interactions with end users (e.g., login pages, email notifications), consider a brief processing notice.
4. Data Processing Agreements (DPAs)
GDPR Article 28 requires a written contract between controllers and processors. Every SaaS company needs:
DPAs with your customers (you as processor):
Your DPA should cover:
Subject matter, duration, nature, and purpose of processing
Types of personal data and categories of data subjects
Controller's obligations and rights
Your obligations as processor (security, confidentiality, sub-processors, breach notification, data subject requests, audits)
Data deletion/return upon termination
International transfer mechanisms
DPAs with your vendors (them as sub-processors):
Every vendor that processes personal data on your behalf needs a DPA
This includes: cloud providers (AWS, GCP, Azure), email services (SendGrid, Postmark), analytics (if processing personal data), payment processors, support tools
Most major vendors have standard DPAs available for signing
Pro tip: Create a standard DPA template and post it publicly. This saves weeks of legal back-and-forth with customers. Include all required Article 28 terms plus your standard security measures.
5. Sub-Processor Management
Your customers need to know who else processes their data. GDPR requires:
Maintain an up-to-date list of sub-processors (name, purpose, location)
Publish this list (most SaaS companies use a public web page)
Notify customers before adding new sub-processors
Give customers the right to object to new sub-processors
Ensure sub-processor contracts include equivalent GDPR protections
Best practice: Create a public sub-processor page (e.g., yourcompany.com/sub-processors) and include a notification mechanism (email list or RSS) for changes.
6. International Data Transfers
If you transfer personal data outside the EEA, you need a lawful transfer mechanism:
Adequacy decisions: Some countries are approved by the EU as having adequate data protection (UK, Canada, Japan, South Korea, etc.). Transfers to these countries need no additional safeguards.
EU-US Data Privacy Framework: If your US-based company (or vendor) is certified under the DPF, transfers to them are covered. Check the DPF list for your vendors.
Standard Contractual Clauses (SCCs): The fallback mechanism for most transfers. You'll need:
The correct module (controller-to-processor or processor-to-processor)
A Transfer Impact Assessment (TIA) documenting risks
Supplementary measures if the destination country's laws don't provide equivalent protection
Practical approach for SaaS:
Map all international data flows (your systems + sub-processors)
Check if each destination is covered by adequacy, DPF, or existing SCCs
Fill gaps with SCCs + TIAs
Document everything — auditors and DPAs will ask
7. Data Subject Rights
As a processor, you'll primarily assist your customers (controllers) in handling data subject requests. But you need:
Processes for your own data (where you're controller):
Respond to access, deletion, correction, portability, and objection requests
30-day response deadline (extendable to 90 for complex requests)
Identity verification procedures
Document every request and response
Processes for customer data (where you're processor):
A mechanism for customers to submit DSRs through your platform
Technical capability to export and delete specific user data
API endpoints for programmatic DSR fulfillment
Documentation of your DSR support capabilities
PrivaBase automates DSR handling across both your controller and processor data, reducing response times from hours to minutes.
8. Breach Notification
GDPR requires:
As a processor: Notify the affected controller "without undue delay" after becoming aware of a breach. In practice, this means within 24-72 hours.
As a controller (for your own data): Notify the relevant DPA within 72 hours if the breach poses a risk to individuals. Notify affected individuals "without undue delay" if the breach poses a high risk.
What you need:
An incident response plan that includes GDPR notification requirements
A breach assessment template (to determine severity and notification obligations)
Pre-drafted notification templates
Contact information for relevant DPAs
A way to notify affected customers quickly
9. Data Protection Impact Assessments (DPIAs)
Required when processing is "likely to result in a high risk to the rights and freedoms of natural persons." For SaaS, this typically applies when you:
Process personal data at large scale
Use automated decision-making or profiling
Process sensitive categories of data (health, biometrics, etc.)
Implement new technologies for processing personal data
A DPIA should assess:
The necessity and proportionality of processing
Risks to individuals
Measures to mitigate those risks
Whether processing should proceed
10. Technical and Organizational Measures
GDPR requires "appropriate" security measures. For SaaS, the baseline includes:
Technical:
Encryption in transit (TLS 1.2+) and at rest (AES-256)
Access controls with MFA
Regular vulnerability scanning and penetration testing
Logging and monitoring
Backup and disaster recovery
Data isolation between customers (logical or physical)
Secure development practices (code review, SAST/DAST scanning)
Organizational:
Security policies and procedures
Employee training on data protection
Incident response procedures
Regular security reviews and audits
Vendor security assessments
Common GDPR Mistakes in SaaS
Treating all data the same — Different data types need different legal bases and retention periods
Forgetting about employee data — Your employee data is subject to GDPR too
Ignoring sub-processors — Adding a new analytics tool without updating your sub-processor list is a violation
Over-relying on consent — Consent can be withdrawn at any time. Use contractual necessity or legitimate interest where appropriate
Copy-pasting DPAs — Your DPA needs to reflect your actual processing activities
Not testing data deletion — Can you actually delete a specific user's data from all systems? Test it
Treating GDPR as a one-time project — Compliance requires ongoing monitoring and maintenance
Building a GDPR Program That Scales
The key to sustainable GDPR compliance is automation. Manual processes break down as you grow:
Automated data mapping keeps your records of processing current as your stack evolves
Automated DSR handling prevents data subject requests from becoming a bottleneck
Continuous monitoring catches new compliance gaps (unauthorized cookies, new sub-processors, policy drift)
Centralized vendor management tracks DPA status and sub-processor changes
PrivaBase was built specifically for this — a single platform to manage your GDPR obligations as both a controller and processor, with automation that scales as your company grows.
Getting Started Today
Scan your website — Free, instant assessment of your website's GDPR compliance
Map your data — Understand what personal data you process and where it lives
Draft your DPA — Post it publicly and streamline customer onboarding
Set up DSR handling — Even a simple email process is better than none
Explore PrivaBase — Free tier includes the tools to build your GDPR foundation
GDPR compliance for SaaS is complex, but it's manageable when you break it into components and tackle them systematically. Start with the highest-risk areas (data mapping, DPAs, breach notification) and build from there.