GDPR confuses a lot of founders because it sounds like a European problem. It's not. If any of your users are in the EU, regardless of where your company is based, GDPR applies to you.
Here's what you actually need to know.
When GDPR Applies to Your SaaS
You're subject to GDPR if you:
- Have users or customers who are EU residents (even a handful)
- Collect any personal data from EU residents (email addresses, names, usage behavior, IP addresses, payment info)
- Run analytics that track EU users
Personal data is broader than you think. An IP address is personal data. A cookie ID is personal data. An email address is personal data. If your product collects any of it from EU residents, GDPR applies.
What GDPR Actually Requires
Most founders overcomplicate this. Here's the practical list:
1. A compliant Privacy Policy Must explain: what data you collect, why you collect it, who you share it with, how long you keep it, and how users can exercise their rights (access, deletion, correction, portability).
2. A legal basis for every data collection You need a reason to collect data. The most common for SaaS:
- Legitimate interest: you need usage data to improve the product
- Contractual necessity: you need their email to deliver the service they signed up for
- Consent: required for marketing emails and non-essential cookies
3. Data Processing Agreements (DPAs) with your vendors Every vendor that processes EU user data on your behalf needs a signed DPA. This includes: your analytics tool, your email provider, your support tool, your cloud provider. Most vendors have these ready. You just need to sign them.
4. A cookie/consent banner (if you use cookies) Non-essential cookies (analytics, advertising) require consent before being set. "Reject all" must be as easy as "Accept all."
5. A way for users to exercise their rights Users can ask to see their data, delete their data, or export it. You need a process for handling these requests, even if it's just an email address.
What Makes Your Existing Docs Go Stale
This is the part founders miss. You write a privacy policy once, ship it, and forget it. Then six months later:
- You added Segment → your privacy policy doesn't mention it
- You added Mixpanel → same problem
- You started using OpenAI on user inputs → you're now processing data with an AI vendor that wasn't disclosed
- You expanded to a new cloud region → your data location statement is wrong
- You changed your retention policy → your policy says 90 days but your actual DB keeps data for a year
Any of these creates a gap between what your policy says and what your product does. That gap is a compliance risk.
The Vendor Problem
DPAs are the most commonly skipped GDPR requirement. Here's what usually happens:
- Founder signs up for a new tool
- Tool handles user data (analytics, support, email)
- No DPA signed
- Privacy policy doesn't list the tool as a subprocessor
Every vendor that touches EU personal data needs a DPA. If you're using standard SaaS tools, they almost always have DPAs available. You just need to find and sign them.
Common vendors where founders miss DPAs:
- Google Analytics / GA4: requires DPA + data processing terms
- Intercom: has a DPA, must be signed separately
- Stripe: has a DPA for EU data processing
- Sentry / error tracking: logs often contain PII
- OpenAI API: has data processing terms, must be reviewed
Cross-Border Data Transfers
If your infrastructure is in the US and you have EU users, you're making a cross-border transfer. Post-Schrems II, this requires a legal mechanism:
- Standard Contractual Clauses (SCCs): the most common; your vendors should have these in their DPAs
- EU-US Data Privacy Framework: US companies can self-certify
- Adequacy decision: some countries (UK, Canada, etc.) are deemed adequate by the EU
If your vendor doesn't have SCCs in their DPA, that's a gap.
The Practical Checklist
Before you launch to EU users, confirm:
- Privacy policy covers all data types you actually collect
- Privacy policy lists all vendors/subprocessors that handle EU data
- DPAs signed with each subprocessor (analytics, email, support, cloud)
- Legal basis documented for each data processing activity
- Cookie consent banner in place (if using non-essential cookies)
- User rights process in place (deletion, access, portability)
- Cross-border transfer mechanism in place for US-hosted data
What Breaks GDPR Compliance
The most common triggers that make your existing compliance position invalid:
| Change | Why It's a Problem |
|---|---|
| New analytics tool | Undisclosed subprocessor, missing DPA |
| New AI/LLM integration | Processing user data with undisclosed vendor |
| New cloud region | Data location statement in policy is now wrong |
| New data types collected | Privacy policy doesn't cover them |
| Changed retention period | Policy retention statement no longer accurate |
| New user-facing feature that logs behavior | Data collection expanded without disclosure |
GDPR isn't about paperwork. It's about your policy matching what your product actually does. The paperwork is easy once you understand that.