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, 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.
Why the residency question is getting louder
The pressure behind these procurement questions is structural, not fashionable. Since the Court of Justice struck down the Privacy Shield in the Schrems II ruling, every transfer of EU personal data to the US has needed a documented transfer impact assessment and, in most readings, supplementary technical measures. The European Data Protection Board codified that expectation in its transfer recommendations, and enterprise buyers have internalised it. Hosting inside the EU is the one architecture that makes the whole question disappear.
The US CLOUD Act sharpens the point. It can compel a US-headquartered provider to disclose data it controls even when that data physically resides in an EU data centre. That is why a US firm's promise of an EU region is not the same as EU jurisdiction: the storage location and the provider's legal home are two different facts, and only the second determines who can lawfully demand the data. The concentration risk is real too — an estimated 97% of Europe's cloud infrastructure market runs on non-European providers, which is precisely the dependency the current wave of digital-sovereignty policy is trying to reduce.
For a security-tooling vendor, this is not an abstract debate. Scan output maps the weak points of a customer's production systems. If that output can be reached by a foreign legal order, the residency claim on the marketing page is worth very little. Jurisdiction, key custody and a documented sub-processor chain are what turn the claim into evidence.
Frequently Asked Questions
Does GDPR require EU data hosting?
GDPR does not force personal data to stay inside the EU, but it heavily regulates any transfer outside it. Hosting personal data in an EU data centre removes the need for transfer mechanisms entirely: no Standard Contractual Clauses, no transfer impact assessments and no ongoing monitoring of third-country surveillance law. EU residency is the simplest path to a defensible compliance position.
What did the Schrems II ruling change for data transfers?
The Court of Justice invalidated the EU-US Privacy Shield because US surveillance law could reach data held by US-based providers, even in their EU data centres. Organisations transferring data to the US must now document a transfer impact assessment and apply supplementary technical measures such as encryption with EU-held keys. Keeping the data in the EU avoids the analysis altogether.
Why does the US CLOUD Act matter if my data is stored in the EU?
The US CLOUD Act can compel a US-headquartered provider to hand over data it controls, even when that data sits in an EU data centre. This creates a direct conflict with GDPR. Using providers under EU jurisdiction, or holding encryption keys within the EU so the host cannot decrypt the data, materially reduces that exposure.
What does R2 jurisdiction=eu actually guarantee?
The R2 jurisdiction=eu flag creates a legal obligation for Cloudflare to keep the bucket’s data within EU jurisdiction and produces audit-legible configuration evidence of that choice. It does not guarantee that no data ever touches non-EU infrastructure during processing, but it is the closest available approximation to a Schrems II-aligned storage decision in the Cloudflare ecosystem.
Is fully EU-only AI inference available today?
Not from commercially available large language model APIs. AssurePort routes inference through EU edge nodes where possible and processes AI data under a GDPR-compliant DPA with Standard Contractual Clauses, and documents this in its sub-processor register. Teams requiring strict EU-only inference should treat that as an open constraint across the whole market, not a single vendor.