GDPR Compliance Checklist for SaaS Teams Selling in the EU

TL;DR

• GDPR applies if you process personal data of EU residents — regardless of where your company is incorporated.
• Operational essentials: data map, documented legal basis, public privacy notice + subprocessor list, DPAs, DSAR workflow, retention policy, DPIA program.
• Non-EU companies must appoint an Article 27 EU representative. Maximum fines reach €20 million or 4% of global annual turnover.

Selling into the EU means GDPR applies to you. It does not matter where your company is incorporated, where your servers sit, or whether you have a single employee in Europe. If you process personal data of people in the EU, you are in scope.

Most SaaS teams know this in the abstract. Fewer have actually worked through what compliance requires in practice. This checklist covers the operational work — the things you need to build, document, and maintain to sell confidently in EU markets.

If you want the broader operational framing, start with our GDPR operations guide.

Who GDPR Actually Applies To

GDPR's territorial scope is defined in Article 3. It applies when:

• You are established in the EU and process personal data in the context of that establishment, regardless of where processing happens.
• You are not established in the EU but offer goods or services to people in the EU, or monitor the behavior of people in the EU.

For B2B SaaS, the second condition is the one that catches most companies. If your product has EU users — even if those users are employees of your customer — GDPR applies. You are typically a data processor (processing on behalf of your customer, the controller), but you are also a controller for your own business data: employee records, marketing contacts, website analytics, support tickets.

Understanding your role — controller, processor, or both — determines which obligations apply to each data flow.

The Checklist

Data Mapping and Records of Processing

Article 30 requires you to maintain records of processing activities (ROPA). This is not optional for most SaaS companies.

• Inventory every system that stores or processes personal data.
• Document data categories, data subjects, purposes, legal basis, retention periods, and recipients for each processing activity.
• Identify where you act as controller vs. processor.
• Map data flows across systems, including third-party integrations.
• Record cross-border transfers and the transfer mechanism used.

Start with a spreadsheet if you need to. The format does not matter. The completeness does.

Legal Basis for Processing

Every processing activity needs a valid legal basis under Article 6. The six options are consent, contract, legal obligation, vital interests, public task, and legitimate interests.

• Map each processing activity to its legal basis.
• For legitimate interests, document the balancing test (your interest vs. the data subject's rights).
• For consent, ensure it is freely given, specific, informed, and unambiguous. Pre-ticked boxes do not count.
• Record where and when consent was obtained, and provide a clear withdrawal mechanism.

Most B2B SaaS processing relies on contract performance (for customer data) and legitimate interests (for marketing and product improvement). Consent is typically reserved for cookies and optional communications.

Data Processing Agreements

If you process personal data on behalf of customers, you need a DPA under Article 28.

• Prepare a standard DPA that covers scope, duration, nature and purpose of processing, data categories, and data subject types.
• Include required clauses: security measures, sub-processor obligations, breach notification timelines, audit rights, data return and deletion.
• Make your DPA available for customer review. Many SaaS companies publish it on their website.
• Track which customers have signed DPAs and which version they signed.

Privacy Notices and Consent

Transparency is a core GDPR principle. Your privacy notice must explain what you collect, why, and what rights people have.

• Publish a privacy policy covering all Article 13/14 requirements.
• Implement a cookie consent mechanism that blocks non-essential cookies until consent is given.
• Provide layered notices — short summaries with links to full details.
• Keep notices updated when processing activities change.

DSAR Workflow

Data subjects can exercise their rights at any time: access, rectification, erasure, restriction, portability, and objection. You need a process to handle these requests within 30 days.

• Define an intake channel (email, web form, in-app).
• Build a verification process to confirm the requester's identity.
• Document how you search for and compile data across all systems.
• Set up internal routing and tracking so nothing falls through the cracks.
• Template your responses.

For a detailed breakdown, see our DSAR workflow guide.

Data Retention and Deletion

GDPR's storage limitation principle means you cannot keep personal data indefinitely.

• Define retention periods for each data category and document the justification.
• Implement automated deletion or anonymization when retention periods expire.
• Handle deletion requests from data subjects within 30 days.
• Ensure backups are included in your deletion process — or document why delayed deletion from backups is necessary and what safeguards are in place.

DPIA Process

A Data Protection Impact Assessment is required when processing is likely to result in high risk to individuals. This includes large-scale profiling, systematic monitoring, and processing of sensitive data.

• Define criteria for when a DPIA is triggered in your organization.
• Create a DPIA template covering the processing description, necessity assessment, risk evaluation, and mitigation measures.
• Conduct DPIAs before launching new features or integrations that involve high-risk processing.
• Consult your supervisory authority if residual risk remains high after mitigation.

Breach Notification

You must notify your supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in risk to individuals.

• Define what constitutes a breach in your context.
• Build an incident response plan with clear roles, escalation paths, and communication templates.
• Maintain a breach register — even for breaches you decide not to report.
• Include processor-to-controller notification obligations in your DPAs (typically 24-48 hours).

Sub-processor Management

If you use third-party services that process personal data on your behalf, those are sub-processors.

• Maintain a list of sub-processors with their processing purpose and location.
• Ensure each sub-processor has a DPA in place with equivalent protections.
• Implement a sub-processor change notification process (most customers expect 30 days' notice).
• Assess sub-processor security posture before onboarding.

This overlaps heavily with vendor risk management — the same process serves both GDPR and frameworks like SOC 2.

Cross-border Transfers

Transferring personal data outside the EU/EEA requires a valid transfer mechanism.

• Identify all transfers to countries without an adequacy decision.
• Implement Standard Contractual Clauses (SCCs) for transfers to non-adequate countries.
• Conduct Transfer Impact Assessments (TIAs) to evaluate the legal framework in the recipient country.
• Monitor adequacy decisions — the landscape changes (the EU-US Data Privacy Framework is one example).

Common Mistakes SaaS Companies Make

Treating GDPR as a legal project. Legal reviews the policy, but engineering builds the deletion pipeline, product designs the consent flow, and support handles DSARs. GDPR is cross-functional.

Ignoring processor obligations. Many SaaS companies focus on their controller responsibilities and forget that as a processor, they have independent obligations: security, breach notification to controllers, and maintaining processing records.

No retention schedule. Data accumulates. Without defined retention periods and automated enforcement, you are storing data longer than you can justify — which is a violation in itself.

Cookie consent theater. Banners that say "By continuing to browse, you accept cookies" are not valid consent. If you are dropping analytics or marketing cookies without affirmative opt-in, you are non-compliant.

Assuming adequacy covers everything. Even with the EU-US Data Privacy Framework, you need to verify your specific sub-processors are certified and that your transfer mechanisms are current.

Building GDPR Into Operations

GDPR compliance is not a one-time project. It is an ongoing operational commitment. The regulation requires you to demonstrate compliance at any point — not just during an audit.

Build GDPR into your existing workflows. Tie data mapping to your change management process. Run DSAR drills quarterly. Review retention schedules when you add new features. Assess sub-processors during vendor onboarding, not after.

If you are also working toward SOC 2 or ISO 27001, there is significant overlap. Privacy controls, access management, incident response, and vendor management all serve multiple frameworks. Build once, map to many.

Need help turning this checklist into a working compliance program? Explore our services or get in touch to talk through your GDPR readiness.