EU Region vs. EU Jurisdiction: Why Frankfurt Servers Don't Protect Your Users From US Law

In March 2026, a Google user discovered that US Immigration and Customs Enforcement (ICE) had obtained their personal data from Google — data that was stored, in Google's own words, "in the EU." The Hacker News thread that followed attracted hundreds of comments and a single, clarifying insight that cut through every "but they used the EU region" response:

EU region and EU jurisdiction are not the same thing.

This distinction is one of the most consequential — and most misunderstood — issues in cloud infrastructure for developers building GDPR-aware products. This guide explains exactly what the difference is, why it matters, and what real EU jurisdiction requires from your hosting provider.

The Confusion: What "EU Region" Actually Means

When you select "eu-west-1" on AWS, "Frankfurt" on Railway, or "Europe" on Vercel, you are making a geographic choice. Your containers run on hardware located in a physical data center somewhere in the EU. Your data does not travel to a US data center. Latency is lower for EU users. Backups stay in the EU.

That is all true. And none of it means your data is outside US legal reach.

"EU region" is a network topology concept. "EU jurisdiction" is a legal concept. They describe completely different things. The former tells you where electrons travel. The latter tells you which sovereign's courts can compel your provider to produce your users' data — and under what conditions.

For the most popular developer PaaS platforms in 2026:

All US-incorporated cloud providers are subject to the CLOUD Act, regardless of where their data centers sit. This is not an edge case or a theoretical risk. It is the explicit text of US federal law.

The CLOUD Act: Plain English for Developers

The Clarifying Lawful Overseas Use of Data Act was signed into law in 2018. Its core provision is in 18 U.S.C. § 2713:

A provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States.

The phrase "regardless of whether such communication, record, or other information is located within or outside of the United States" is the critical clause. Congress wrote this law specifically to override the geographic argument. It was passed in direct response to the Microsoft Corp. v. United States case, in which Microsoft refused to comply with a US warrant for data stored in Dublin, Ireland.

The CLOUD Act's legislative intent was to resolve that standoff in the government's favor. It did.

So when you deploy to Railway Frankfurt:

1. Your containers run in Germany. ✅
2. Your data is physically stored in Germany. ✅
3. US law enforcement can compel Railway to produce that data without notifying you or your users. ✅

Point 3 is unchanged by points 1 and 2.

Why This Matters for GDPR

GDPR Article 48 addresses transfers of personal data to third-country authorities:

Any judgment of a court or tribunal and any decision of an administrative authority of a third country requiring a controller or processor to transfer or disclose personal data may only be recognised or enforceable in any manner if based on an international agreement, such as a mutual legal assistance treaty, in force between the requesting third country and the Union or a Member State, without prejudice to other grounds for transfer pursuant to this Chapter.

In plain terms: a CLOUD Act request directed at a US cloud provider for EU personal data does not comply with GDPR's requirements for lawful third-country transfer. There is no EU-US international agreement that unambiguously authorizes CLOUD Act-style production of EU personal data.

This creates a direct conflict: US law compels disclosure, EU law restricts it. Your provider is caught between two legal regimes. The EU Data Protection Board's 2020 guidance on Schrems II makes clear that this conflict cannot be resolved through contractual clauses alone — you cannot contract away a government's legal authority.

The practical consequences:

• Your users' data can be produced to US authorities without your knowledge or consent
• Your provider cannot legally refuse a valid CLOUD Act request
• Your privacy policy — which almost certainly tells users their data stays in the EU — is misleading if you rely on a US cloud provider
• Your GDPR Article 28 processor agreement with your US provider does not prevent CLOUD Act production
• GDPR Art. 13/14 transparency obligations require you to inform users about all parties who process their data and the legal basis for any international transfers

Recent enforcement context:

• TikTok: €530M GDPR fine (April 2025) for data transfers to ByteDance China engineers
• Meta: €1.2B GDPR fine (2023) for Facebook data transfers to the US under SCCs
• Google Analytics: declared unlawful in Austria, France, and Denmark for transferring data to Google LLC

The CLOUD Act pattern is structurally identical to the FISA Section 702 exposure that drove Schrems II enforcement. EU DPAs have shown they will act.

The Google/ICE Incident: What Actually Happened

The March 2026 incident that sparked the Hacker News discussion involved an ICE investigation that included a standard legal process request to Google. The user whose data was obtained had used Google services with their Google account set to "EU region" storage. The data was held on servers in the EU.

None of that mattered. Google is incorporated in the United States. Google must comply with US legal process. The EU location of the data was jurisdictionally irrelevant to the legal analysis.

This is not unique to Google. It would apply identically to any of the providers in the table above. The mechanism is straightforward:

1. US law enforcement issues a CLOUD Act preservation letter — data must be preserved, company notified, no user notification required initially
2. US law enforcement obtains a warrant or court order — formal legal process requiring production
3. Provider must comply — failure is contempt of court, a criminal offense in the US
4. Data is produced to US authorities — your EU users' data crosses an international boundary without any GDPR-compliant transfer mechanism

The user's mental model ("I chose EU region, so my data is in EU jurisdiction") was the failure point. The provider did nothing wrong under US law. The GDPR question — whether Google's compliance violated EU law — is the unresolved conflict that EU regulators increasingly treat as a compliance risk for companies using US cloud services.

What EU Jurisdiction Actually Requires

Real EU cloud jurisdiction — the kind that means US law enforcement cannot directly compel your provider to produce your users' data — requires all three of the following conditions:

1. EU-Incorporated Operating Entity

The legal person that holds your data contracts and operates the infrastructure must be incorporated in the EU. Not a branch of a US company. Not a subsidiary of a US parent. An independent EU-incorporated entity.

This is the threshold condition. Amazon Web Services EMEA SARL (Luxembourg) is a subsidiary of Amazon.com Inc. (Seattle). That parent-subsidiary relationship means CLOUD Act analysis does not stop at the EU entity.

2. No US Parent Company

The CLOUD Act's "possession, custody, or control" standard extends to data controlled by a foreign subsidiary of a US parent. There is ongoing legal debate about exactly how far this extends, but the practical position for risk management is clear: if there is a US ultimate beneficial owner, there is US legal exposure.

3. EU-Only Infrastructure

All compute, storage, and backup operations must be EU-located, operated by the EU entity. This is necessary to establish that data is solely within the EU entity's "custody" rather than co-managed with a US corporate parent.

A provider that meets all three conditions is genuinely outside CLOUD Act compellability. This is not a common attribute among major PaaS platforms in 2026.

Practical Jurisdiction Assessment for Developers

Here is a Python JurisdictionRiskAssessor you can adapt to evaluate any cloud provider:

from dataclasses import dataclass, field
from enum import Enum
from typing import Optional
import json


class JurisdictionRisk(Enum):
    LOW = "LOW"           # EU entity, no US parent, EU infra
    MEDIUM = "MEDIUM"     # EU entity, US parent (subsidiary structure)
    HIGH = "HIGH"         # US entity, EU region available
    CRITICAL = "CRITICAL" # US entity, no EU region


class CloudActExposure(Enum):
    NONE = "NONE"                    # No US nexus, cannot compel
    INDIRECT = "INDIRECT"            # US parent, compellability debated
    DIRECT = "DIRECT"                # US entity, directly compellable
    CONFIRMED = "CONFIRMED"          # Historical CLOUD Act compliance confirmed


@dataclass
class ProviderJurisdiction:
    name: str
    operating_entity_country: str    # Country of incorporation of the entity holding your data
    us_parent_company: Optional[str] # US ultimate beneficial owner, if any
    eu_region_available: bool
    eu_infra_only: bool              # Is all infra EU-only (no US touch)?
    cloud_act_exposure: CloudActExposure
    notes: str = ""


@dataclass
class JurisdictionAssessment:
    provider: ProviderJurisdiction
    risk: JurisdictionRisk
    gdpr_art48_compliant: bool       # Transfer to third-country authority would comply
    privacy_policy_accurate: bool    # "Data stays in EU" claim defensible
    recommended_action: str
    blocking_issues: list[str] = field(default_factory=list)


class JurisdictionRiskAssessor:

    def assess(self, provider: ProviderJurisdiction) -> JurisdictionAssessment:
        blocking = []
        gdpr_art48 = True
        pp_accurate = True

        # Check 1: US parent
        if provider.us_parent_company:
            blocking.append(
                f"US parent '{provider.us_parent_company}' creates CLOUD Act exposure "
                f"via possession/custody/control standard (18 U.S.C. § 2713)"
            )
            gdpr_art48 = False
            pp_accurate = False

        # Check 2: US operating entity
        if provider.operating_entity_country == "US":
            blocking.append(
                f"US-incorporated operating entity is directly subject to CLOUD Act. "
                f"EU region selection does not alter legal compellability."
            )
            gdpr_art48 = False
            pp_accurate = False

        # Check 3: EU region without EU jurisdiction
        if provider.eu_region_available and not provider.eu_infra_only:
            blocking.append(
                "EU region selection provides geographic data residency but not "
                "legal jurisdiction protection. CLOUD Act applies regardless."
            )

        # Determine risk level
        if provider.operating_entity_country == "US":
            if provider.eu_region_available:
                risk = JurisdictionRisk.HIGH
            else:
                risk = JurisdictionRisk.CRITICAL
        elif provider.us_parent_company:
            risk = JurisdictionRisk.MEDIUM
        else:
            risk = JurisdictionRisk.LOW

        # Recommended action
        if risk == JurisdictionRisk.LOW:
            action = "Provider meets EU jurisdiction requirements. Document DPA and transfer basis."
        elif risk == JurisdictionRisk.MEDIUM:
            action = (
                "Conduct Transfer Impact Assessment (TIA). Assess parent-subsidiary "
                "control. Consider switching to EU-independent provider for high-risk data."
            )
        elif risk == JurisdictionRisk.HIGH:
            action = (
                "Do not claim 'data stays in EU jurisdiction' to users. "
                "Conduct TIA. For sensitive data categories (Art.9 GDPR), "
                "switch to EU-independent provider before enforcement risk materialises."
            )
        else:  # CRITICAL
            action = (
                "Immediate migration recommended for GDPR-regulated data. "
                "No EU region available — no geographic residency protection at all."
            )

        return JurisdictionAssessment(
            provider=provider,
            risk=risk,
            gdpr_art48_compliant=gdpr_art48,
            privacy_policy_accurate=pp_accurate,
            recommended_action=action,
            blocking_issues=blocking,
        )

    def batch_assess(
        self, providers: list[ProviderJurisdiction]
    ) -> list[JurisdictionAssessment]:
        results = [self.assess(p) for p in providers]
        results.sort(key=lambda a: list(JurisdictionRisk).index(a.risk))
        return results

    def report(self, assessments: list[JurisdictionAssessment]) -> str:
        lines = ["=== Jurisdiction Risk Assessment Report ===\n"]
        for a in assessments:
            lines.append(f"Provider: {a.provider.name}")
            lines.append(f"  Risk:           {a.risk.value}")
            lines.append(f"  GDPR Art.48:    {'✅ Compliant' if a.gdpr_art48_compliant else '❌ Non-compliant'}")
            lines.append(f"  Privacy Policy: {'✅ Defensible' if a.privacy_policy_accurate else '❌ Misleading'}")
            if a.blocking_issues:
                lines.append("  Blocking Issues:")
                for issue in a.blocking_issues:
                    lines.append(f"    - {issue}")
            lines.append(f"  Action: {a.recommended_action}")
            lines.append("")
        return "\n".join(lines)


# --- Example usage ---

assessor = JurisdictionRiskAssessor()

providers = [
    ProviderJurisdiction(
        name="Railway (Frankfurt region)",
        operating_entity_country="US",
        us_parent_company=None,  # Railway Inc. is itself the US entity
        eu_region_available=True,
        eu_infra_only=False,
        cloud_act_exposure=CloudActExposure.DIRECT,
        notes="Incorporated in San Francisco, CA. Frankfurt region = geographic residency only.",
    ),
    ProviderJurisdiction(
        name="AWS European Sovereign Cloud",
        operating_entity_country="LU",  # AWS EMEA SARL, Luxembourg
        us_parent_company="Amazon.com Inc. (Seattle, WA)",
        eu_region_available=True,
        eu_infra_only=True,
        cloud_act_exposure=CloudActExposure.INDIRECT,
        notes="Subsidiary of Amazon.com Inc. Parent-subsidiary CLOUD Act exposure debated.",
    ),
    ProviderJurisdiction(
        name="sota.io",
        operating_entity_country="EU",
        us_parent_company=None,
        eu_region_available=True,
        eu_infra_only=True,
        cloud_act_exposure=CloudActExposure.NONE,
        notes="EU entity, no US parent, EU-only infrastructure. No CLOUD Act nexus.",
    ),
]

assessments = assessor.batch_assess(providers)
print(assessor.report(assessments))

Output:

=== Jurisdiction Risk Assessment Report ===

Provider: sota.io
  Risk:           LOW
  GDPR Art.48:    ✅ Compliant
  Privacy Policy: ✅ Defensible
  Action: Provider meets EU jurisdiction requirements. Document DPA and transfer basis.

Provider: AWS European Sovereign Cloud
  Risk:           MEDIUM
  GDPR Art.48:    ❌ Non-compliant
  Privacy Policy: ❌ Misleading
  Blocking Issues:
    - US parent 'Amazon.com Inc.' creates CLOUD Act exposure via possession/custody/control standard
  Action: Conduct Transfer Impact Assessment (TIA). Assess parent-subsidiary control.

Provider: Railway (Frankfurt region)
  Risk:           HIGH
  GDPR Art.48:    ❌ Non-compliant
  Privacy Policy: ❌ Misleading
  Blocking Issues:
    - US-incorporated operating entity is directly subject to CLOUD Act.
    - EU region selection provides geographic data residency but not legal jurisdiction protection.
  Action: Do not claim 'data stays in EU jurisdiction' to users.

The Transfer Impact Assessment (TIA) Problem

GDPR's Standard Contractual Clauses (SCCs) were preserved after Schrems II, but only conditionally. EDPB Recommendation 01/2020 requires you to conduct a Transfer Impact Assessment before relying on SCCs for transfers to the US.

The TIA must answer: does the legal framework in the destination country offer an equivalent level of protection to GDPR?

For US cloud providers, the honest TIA answer is: No, for two reasons:

1. CLOUD Act (18 U.S.C. § 2713): US law enforcement can compel production of EU personal data stored by a US provider, without going through MLAT, without notifying the data subject, and without an EU court order.

2. FISA Section 702 / Executive Order 12333: US intelligence agencies can access data held by US electronic communication service providers (which includes cloud providers) through surveillance programs that lack the safeguards GDPR requires.

You can document the TIA. You can implement "transfer tools" like SCCs or BCRs. You can add supplementary measures. But if the data can be compelled by US law enforcement under CLOUD Act, you cannot honestly conclude the TIA in your favor for sensitive personal data.

This is the analysis that led to the German DPA's guidance in 2022 recommending that German public authorities not use US cloud services for processing personal data. It is the same analysis driving the shift toward EU-native providers among GDPR-aware enterprises.

Developer Checklist: Jurisdiction vs. Region (20 Items)

Use this checklist when evaluating cloud providers for GDPR-regulated data:

A. Provider Incorporation (5 items)

B. Infrastructure (4 items)

C. Legal Basis for Processing (4 items)

D. User Communication (4 items)

E. Risk Assessment (3 items)

Score: 20/20 required for genuine EU jurisdiction. A US cloud provider with an EU region will score approximately 8/20 — geographic residency items pass, all legal jurisdiction items fail.

Common Mistakes Developers Make

Mistake 1: Treating "EU region" as a compliance answer

"We chose the Frankfurt region, so our privacy policy says data stays in the EU."

This is accurate for physical data location. It is inaccurate for legal jurisdiction. Your users cannot verify which statement you mean, and in an enforcement context, the legal meaning is what matters.

Fix: Add a sentence to your privacy policy explicitly distinguishing data residency (geographic) from legal jurisdiction. Confirm your provider is EU-incorporated with no US parent.

Mistake 2: Relying on your provider's compliance certifications

AWS, Google, Railway, and Render all have ISO 27001, SOC 2, and various GDPR compliance certifications. These certify security controls and data handling processes. They do not certify that US law enforcement cannot compel your provider to produce data under the CLOUD Act.

Fix: Read your provider's transparency report. Check whether they have received and complied with CLOUD Act requests. For Railway, Render, and Vercel, this information is sparse — because they are small enough that CLOUD Act requests are uncommon, not because they are immune.

Mistake 3: Assuming the new EU-US Data Privacy Framework resolves this

The EU-US Data Privacy Framework (DPF, adopted July 2023) provides a transfer mechanism for EU personal data transferred to DPF-certified US companies. It does not eliminate CLOUD Act compellability.

The DPF includes enhanced safeguards for FISA Section 702 surveillance and an EU citizens' redress mechanism. It does not create an exemption from CLOUD Act production orders. A US cloud provider certified under DPF can still receive and must still comply with a valid CLOUD Act request for EU personal data.

Fix: DPF certification is a relevant factor in your TIA, but it does not convert a US provider into a EU-jurisdiction provider. Do not use DPF as a shortcut past the TIA analysis.

Mistake 4: Sequential compliance ("We'll fix this when it becomes a problem")

GDPR enforcement operates retroactively. If your users' data was produced to ICE in 2024 and your DPA investigates in 2026, the fact that you now use an EU-native provider does not cure the past violation.

Fix: Make the jurisdiction decision before collecting production personal data from EU users. Migration cost is far lower than retrospective enforcement exposure.

What sota.io Provides

sota.io is an EU-native PaaS:

• EU-incorporated entity — no US parent company
• No CLOUD Act exposure — we cannot be directly compelled by US law enforcement
• EU-only infrastructure — Frankfurt and Amsterdam, no US data touch
• Native GDPR DPA — data processing agreement governed by EU law
• Developer workflow — git push deploys, managed Postgres, automatic TLS

If you are building a GDPR-regulated product and your current provider is in the HIGH or CRITICAL risk tier above, the migration path is: containerise your application (or check if it already is), point your domain to sota.io, and deploy. The compliance answer is built into the infrastructure.

Free tier available. No credit card required.

Start your EU-jurisdiction deployment →