GDPR Privacy Policy for SaaS: The Complete 2026 Checklist

Why your SaaS privacy policy is a legal document, not a formality

Under GDPR, a privacy policy is a legal obligation — not a checkbox. Articles 13 and 14 of the General Data Protection Regulation require you to give data subjects specific information at the time you collect their data. Get it wrong and you're looking at DPA investigations, fines (up to €20M or 4% of global turnover), and reputational damage.

The good news: if you know what's required, writing a compliant policy isn't that complicated. Here's the complete checklist.

Article 13 vs Article 14: What's the difference?

Article 13 applies when you collect data directly from the person (signup form, checkout, contact form).
Article 14 applies when you obtain data indirectly (purchased lists, third-party integrations, public sources).

Most SaaS companies primarily deal with Art. 13. But if you enrich profiles with third-party data or buy lead lists, Art. 14 also applies.

The GDPR privacy policy checklist

✅ Identity of the data controller

Full legal name of your company
Registered address (not just a city — the actual postal address)
Contact email (a dedicated privacy@ address is best practice)

Common mistake: Using a trading name without the legal entity behind it. DPAs want the entity that can be served legal papers.

✅ Contact details of the DPO (if applicable)

Required if you're a public authority, do large-scale systematic monitoring, or process special category data at scale
Most early-stage SaaS don't need a DPO — but you should state this clearly if you've assessed it

✅ Purposes and legal bases for processing

For each purpose (account management, analytics, marketing, support, etc.): state the legal basis
Legal bases: Consent (Art. 6(1)(a)), Contract (Art. 6(1)(b)), Legal obligation (Art. 6(1)(c)), Legitimate interests (Art. 6(1)(f))
If relying on legitimate interests: briefly describe what those interests are

Common mistake: Listing "legitimate interests" as the basis for everything without explaining what those interests are. DPAs see through this.

✅ Categories of data collected

Account data (name, email, password hash)
Usage data (feature usage, session logs)
Billing data (handled by Stripe — you receive a token, not raw card data)
Communications (support tickets, email history)
Device/technical data (IP, browser, OS)

✅ Recipients or categories of recipients

List your key processors: Stripe, AWS/GCP/Azure, Intercom, Mixpanel, etc.
You don't need to list every sub-processor, but you must give users a way to see them (a link to a sub-processor list is fine)

✅ International transfers

If you use US-based services (most SaaS do), you're transferring data internationally
Post-Schrems II: rely on Standard Contractual Clauses (SCCs) for US transfers
State which transfer mechanism you use (SCCs, adequacy decision, etc.)

Common mistake: Not mentioning international transfers at all. This is one of the most common DPA complaint triggers.

✅ Retention periods

For each category of data: how long do you keep it?
"As long as necessary" is not acceptable — give actual timeframes or the criteria used to determine them
Example: Account data retained for the duration of the subscription + 90 days after cancellation

✅ Data subject rights

You must inform users they have the right to:

Access their data (Art. 15)
Rectify inaccurate data (Art. 16)
Erasure ("right to be forgotten") (Art. 17)
Restrict processing (Art. 18)
Data portability (Art. 20)
Object to processing (Art. 21)
Not be subject to automated decision-making (Art. 22)

And you must tell them how to exercise these rights (email address, response timeframe).

✅ Right to withdraw consent

If you rely on consent as a legal basis for anything: explicitly state users can withdraw consent at any time without it affecting prior processing

✅ Right to lodge a complaint with a DPA

Users must know they can complain to a supervisory authority
Link to the relevant DPA (e.g., ICO for UK users, CNIL for French users, AKI for Estonian entities)

✅ Automated decision-making and profiling

If you use AI for decisions that significantly affect users: disclose this, explain the logic, and state consequences
Most SaaS don't do this — but you still need to state that you don't

SaaS-specific additions often missed

Processing data on behalf of your customers (B2B)

If your SaaS processes personal data on behalf of business customers (e.g., your users upload their customer data), you're acting as a data processor for those customers. You need:

A Data Processing Agreement (DPA) in place with each customer
Your privacy policy should distinguish between data you collect as a controller vs. data you process as a processor

Cookie policy

Your privacy policy should either include a cookie section or link to a separate cookie policy. Under ePrivacy Directive, cookies that aren't strictly necessary require consent before setting.

Children's data

Under GDPR, processing children's data (under 16, or 13 in some member states) requires parental consent. If your service isn't intended for children, state your minimum age clearly.

How often should you update it?

Every time:

You add a new tool that processes user data
You change the purposes you process data for
EU/UK data protection law materially changes
You change your company structure (new entity, acquisition, etc.)

Keep a version history. DPAs may ask to see previous versions during investigations.

The fastest way to get a compliant policy

Writing this from scratch takes 2-4 hours. Hiring a lawyer to draft it runs €800–€3,000. ComplyKit generates a GDPR-compliant privacy policy in under 5 minutes — free, no signup required.