The gap between “GDPR compliant” and “EU data residency”
GDPR compliance and EU data residency are not the same thing. GDPR compliance means you have a legal basis for processing, a privacy notice, and a process for handling data subject requests. EU data residency means the data never leaves EU-controlled infrastructure in the first place. Both matter. They solve different problems.
The confusion matters because many EU procurement teams now require data residency as a contract term, not just compliance documentation. If your infrastructure routes data through US-based CDN edge nodes before it reaches EU storage, you may have GDPR compliance paperwork in order and still fail a data residency audit.
Schrems II (CJEU C-311/18, July 2020) invalidated the EU-US Privacy Shield and established that personal data transferred to the US requires additional safeguards beyond Standard Contractual Clauses alone. The practical consequence is that data residency — keeping personal data on EU infrastructure at all times — is the cleanest way to eliminate the Schrems II analysis from your compliance posture.
What “EU data residency” means at each infrastructure layer
Data residency is not a binary property. It applies at each layer of the stack independently. A vendor can have EU compute and US-based object storage simultaneously. Here is how we think about it layer by layer.
| Layer | AssurePort choice | EU residency status | Audit evidence produced |
|---|---|---|---|
| API / compute | Cloudflare Workers (weur region) | EU West | Cloudflare regional deployment config |
| Database | Cloudflare D1 (weur region) | EU West | D1 location_hint=weur in wrangler.toml |
| Object storage | Cloudflare R2 (jurisdiction=eu) | EU jurisdiction | R2 jurisdiction flag in wrangler.toml |
| Scan compute | Fly Machines (Frankfurt, fra) | Frankfurt, Germany | Fly.io region=fra in fly.toml |
| Transactional email | Resend (EU region) | EU | Resend EU region endpoint in config |
| AI inference | Anthropic Claude via Cloudflare AI Gateway | Prompt data routed through CF AI Gateway (EU edge); Anthropic processes via Claude API — Anthropic EU DPA covers this | Anthropic DPA + CF AI Gateway config |
| Billing / payments | Polar.sh (Merchant of Record) | Polar.sh handles payment data; not in AssurePort EU infra scope | Polar.sh DPA + sub-processor register |
The Cloudflare Workers regional model
Cloudflare Workers run at the edge globally by default. To constrain execution to a specific region, you set the smart_placement and location_hint configuration in wrangler.toml. This is not the same as running a dedicated VM in a specific data centre — it is a soft binding that instructs Cloudflare to prefer EU PoPs for request handling.
For D1 and R2, the regional binding is harder. D1 with location_hint=weur stores data in Western Europe. R2 with jurisdiction=eu creates a legal obligation for Cloudflare to keep data within EU jurisdiction and excludes that bucket from US government access under US data access laws. This is the meaningful distinction for Schrems II analysis.
Practical note: The R2 jurisdiction=eu flag is the closest available approximation to a Schrems II-proof storage choice within the Cloudflare ecosystem. It does not guarantee that no data ever touches non-EU infrastructure during processing, but it does produce audit-legible configuration evidence that you have made the appropriate binding choice.
EU Cloud Code of Conduct (EU CCoC)
The EU Cloud Code of Conduct (approved by the EDPB in 2021) provides a certification framework for cloud providers to demonstrate GDPR compliance. Cloudflare is not a signatory as of this writing, but has GDPR-compliant DPAs and regional data processing commitments. Fly.io operates Frankfurt machines under EU jurisdiction.
When evaluating any SaaS vendor for EU data residency requirements, the questions to ask are:
- Where is the data stored at rest? Which storage region, which jurisdiction?
- Where is the data processed? Does compute happen outside the EU at any point?
- Who are the sub-processors, and where do they process data?
- What DPA covers each sub-processor relationship?
- Is there a Standard Contractual Clause (SCC) in place for any cross-border transfers?
AssurePort publishes its sub-processor list at /trust and provides a GDPR Data Processing Addendum (DPA) at /legal/dpa.html for customers who require one as a contract term.
What “GDPR-native” actually means in practice
GDPR-native, as we use the term at AssurePort, means that EU data residency was a design constraint from the first line of infrastructure code, not a feature bolted on after a compliance audit. The practical consequences:
- No US data flows for scan results. Scan output (findings, CVSS scores, remediation steps) is stored in D1 (weur) and R2 (eu jurisdiction). It does not transit US infrastructure.
- No cross-border OTP/auth data. Magic-link tokens and OTP codes are generated and stored in Cloudflare KV (EU region) and expire within minutes.
- Scan compute in Frankfurt. The runner pool that executes Web, API, Mobile, and GitHub scan pipelines runs exclusively on Fly Frankfurt machines. Scan targets are reached from EU IPs.
- Resend EU for email. Transactional emails (OTP codes, scan completion notifications) are sent via Resend EU region endpoints. User email addresses do not leave EU infrastructure for email processing.
The honest trade-offs
EU data residency has costs. Frankfurt compute has higher latency to users in Asia-Pacific and North America than US-based infrastructure would. EU region Cloudflare Workers have a smaller PoP network for request handling than global Workers. These are conscious trade-offs for a product built specifically for the EU market, where data residency requirements are a procurement reality rather than a preference.
The trade-off we did not accept: using US-based AI inference infrastructure without a DPA. Anthropic provides a GDPR-compliant DPA and processes data under SCCs. Cloudflare AI Gateway routes inference requests through EU edge nodes where possible. This is not a complete Schrems II clean answer for AI inference, because the model runs in Anthropic’s infrastructure, but it is the current state of the art for commercially available large language model APIs, and we document it transparently in our sub-processor register.
If your compliance requirement is strict EU-only AI inference, that use case is not yet served by any commercially available API provider. If your requirement is documented GDPR safeguards for AI processing, we provide those.