GDPR Compliance Checklist for SaaS Companies (2025)
A practical GDPR compliance checklist for SaaS companies. Covers lawful basis, data subject rights, breach notification, DPAs, technical measures, and common mistakes.
The GDPR (General Data Protection Regulation) applies to any organization that processes personal data of people in the EU and EEA — regardless of where the organization is based. A SaaS company in California serving European customers is subject to GDPR.
Non-compliance penalties can reach €20 million or 4% of global annual revenue, whichever is higher. More practically, GDPR compliance is now a checkbox on virtually every enterprise security questionnaire from European buyers.
This checklist covers the core requirements for SaaS companies.
1. Establish Lawful Basis for Processing
Every processing activity requires a valid lawful basis. The six lawful bases are:
| Basis | When to use |
|---|---|
| Consent | Optional features, marketing emails |
| Contract | Processing necessary to fulfill your service agreement |
| Legitimate Interests | Fraud prevention, security monitoring (requires LIA) |
| Legal Obligation | Compliance with laws (financial records, etc.) |
| Vital Interests | Life-threatening situations (rare for SaaS) |
| Public Task | Government organizations (rarely applies) |
For most SaaS products:
- Account creation and service delivery: Contract basis
- Marketing emails: Consent (must be opt-in with clear unsubscribe)
- Analytics, logging, security monitoring: Legitimate Interests
- Payment processing: Contract + Legal Obligation
Checklist:
- Document the lawful basis for each category of processing in your Record of Processing Activities (RoPA)
- If using Legitimate Interests, conduct a Legitimate Interests Assessment (LIA)
- Consent must be: freely given, specific, informed, and unambiguous
2. Record of Processing Activities (RoPA)
Article 30 requires companies with 250+ employees (or processing that poses risk to rights and freedoms) to maintain a RoPA — a written record of all processing activities.
Even if you're below the threshold, a RoPA is best practice and often required by customers in security questionnaires.
Each entry should document:
- What data is processed (categories of personal data)
- Why it's processed (purpose)
- Lawful basis
- Who has access (internal roles, third parties)
- Retention period
- Where data is stored (jurisdiction)
- Security measures
3. Privacy Policy and Transparency
Your privacy policy must cover (Article 13/14):
- Who the data controller is (your company, contact details)
- Data Protection Officer contact (if applicable)
- What personal data you collect
- Purpose and lawful basis for each processing activity
- Data retention periods
- Third parties you share data with
- International transfers and safeguards
- Data subject rights and how to exercise them
- Right to lodge complaint with supervisory authority
Write it in plain language. "We may use your data to improve our services" is not compliant — you must specify what data, for what purpose, on what basis.
4. Data Subject Rights
You must be able to fulfill these requests within 30 days (extendable to 90 days with notice):
| Right | What it means |
|---|---|
| Access (Art. 15) | User can request a copy of all their data |
| Rectification (Art. 16) | User can correct inaccurate data |
| Erasure (Art. 17) | "Right to be forgotten" — delete data on request |
| Restriction (Art. 18) | Pause processing while a dispute is resolved |
| Portability (Art. 20) | Provide data in machine-readable format (CSV/JSON) |
| Objection (Art. 21) | Stop processing for direct marketing or legitimate interests |
| Automated Decisions (Art. 22) | Right not to be subject to solely automated decisions with legal effect |
Checklist:
- Build a data export feature (download all my data)
- Build an account/data deletion flow
- Create a process to handle manual requests within 30 days
- Don't require account login to submit a request (creates a catch-22 for erasure)
5. Data Processing Agreements (DPAs)
When you share personal data with a third-party service that processes it on your behalf (a "processor"), you must have a DPA in place.
Common processors requiring DPAs:
- AWS, GCP, Azure (infrastructure)
- Stripe (payment processing)
- SendGrid, Postmark (email delivery)
- Intercom, HubSpot (CRM)
- Datadog, Sentry (monitoring/error tracking)
- Analytics providers
Most major services have pre-signed DPAs available in their legal/privacy portal. You often just need to download and accept them.
Checklist:
- Inventory all sub-processors
- Execute DPAs with each processor
- Publish a sub-processor list for your own customers (required if you're a processor)
- Notify customers 30 days before adding new sub-processors (standard SaaS practice)
6. International Data Transfers
Transferring personal data to countries outside the EEA requires a legal mechanism:
- Adequacy decision: UK, US (for some transfers via DPF), Canada, Switzerland, Japan, South Korea, and others
- Standard Contractual Clauses (SCCs): The most common mechanism; use the 2021 SCCs for new transfers
- Binding Corporate Rules (BCRs): For intra-group transfers in multinational companies
- Derogations: Consent, contract performance, public interest (limited use)
For US SaaS companies: the EU-US Data Privacy Framework (DPF) was established in 2023 as a replacement for Privacy Shield. Certifying under DPF simplifies EU-US transfers for participating companies.
7. Technical and Organizational Measures
Article 32 requires "appropriate technical and organizational measures" to ensure security. This is deliberately non-prescriptive but typically includes:
Technical:
- Encryption at rest (AES-256) for personal data
- Encryption in transit (TLS 1.2+) for all data transfers
- Access controls and authentication (MFA for admin access)
- Regular security testing (vulnerability scans, penetration tests)
- Pseudonymization where appropriate
- Audit logging of access to personal data
Organizational:
- Privacy training for staff
- Access on need-to-know basis
- Vendor due diligence for processors
- Written security policies
8. Data Breach Notification
If you suffer a personal data breach, GDPR requires:
- 72 hours: Notify your supervisory authority (e.g., ICO in the UK, DPA in Germany) if the breach poses risk to individuals
- Without undue delay: Notify affected individuals if the breach poses high risk to them
What counts as a breach: any accidental or unlawful access, disclosure, alteration, or loss of personal data — not just malicious attacks. A misconfigured S3 bucket that was publicly accessible is a notifiable breach if personal data was involved.
Checklist:
- Document your breach notification procedure
- Identify which supervisory authority you report to (usually where your EU establishment is, or your main EU customer base)
- Have a 72-hour incident response plan
9. Data Minimization and Retention
Collect only what you need (minimization). Delete it when you no longer need it (retention limitation).
Checklist:
- Define retention periods for each data category
- Implement automatic deletion (purge inactive accounts after X months)
- Don't keep data "just in case" — document why each field is necessary
- Delete data from backups within reasonable timeframes after deletion requests
10. Do You Need a DPO?
A Data Protection Officer is required if you:
- Are a public authority
- Carry out large-scale systematic monitoring of individuals
- Process special categories of data (health, biometric, political views, etc.) at large scale
Most B2B SaaS companies don't require a DPO. But designating a privacy lead (even if not formally a DPO) is good practice and satisfies customer questionnaire questions about privacy ownership.