Most SaaS vendors put "GDPR-compliant" on a trust page and call it done. When you actually read the DPA and the subprocessor list, three things decide whether a tool is safe to put EU personal data into — and the trust badge tells you none of them.
I went through ten SaaS tools that show up in almost every EU company's stack (Salesforce, HubSpot, Atlassian, Intercom, Notion, Slack, Asana, monday.com, Zendesk, Calendly) and checked the same three questions for each. One pattern jumped out: EU data residency, the thing most buyers assume is table stakes, is gated behind a higher plan for half of them. One vendor gates the signed DPA itself behind a paid tier.
The three questions that actually decide it
When a DPO or a buyer vets a subprocessor, the marketing copy is noise. These three questions change the answer:
1. Can my data stay at rest in the EU? Not "do they have an EU office" — can you provision your tenant so personal data physically rests in an EU region. For some vendors this is a real toggle. For others it only exists on Enterprise.
2. What's the transfer mechanism when data leaves the EEA? Standard Contractual Clauses (SCCs), the EU-US Data Privacy Framework (DPF), or both. After Schrems II this is the part legal asks about first, and "we self-certify to the DPF" and "we fall back to SCCs" are different risk profiles.
3. Who signs the DPA, and on what plan? A self-serve DPA you accept in-product is a different thing from one that's only offered to paid customers or negotiated per contract.
What I found across 10 common vendors
| Vendor | EU data residency | Transfer mechanism | DPA |
|---|---|---|---|
| Salesforce | Available (Hyperforce DE/FR) | DPF + SCCs | Self-serve |
| HubSpot | Available | DPF + SCCs | Self-serve |
| Atlassian | Available | DPF + SCCs | Self-serve |
| Intercom | Available | DPF + SCCs | Self-serve |
| Notion | Tier-gated | SCCs | Self-serve |
| Slack | Tier-gated | DPF + SCCs | Self-serve |
| Asana | Tier-gated | SCCs | Paid tier |
| monday.com | Tier-gated | SCCs | Self-serve |
| Zendesk | Tier-gated | DPF + SCCs | Self-serve |
| Calendly | None | DPF + SCCs | Self-serve |
The part that surprises buyers
Five of the ten only offer EU data residency on higher plans. You pick a tool on the Team plan, it clears procurement, and then you find out the "data stays in the EU" guarantee needed Enterprise the whole time. Asana goes one step further: the DPA itself isn't a self-serve click on the lower tiers.
Calendly is the honest edge case. No EU-at-rest option, so invitee names, emails, and meeting metadata transfer to the US under DPF/SCCs. That isn't automatically disqualifying, but it's a call you want to make on purpose, not discover in an audit.
The four with real EU residency (Salesforce, HubSpot, Atlassian, Intercom) still hang the transfer mechanism on the DPF + SCCs combination, so "EU region selected" doesn't mean "nothing ever leaves the EEA" — support, telemetry, and sub-processors can still route data out. The residency toggle narrows the surface; it doesn't close it.
A checklist you can reuse
Before a vendor goes on the data map:
- Ask the residency question on the tier you'll actually buy, not the one on the pricing page hero.
- Get the transfer mechanism in writing (DPF, SCCs, or both) and note which one is the fallback.
- Confirm the DPA is available on your plan and screenshot the terms with a date — DPAs get revised quietly.
- Pull the current sub-processor list. The risk usually lives in the sub-processors, not the headline vendor.
I keep the per-vendor details — residency specifics, sub-processor lists, the exact transfer language, each with a source and a last-verified date — in the GDPR DPA Atlas. It's free and the individual vendor pages go deeper than the table above.
These terms change. Verify against the vendor's live DPA before you sign anything — treat this as a starting map, not a final answer.
Top comments (0)