European regulators issued €1.2 billion in GDPR fines in 2025, consistent with 2024 levels, pushing cumulative penalties since 2018 to €7.1 billion. Data protection authorities across Europe now receive an average of 443 breach notifications per day. These are not numbers aimed at Big Tech alone. Ireland and France accounted for over €1 billion of the 2025 total, but fines of £10,000-500,000 against SMEs and SaaS companies are increasingly routine, particularly for missing privacy policies, ignored data subject requests, and non-compliant cookie banners.
If your SaaS product processes personal data of EU or UK residents, GDPR applies, regardless of where your company is incorporated, where your servers are hosted, or how small your user base is. This checklist covers the 15 essential compliance areas with specific implementation guidance for SaaS businesses, including the intersection with the EU AI Act that came into force in 2025.
Does GDPR Apply to You?
GDPR applies if:
- Your company is established in the EU/EEA, or
- You offer goods or services to people in the EU/EEA (including free services), or
- You monitor the behaviour of people in the EU/EEA
For SaaS companies, the second and third criteria are the ones that catch you. If you have EU customers, EU users, or track EU website visitors with analytics, GDPR applies. Hosting your servers outside Europe does not exempt you. Having no EU entity does not exempt you. Processing data "only in the cloud" does not exempt you.
Since the UK left the EU, the UK GDPR operates as a separate but nearly identical regime enforced by the ICO. If you serve both EU and UK users, you comply with both. The practical differences are minor but real, primarily around international transfer mechanisms and supervisory authority jurisdiction.
Controller vs Processor: Know Your Role
This distinction determines your specific obligations under the regulation:
Controller: You decide why and how personal data is processed. If you collect user data for your own product (names, emails, usage analytics, billing details) you are a controller for that data.
Processor: You process data on behalf of someone else. If you are a B2B SaaS and your customers input their end users' data into your platform, you are a processor for that data.
Most SaaS companies are both simultaneously: a controller for their own customer relationship data and a processor for data their customers store in the platform. Your obligations differ by role. Controllers carry primary responsibility for lawful basis, transparency, and data subject rights. Processors have specific duties around security measures, breach notification, and sub-processor management.
Understanding this dual role is essential. A compliance programme that treats you only as a controller will miss processor-specific obligations. One that treats you only as a processor will miss your controller duties for your own customer data.
The Checklist
1. Data Mapping and Records of Processing
Requirement: Document every category of personal data you collect, its source, storage location, access controls, retention period, and legal basis. Maintain a Record of Processing Activities (ROPA) as required by Article 30.
SaaS-specific data categories to map:
| Data Category | Your Role | Typical Sources | Storage |
|---|---|---|---|
| Customer account data (names, emails, billing) | Controller | Registration, billing | Primary database, Stripe |
| Customer-stored data (their users' data in your platform) | Processor | Customer input via API/UI | Primary database, object storage |
| Employee/contractor data | Controller | HR systems, payroll | HR platform, payroll provider |
| Website analytics | Controller | Cookies, tracking scripts | GA4, Mixpanel, PostHog |
| Support ticket contents | Controller/Processor | Email, chat, in-app | Intercom, Zendesk, email |
| Marketing data (email lists, campaign engagement) | Controller | Sign-up forms, events | HubSpot, Mailchimp |
| Application logs and telemetry | Controller/Processor | Application servers | Datadog, CloudWatch, ELK |
Action: Build your ROPA in a structured format, either a spreadsheet or a dedicated tool. For each processing activity, record: purpose, lawful basis, data categories, data subjects, recipients, transfers, and retention period. This is legally required and is typically the first document a regulator requests during an investigation.
2. Lawful Basis for Every Processing Activity
Requirement: Every processing activity must have one of six legal bases. Selecting the wrong basis creates compliance risk that's difficult to remediate retrospectively.
| Basis | When to Use | SaaS Example | Risk Level if Misapplied |
|---|---|---|---|
| Contract (Art. 6(1)(b)) | Processing necessary to fulfil a contract | Providing the subscribed service | Low: clear and defensible |
| Legitimate interest (Art. 6(1)(f)) | Business benefit without overriding individual rights | Product analytics, fraud prevention, security logging | Medium: requires documented balancing test |
| Consent (Art. 6(1)(a)) | Freely given, specific, informed consent | Marketing emails, non-essential cookies, third-party data sharing | High: can be withdrawn at any time |
| Legal obligation (Art. 6(1)(c)) | Required by law | Tax records, financial reporting, regulatory disclosures | Low: clear and defensible |
| Vital interests (Art. 6(1)(d)) | Protecting someone's life | Rarely applicable to SaaS | N/A |
| Public interest (Art. 6(1)(e)) | Public authority functions | Rarely applicable to SaaS | N/A |
Common mistake: Defaulting to consent when legitimate interest would be more appropriate. Consent can be withdrawn at any time, creating operational complexity. If a user withdraws consent for analytics, you must stop processing their data for that purpose immediately and delete any data collected under that basis. Use consent only when genuinely required (marketing communications, non-essential tracking, sharing data with third parties for their own purposes).
Common mistake for AI features: If your SaaS uses customer data to train or improve AI models, this requires its own lawful basis, typically consent or a carefully documented legitimate interest with an opt-out mechanism. The EU AI Act adds additional requirements for high-risk AI systems. See our AI governance frameworks article.
3. Privacy Policy
Requirement: A clear, accessible privacy policy compliant with Articles 13 and 14, written in plain language.
Must include (non-negotiable):
- Your identity, contact details, and establishment location
- DPO contact details (if applicable)
- Each processing purpose paired with its specific lawful basis
- Categories of personal data collected per purpose
- Recipients or categories of recipients for each data category
- International transfer details and safeguards
- Retention periods per data category (not "as long as necessary": provide specific periods)
- Complete list of individual rights with instructions for exercising them
- Right to lodge a complaint with a supervisory authority (name the relevant authority)
- Whether data provision is a contractual or statutory requirement
- Information about automated decision-making, including profiling
SaaS-specific requirement: You need separate privacy disclosures for:
- Your customers (controller relationship): your main privacy policy
- Your customers' end users (processor relationship): typically addressed through your customer's privacy policy, but you should provide a sub-processor page and DPA that enables your customers to meet their own transparency obligations
- Website visitors: may be a separate cookie/analytics disclosure
Many SaaS companies maintain a public sub-processor page (e.g., yourapp.com/subprocessors) listing all third parties that process data on their behalf. This is increasingly expected by enterprise customers and auditors.
4. Cookie Consent
Requirement: Informed, affirmative consent before placing non-essential cookies. The ePrivacy Directive (implemented nationally) governs this alongside GDPR.
Requirements that regulators actively enforce:
- No pre-ticked boxes or implied consent
- No cookie walls (blocking access unless consent is given): the EDPB has ruled these non-compliant
- Granular options: analytics separate from marketing separate from functional
- Rejecting cookies must be as easy as accepting them: one click, not buried in settings
- Record of consent with timestamp
- Cookies must not fire before consent is given (this is the most common technical violation)
Tools: CookieYes, OneTrust, Cookiebot, Osano. Budget £0-200/month depending on traffic and features. Implementation typically takes 2-4 hours for a standard SaaS marketing site.
Enforcement reality: Cookie consent violations are the easiest for regulators to detect (automated scanning tools) and the most common source of complaints. The French CNIL has been particularly active, issuing fines of €40 million to Criteo in 2023 for consent violations.
5. Data Processing Agreements (DPAs)
Requirement: A legally binding agreement (Article 28) with every third party that processes personal data on your behalf.
Must cover:
- Subject matter, duration, nature, and purpose of processing
- Types of personal data and categories of data subjects
- Controller's obligations and rights
- Processor's obligations (security measures, confidentiality, audit rights, sub-processor management, breach notification, deletion/return of data)
Your DPA obligations as a SaaS company:
| Direction | What You Need | Status |
|---|---|---|
| Upstream (your vendors) | DPAs from every sub-processor | Collect and file |
| Downstream (your customers) | Your DPA offered to every customer | Publish on your website |
Common sub-processors requiring DPAs:
- Cloud providers: AWS, GCP, Azure (all publish DPAs)
- Payment processors: Stripe, Braintree, Paddle
- Analytics: PostHog (self-hosted option avoids this), Mixpanel, Amplitude
- Email delivery: SendGrid, Postmark, Resend
- Support: Intercom, Zendesk, Freshdesk
- Error tracking: Sentry, Bugsnag
If a vendor does not have a DPA or refuses to sign one, that is a compliance red flag. Find an alternative.
6. Sub-Processor Management
Requirement: Maintain transparency about the third parties processing data on your behalf and provide customers with notification of changes.
Action:
- Publish a sub-processor list on your website with company name, purpose, data processed, and hosting location for each
- Provide a notification mechanism for changes, such as email subscription or RSS feed
- Include in your DPA the right for customers to object to new sub-processors within a defined period (typically 30 days)
- Evaluate new sub-processors for GDPR compliance before onboarding
Enterprise customers increasingly require sub-processor lists as part of procurement due diligence. Having this page ready signals compliance maturity.
7. International Data Transfers
Requirement: Transferring personal data outside the EU/EEA requires specific legal safeguards under Chapter V of GDPR.
Current transfer mechanisms (2026):
| Mechanism | When It Applies | Complexity |
|---|---|---|
| Adequacy decision | Transfers to countries the EU recognises as adequate (UK, Japan, South Korea, Canada, Israel, others) | Low: no additional safeguards needed |
| EU-US Data Privacy Framework | Transfers to participating US companies (self-certified with the US Department of Commerce) | Low: verify certification per vendor |
| Standard Contractual Clauses (SCCs) | Default for transfers to non-adequate countries where DPF doesn't apply | Medium: must conduct Transfer Impact Assessment |
| Binding Corporate Rules | Intra-group transfers for multinationals | High: requires supervisory authority approval |
SaaS-specific guidance: If you use US-based sub-processors (AWS US regions, Google Cloud, Stripe), verify each is certified under the EU-US Data Privacy Framework. Most major vendors are, but certification must be current and covering the correct data categories. For vendors not covered by DPF, implement SCCs with a documented Transfer Impact Assessment.
UK-specific: The UK has its own adequacy decisions and International Data Transfer Agreement (IDTA) that replaces SCCs for UK-to-third-country transfers. If you serve both EU and UK users, you need both mechanisms.
8. Data Subject Rights Implementation
Requirement: Respond to data subject requests within 30 days (extendable to 90 days for complex requests with notification).
| Right | GDPR Article | SaaS Implementation | Automation Level |
|---|---|---|---|
| Access (copy of data) | Art. 15 | Data export feature | High: build self-service |
| Rectification (correct errors) | Art. 16 | Edit profile functionality | High: already in most products |
| Erasure ("right to be forgotten") | Art. 17 | Account deletion workflow | Medium: must cascade to backups |
| Portability (machine-readable export) | Art. 20 | JSON/CSV export | Medium: requires structured format |
| Restriction (pause processing) | Art. 18 | Account suspension flag | Low: often manual |
| Objection (opt out of legitimate interest processing) | Art. 21 | Opt-out mechanisms | Medium |
| Automated decision-making (human review) | Art. 22 | Human review workflow for AI decisions | Low: case-by-case |
Build self-service into your product. A self-service data export and account deletion feature handles 90% of requests without manual intervention. This is not just a compliance measure; it reduces operational overhead. Tools like DataGrail and Transcend automate the orchestration of data subject requests across your entire sub-processor chain.
The deletion challenge: Erasure requests must cascade to backups, logs, analytics, and sub-processors. Document your deletion workflow, including what happens to backups (acceptable to wait for natural expiry if documented) and anonymised/aggregated data (not personal data, so not subject to erasure).
9. Data Protection Impact Assessments (DPIAs)
Requirement: Mandatory under Article 35 when processing is "likely to result in a high risk" to individuals.
When you need one:
- Large-scale profiling or automated decision-making that produces legal or similarly significant effects
- Systematic monitoring of publicly accessible areas
- Large-scale processing of special category data (health, biometric, genetic, political, religious)
- Using new technologies in novel ways that could create risk
SaaS-specific triggers: If your product uses AI or machine learning to make decisions about people (credit scoring, hiring recommendations, content moderation, fraud detection, risk assessment) you almost certainly need a DPIA. The EU AI Act adds further requirements: high-risk AI systems (listed in Annex III) require conformity assessments that overlap significantly with DPIAs.
DPIA content: Description of processing, necessity and proportionality assessment, risk assessment for individuals, and mitigation measures. The ICO and EDPB both publish templates. A DPIA for a typical SaaS AI feature takes 2-4 days to complete properly.
10. Breach Notification
Requirement: Notify the supervisory authority within 72 hours of becoming aware of a personal data breach that poses a risk to individuals. Notify affected individuals "without undue delay" if the breach poses a high risk.
Your breach response process:
| Timeline | Action | Responsible |
|---|---|---|
| Hour 0 | Detect breach (monitoring, alerts, report) | Engineering/Security |
| Hours 0–4 | Contain breach, assess scope and severity | Incident response team |
| Hours 4–24 | Document: nature of breach, data categories, approximate numbers, likely consequences, measures taken | DPO/Legal |
| Hours 24–48 | Notify customers (as processor, per DPA terms) | DPO/Customer Success |
| Within 72 hours | Notify supervisory authority (as controller) | DPO/Legal |
| Without undue delay | Notify affected individuals if high risk | DPO/Comms |
| Post-incident | Root cause analysis, remediation, breach register update | Engineering |
SaaS-specific: As a processor, you must notify your customers (the controllers) "without undue delay" after becoming aware of a breach affecting their data. Your DPA should specify the notification timeline. Best practice is 24-48 hours, though some enterprise customers require shorter.
Maintain a breach register documenting every breach, including those you determine do not require notification. Regulators will ask for this during audits.
11. Data Protection Officer (DPO)
Requirement: Mandatory under Article 37 if your core activities involve large-scale systematic monitoring of individuals or large-scale processing of special category data.
SaaS reality: Most B2B SaaS companies below 200 employees do not legally require a DPO. However, appointing one (even outsourced) demonstrates compliance maturity to customers and regulators. An outsourced DPO service costs £3,000-8,000/year (DPO Centre, Privacy Culture, Aphaia) and provides expertise that's difficult to hire for at small scale.
If you do appoint a DPO, they must have genuine independence. They cannot be instructed on how to perform their tasks and cannot be penalised for doing their job. This creates practical challenges if the DPO is an internal employee who also has other responsibilities.
12. Privacy by Design and Default
Requirement: Article 25 requires data protection to be considered from the beginning of system design, not retrofitted.
Practical implementation for SaaS engineering teams:
- Data minimisation: Collect only what you need. Audit every field in registration forms, API requests, and tracking events. If you can't justify why you collect it, stop collecting it.
- Privacy-protective defaults: New accounts should have the most restrictive sharing and visibility settings. Opt-in, not opt-out.
- Pseudonymisation: Use internal identifiers rather than personal data in logs, analytics, and internal systems where possible.
- Retention automation: Build TTL (time-to-live) into your database architecture. Data should expire automatically, not accumulate indefinitely.
- Privacy reviews in development: Include privacy impact as a standard consideration in feature specifications and pull request reviews, particularly for features that introduce new data collection or new purposes for existing data.
13. Data Retention Policies
Requirement: Personal data must not be kept longer than necessary for the purpose for which it was collected.
SaaS retention schedule (recommended):
| Data Category | Retention Period | Justification | Deletion Method |
|---|---|---|---|
| Active customer data | Duration of contract + 30 days | Service delivery | Automated deletion on account closure |
| Billing and invoice records | 7 years post-transaction | Legal requirement (tax, accounting) | Automated archival and deletion |
| Support tickets | 2 years after resolution | Service improvement, dispute resolution | Automated deletion job |
| Marketing data | Until consent withdrawn | Consent-based processing | Immediate on unsubscribe |
| Application logs | 90 days | Debugging, security investigation | Log rotation policy |
| Analytics data | Anonymise after 26 months | Product improvement (anonymised = not personal data) | Automated anonymisation job |
| Backups | Aligned with primary retention | Disaster recovery | Backup lifecycle policy |
| Trial/churned user data | 12 months post-churn | Re-engagement (legitimate interest) | Automated deletion job |
Critical point on backups: If you delete a user's data from production but retain it in backups for 90 days, document this. The ICO has indicated this is acceptable provided the retention is justified, documented, and the data is not restored to production.
14. Security Measures
Requirement: Article 32 requires "appropriate technical and organisational measures" proportionate to the risk.
Minimum security controls for SaaS:
| Control | Implementation | Tools |
|---|---|---|
| Encryption in transit | TLS 1.2+ on all endpoints | Let's Encrypt, Cloudflare |
| Encryption at rest | AES-256 for databases and object storage | AWS KMS, GCP KMS |
| Access control with MFA | Enforced for all employees and admin interfaces | Okta, 1Password, Google Workspace |
| Vulnerability scanning | Automated weekly scans, annual penetration test | Snyk, Semgrep, third-party pentest |
| Incident response plan | Documented, tested, and accessible | Internal document, tested quarterly |
| Employee security training | Annual with practical scenarios | KnowBe4, custom programme |
| Backup and disaster recovery | Automated backups, tested restore | AWS Backup, custom scripts |
| Logging and monitoring | Centralised logging with alerting | Datadog, Grafana, ELK |
If you're pursuing ISO 27001 or SOC 2, these controls will already be covered. GDPR compliance and certification programmes are complementary, not redundant.
15. Staff Training and Awareness
Requirement: Staff who handle personal data must understand their GDPR obligations. This isn't optional guidance: it's an enforceable requirement.
Training programme structure:
- All staff: Annual GDPR awareness training covering what personal data is, lawful bases, data subject rights, and breach reporting. 30-60 minutes with assessment.
- Engineering: Additional training on privacy by design, secure coding practices, data minimisation in system design. Include in onboarding.
- Customer-facing teams: Training on handling data subject requests, recognising and escalating potential breaches, and appropriate responses to customer privacy questions.
- Leadership: Quarterly briefing on compliance posture, regulatory developments, and risk areas.
Make it practical, not theoretical. Use your own product's data as examples. Test with scenarios: "A customer emails asking for all their data. What do you do?"
Quick-Start Priority Order
If you're building compliance from scratch, tackle these in order of risk and visibility:
| Priority | Area | Effort | Impact |
|---|---|---|---|
| 1 | Data mapping (ROPA) | 2–3 days | Foundation for everything else |
| 2 | Privacy policy | 1–2 days | Most publicly visible document |
| 3 | DPAs with vendors | 1 day (collect existing) | Immediate risk reduction |
| 4 | Cookie consent | 2–4 hours | High visibility, easy to enforce against |
| 5 | Data subject rights workflows | 1–2 weeks | Build self-service where possible |
| 6 | Security measures | Ongoing | Likely partially in place already |
| 7 | Breach notification process | 1 day | Document before you need it |
| 8 | Retention policies and automation | 1–2 weeks | Technical implementation required |
| 9 | DPO appointment (if needed) | 1 week | Outsource for speed |
| 10 | DPIAs (if applicable) | 2–4 days per assessment | Required before high-risk processing |
Tools That Accelerate Compliance
| Tool | Purpose | Cost | Best For |
|---|---|---|---|
| CookieYes / Cookiebot | Cookie consent management | Free–£200/month | All SaaS companies |
| Vanta | Compliance automation (SOC 2, ISO 27001, GDPR) | £8,000–15,000/year | Series A+ |
| Drata | Compliance automation | £8,000–15,000/year | Series A+ |
| DataGrail / Transcend | Data subject request automation | £5,000–20,000/year | High-volume DSR processing |
| DPO Centre / Privacy Culture | Outsourced DPO service | £3,000–8,000/year | Companies without in-house expertise |
| OneTrust | Enterprise privacy management | £15,000–50,000/year | Enterprise |
| PostHog (self-hosted) | Privacy-friendly analytics | Free (self-hosted) | Engineering-led teams wanting to avoid analytics DPAs |
For a deeper look at how AI is transforming compliance workflows, see How AI Is Transforming Compliance Automation.
The EU AI Act Intersection
The EU AI Act, which entered into force in stages from 2024, creates additional obligations for SaaS companies deploying AI features:
- Prohibited practices (effective February 2025): social scoring, manipulative AI, real-time biometric identification in public spaces
- High-risk AI systems (effective August 2026): AI used in employment, creditworthiness, education, law enforcement. Requires conformity assessment, risk management system, data governance, transparency, human oversight
- General-purpose AI models (effective August 2025): transparency obligations, copyright compliance, technical documentation
If your SaaS product includes AI features that fall into the high-risk category, you need both GDPR DPIAs and AI Act conformity assessments. The overlap is significant, and smart compliance programmes address both simultaneously. Penalties under the AI Act can reach up to 7% of global turnover, exceeding even GDPR's 4%.
What This Means for Your Organisation
GDPR compliance is not a project with an end date. It is an ongoing operational practice that requires sustained attention, periodic reassessment, and continuous adaptation as your product, your data processing activities, and the regulatory landscape evolve.
The good news: most of what GDPR requires is sound engineering and responsible business practice. Protect your users' data, be transparent about what you do with it, give people control over their information, and document your decisions. The regulation formalises what responsible companies already do.
The enforcement reality is this: €7.1 billion in cumulative fines and 443 breach notifications per day across Europe. Regulators are better resourced, better tooled, and more willing to pursue SMEs than at any point since GDPR took effect. The cost of compliance is real but bounded. The cost of non-compliance is unpredictable and potentially existential for a startup.
Start with the data map. Everything else follows from knowing what data you hold, why you hold it, and where it lives.
