GDPR for SaaS: The 8 Things You Need Before Your First Paying Customer

1. A Privacy Policy That Actually Describes Your Product

Not a generic template. A policy that names the actual data you collect (email, name, usage events, payment info), why you collect each type, who you share it with, and how long you keep it. GDPR Article 13 lists exactly what must be in there.

Common failures: privacy policies that say "we may share with third parties" without listing them, policies that were generated in 2019 and never updated after adding Intercom or Segment, and policies that describe a different product entirely because they were copied from another site.

2. DPAs With Every Processor That Touches User Data

Article 28 requires a written Data Processing Agreement with every third-party processor that handles personal data on your behalf. For a typical SaaS, this list is longer than founders expect:

• →AWS / GCP / Azure — your hosting provider processes all your user data. AWS's DPA is in their Service Terms under "Data Privacy." Accept it in your account settings.
• →Stripe — processes payment data and billing information. Their DPA is available to accept in the Stripe Dashboard under Settings → Legal.
• →Intercom / Crisp / Zendesk — if it handles support tickets or in-app chat, it touches user data. All have DPAs available.
• →Mailgun / Postmark / SendGrid — your transactional email provider sends emails to your users. That's personal data processing.
• →Segment / Mixpanel / Amplitude — product analytics that receive user identifiers and events need DPAs.

Most major SaaS vendors have standard DPAs you can accept with a click. The mistake is not knowing you need to accept them, not the acceptance itself.

3. Cookie Consent (And Getting the Order Right)

Any non-essential cookie requires prior consent. "Non-essential" means anything beyond what's strictly necessary for the service to function — so session authentication cookies are fine, analytics cookies are not. The consent must happen before the cookies are set, not after.

This is where most SaaS products fail. Intercom loads on page load. Google Analytics fires on page load. The consent banner appears, but the scripts already ran. The technical implementation matters as much as having a banner at all.

4. A Working Data Deletion Mechanism

Users have the right to erasure (Article 17). You need a way to actually delete their data when requested — not just mark an account as inactive, but remove the personal data from your database, your backups pipeline, and any processors you've sent it to. You have 30 days to respond to deletion requests.

Build this before you have users, not after. Retrofitting deletion logic into a database schema that wasn't designed for it is painful. At minimum: a button in account settings that triggers account deletion and sends a deletion request to Intercom, Mailchimp, and anywhere else you've synced their data.

5. A Data Breach Response Plan (72-Hour Rule)

If you suffer a data breach that risks individuals' rights and freedoms, you must notify your supervisory authority within 72 hours of becoming aware. This is faster than most startups can move if they have no plan.

Your plan doesn't need to be elaborate. You need: the URL for your lead supervisory authority's breach notification portal, a template notification with the Article 33 required fields, and clarity on who internally decides whether a breach is notifiable.

6. Terms of Service With Data Clauses

Your ToS should explicitly address what data you collect, what users are permitted to submit (especially if your product handles personal data on their behalf), and who owns what. This matters for liability — if a user uploads a list of their customers into your product, you're suddenly a processor for their data too.

7. A Sub-Processor List

Enterprise customers will ask for this. It's the list of third parties you use to process data — your AWS region, Stripe, Mailgun, etc. Publish it in your privacy policy or on a dedicated page. Update it 30 days before adding new sub-processors (this is usually a contractual requirement in enterprise DPAs).

8. A DPA Template for Enterprise Customers

When you process personal data on behalf of your customers (which most B2B SaaS products do), you're a processor and they're the controller. They need a DPA with you. Don't wait for them to send you a 40-page custom DPA — have your own standard one ready. IAPP has free templates. Standard Contractual Clauses are available from the European Commission's website.

Having your DPA ready to share shortens enterprise sales cycles. Prospects who ask for it are serious buyers — not having one ready kills deals.