2026-04-27·14 min read·

EU Region vs EU Jurisdiction: Why Railway Frankfurt Is Still Under US Law

Hosting your application in Railway's EU West (Frankfurt) region, Render's Frankfurt data center, or Fly.io's Amsterdam and Paris regions does not remove your data from US legal jurisdiction. This is the most consequential misunderstanding in cloud infrastructure compliance in 2026 — and it affects every SaaS developer making hosting decisions for GDPR-sensitive workloads, NIS2-classified services, and EU AI Act Annex III deployments.

The distinction is between data residency and data jurisdiction. Data residency describes the physical location of servers. Data jurisdiction describes which country's laws can compel access to that data. A Frankfurt server operated by a Delaware-incorporated company is resident in Germany but jurisdictionally subject to US law. GDPR compliance and physical EU location do not change this.

What the CLOUD Act Actually Says

The Clarifying Lawful Overseas Use of Data Act (CLOUD Act, Pub. L. 115-141, 18 U.S.C. §2703(h)) was enacted in 2018. Its operative clause is precise: 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 italicised phrase is the entire problem. "Regardless of whether such communication, record, or other information is located within or outside of the United States" — location of the physical server is explicitly irrelevant to the statute.

The legal basis for compelled disclosure is the provider's possession, custody, or control of the data. For a US-incorporated company operating a Frankfurt data center, the Frankfurt servers are within the corporate entity's control. The US parent company can access the data. The US government can therefore compel the US parent to produce it.

The Affected Providers

Three infrastructure providers widely used by European developers operate under this structure:

Railway is incorporated in the United States (Delaware). Its EU West region uses data centers in Frankfurt, Germany. Railway's Terms of Service and Privacy Policy are governed by California law. CLOUD Act demands to Railway Inc. can compel disclosure of data stored on Railway's Frankfurt infrastructure.

Render is incorporated in the United States (Delaware). Render's Ohio infrastructure serves US workloads; European customers may use Frankfurt-proximate infrastructure depending on service configuration. CLOUD Act jurisdiction follows the Delaware incorporation.

Fly.io is incorporated in the United States. Fly.io operates regions in Amsterdam (ams), Paris (cdg), Stockholm (arn), and Warsaw (waw). The European region label does not affect Fly.io's status as a US legal entity subject to CLOUD Act compulsion.

Heroku (Salesforce subsidiary) is a US company with EU infrastructure. Same analysis applies.

Vercel is incorporated in the United States. Edge functions running in Frankfurt or Amsterdam remain under US corporate jurisdiction for CLOUD Act purposes.

This is not a critique of these providers' security practices, uptime, or engineering quality. It is a statement about their legal structure and the resulting exposure under US law.

A common misconception is that GDPR Articles 44–49 restrict transfers to the US, and that a CLOUD Act production order would constitute a restricted transfer that the provider could lawfully refuse. This analysis is incorrect.

GDPR Chapter V (Art.44–49) governs transfers of personal data to third countries initiated by the controller or processor. A CLOUD Act production order is not a transfer initiated by the data controller. It is a compelled disclosure by a US court order directed to the provider as a US legal entity.

The European Court of Justice addressed adjacent issues in Schrems I (C-362/14, 2015) and Schrems II (C-311/18, 2020). Schrems II invalidated the Privacy Shield adequacy decision precisely because US surveillance law — including FISA 702, Executive Order 12333, and the intelligence community's access to cloud data — was incompatible with GDPR's essential equivalence requirement. The ECJ did not hold that GDPR prevents US law enforcement access; it held that the existence of that access mechanism prevented the US from qualifying as a country with adequate data protection.

The EU Data Act (Regulation (EU) 2023/2854, applying since 12 September 2025) introduced Art.32, which requires cloud service providers to take "all reasonable legal, technical and organisational measures" to prevent unlawful third-country government access. Art.32(4) requires providers to notify the affected party of any access request before complying, and to challenge requests that lack a valid legal basis. This creates a procedural obligation — but Art.32 does not give a EU-based provider the legal standing to override a valid US court order against a US parent company. The US corporate entity must comply with a facially valid CLOUD Act warrant issued by a US federal court regardless of Art.32 obligations in the EU Data Act.

Python: CloudActExposureAnalyzer

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


class JurisdictionRisk(Enum):
    LOW = "low"           # EU-incorporated, no US parent, no substantial US nexus
    MEDIUM = "medium"     # EU-incorporated with US investors or US-listed parent
    HIGH = "high"         # US-incorporated, EU data centers
    CRITICAL = "critical" # US-incorporated, US intelligence contractor relationships


@dataclass
class ProviderJurisdictionProfile:
    provider_name: str
    country_of_incorporation: str
    us_parent_or_owner: Optional[str]
    eu_data_center_locations: list[str]
    cloud_act_exposure: bool
    jurisdiction_risk: JurisdictionRisk
    gdpr_transfer_mechanism: str
    eu_data_act_art32_challenge_feasible: bool
    notes: str


@dataclass
class WorkloadJurisdictionRequirement:
    workload_type: str
    regulation: str
    requires_eu_jurisdiction: bool
    rationale: str


def analyze_cloud_act_exposure(
    country_of_incorporation: str,
    us_parent: Optional[str],
    has_substantial_us_operations: bool,
) -> tuple[bool, JurisdictionRisk]:
    if country_of_incorporation.upper() == "US":
        return True, JurisdictionRisk.HIGH
    if us_parent is not None:
        return True, JurisdictionRisk.MEDIUM
    if has_substantial_us_operations:
        return True, JurisdictionRisk.MEDIUM
    return False, JurisdictionRisk.LOW


PROVIDER_PROFILES: list[ProviderJurisdictionProfile] = [
    ProviderJurisdictionProfile(
        provider_name="Railway",
        country_of_incorporation="US",
        us_parent_or_owner=None,
        eu_data_center_locations=["Frankfurt, DE"],
        cloud_act_exposure=True,
        jurisdiction_risk=JurisdictionRisk.HIGH,
        gdpr_transfer_mechanism="Standard Contractual Clauses",
        eu_data_act_art32_challenge_feasible=False,
        notes="Delaware incorporation. EU West Frankfurt region. CLOUD Act demands enforceable against Railway Inc.",
    ),
    ProviderJurisdictionProfile(
        provider_name="Render",
        country_of_incorporation="US",
        us_parent_or_owner=None,
        eu_data_center_locations=["Frankfurt, DE"],
        cloud_act_exposure=True,
        jurisdiction_risk=JurisdictionRisk.HIGH,
        gdpr_transfer_mechanism="Standard Contractual Clauses",
        eu_data_act_art32_challenge_feasible=False,
        notes="Delaware incorporation. CLOUD Act demands enforceable against Render Inc.",
    ),
    ProviderJurisdictionProfile(
        provider_name="Fly.io",
        country_of_incorporation="US",
        us_parent_or_owner=None,
        eu_data_center_locations=["Amsterdam, NL", "Paris, FR", "Stockholm, SE", "Warsaw, PL"],
        cloud_act_exposure=True,
        jurisdiction_risk=JurisdictionRisk.HIGH,
        gdpr_transfer_mechanism="Standard Contractual Clauses",
        eu_data_act_art32_challenge_feasible=False,
        notes="US incorporation. European region labels (ams, cdg, arn, waw) do not affect jurisdiction.",
    ),
    ProviderJurisdictionProfile(
        provider_name="Vercel",
        country_of_incorporation="US",
        us_parent_or_owner=None,
        eu_data_center_locations=["Frankfurt, DE", "Amsterdam, NL", "Paris, FR"],
        cloud_act_exposure=True,
        jurisdiction_risk=JurisdictionRisk.HIGH,
        gdpr_transfer_mechanism="Standard Contractual Clauses",
        eu_data_act_art32_challenge_feasible=False,
        notes="US incorporation. Edge function execution in EU regions does not create EU jurisdiction.",
    ),
    ProviderJurisdictionProfile(
        provider_name="Hetzner",
        country_of_incorporation="DE",
        us_parent_or_owner=None,
        eu_data_center_locations=["Nuremberg, DE", "Falkenstein, DE", "Helsinki, FI"],
        cloud_act_exposure=False,
        jurisdiction_risk=JurisdictionRisk.LOW,
        gdpr_transfer_mechanism="No transfer required (EU controller to EU processor)",
        eu_data_act_art32_challenge_feasible=True,
        notes="German GmbH. No US parent. Subject to German and EU law only. No CLOUD Act exposure.",
    ),
    ProviderJurisdictionProfile(
        provider_name="sota.io",
        country_of_incorporation="DE",
        us_parent_or_owner=None,
        eu_data_center_locations=["Germany"],
        cloud_act_exposure=False,
        jurisdiction_risk=JurisdictionRisk.LOW,
        gdpr_transfer_mechanism="No transfer required (EU controller to EU processor)",
        eu_data_act_art32_challenge_feasible=True,
        notes="German entity. No US parent or owner. Infrastructure in Germany. CLOUD Act does not apply.",
    ),
]

WORKLOAD_REQUIREMENTS: list[WorkloadJurisdictionRequirement] = [
    WorkloadJurisdictionRequirement(
        workload_type="EU AI Act Annex III High-Risk AI System",
        regulation="EU AI Act Art.10, Art.12, Art.17",
        requires_eu_jurisdiction=True,
        rationale="Technical documentation and logs under Art.12 must be available to NCA market surveillance. US CLOUD Act access would create a parallel access channel outside NCA control.",
    ),
    WorkloadJurisdictionRequirement(
        workload_type="NIS2-classified Essential Service",
        regulation="NIS2 Art.21, NCAF 2.0",
        requires_eu_jurisdiction=True,
        rationale="NIS2 Art.21(2)(i) supply chain security requires assessment of provider jurisdiction. NCAF 2.0 identifies US CLOUD Act exposure as a supply chain risk factor.",
    ),
    WorkloadJurisdictionRequirement(
        workload_type="GDPR Special Category Data (Art.9)",
        regulation="GDPR Art.9, Art.32, Art.44–49",
        requires_eu_jurisdiction=True,
        rationale="Schrems II established that US intelligence access to EU-stored data is incompatible with adequate GDPR protection. Special category data demands the highest protection level.",
    ),
    WorkloadJurisdictionRequirement(
        workload_type="DORA-regulated Financial Service",
        regulation="DORA Art.28–44 (ICT Third-Party Risk)",
        requires_eu_jurisdiction=False,
        rationale="DORA Art.30 requires contractual provisions on data location and accessibility, but does not mandate EU-only jurisdiction. However, competent authority access rights under Art.42 favour EU providers.",
    ),
    WorkloadJurisdictionRequirement(
        workload_type="Standard SaaS B2B (no regulated data)",
        regulation="GDPR Art.28 (processor agreement)",
        requires_eu_jurisdiction=False,
        rationale="Standard SCCs with US providers remain a valid transfer mechanism post-Schrems II for non-special-category data, subject to transfer impact assessment.",
    ),
]


def assess_workload_provider_match(
    workload: WorkloadJurisdictionRequirement,
    provider: ProviderJurisdictionProfile,
) -> dict:
    compliant = True
    issues = []

    if workload.requires_eu_jurisdiction and provider.cloud_act_exposure:
        compliant = False
        issues.append(
            f"{provider.provider_name} is subject to CLOUD Act despite EU data center presence."
        )

    if provider.cloud_act_exposure and workload.regulation.startswith("GDPR Art.9"):
        compliant = False
        issues.append(
            "Schrems II incompatibility: US jurisdiction over special category data."
        )

    return {
        "workload": workload.workload_type,
        "provider": provider.provider_name,
        "compliant": compliant,
        "issues": issues,
        "recommendation": "Use EU-incorporated provider" if not compliant else "Proceed with transfer impact assessment",
    }


if __name__ == "__main__":
    regulated_workloads = [w for w in WORKLOAD_REQUIREMENTS if w.requires_eu_jurisdiction]
    us_providers = [p for p in PROVIDER_PROFILES if p.cloud_act_exposure]

    for workload in regulated_workloads:
        for provider in us_providers:
            result = assess_workload_provider_match(workload, provider)
            if not result["compliant"]:
                print(f"NON-COMPLIANT: {result['workload']} on {result['provider']}")
                for issue in result["issues"]:
                    print(f"  → {issue}")

The DPA Transfer Impact Assessment Problem

Since Schrems II, GDPR Art.46 transfers (including Standard Contractual Clauses) require a Transfer Impact Assessment (TIA) that evaluates whether the destination country's legal framework provides essentially equivalent protection to EU standards.

For transfers to US-parent-company cloud providers, the TIA must account for:

FISA 702 (50 U.S.C. §1881a) — permits surveillance of non-US persons' communications stored by US-based electronic communication service providers without individual warrant
Executive Order 12333 — permits NSA collection of data in transit outside US borders
CLOUD Act — permits law enforcement compelled disclosure of data stored anywhere by US companies
PATRIOT Act (now USA FREEDOM Act) — national security letter (NSL) authority for business records

The Data Protection Authority of the European Data Protection Board (EDPB) Recommendations 01/2020 on supplementary measures identify that no purely contractual or organisational measure can substitute for technical impossibility of access when the legal basis for access under US law is facially valid. Only customer-held encryption keys, with the provider never holding plaintext, can close this gap — and this requires architectural choices, not just provider selection.

Choosing Railway Frankfurt with SCCs does not complete a valid TIA for NIS2-classified, AI Act Annex III, or GDPR Art.9 workloads. The CLOUD Act exposure survives the SCC mechanism.

What "EU Jurisdiction" Actually Means

For a provider to be outside US CLOUD Act jurisdiction, it must satisfy three conditions:

Incorporated in an EU member state — not UK (post-Brexit), not Switzerland, not Norway. EU incorporation means German GmbH, French SAS, Dutch BV, etc.
No US parent company or controlling shareholder — a German company owned by a US investment fund or US parent corporation may have CLOUD Act exposure through the parent
No substantial US operations or US-listed securities — companies cross-listed on US exchanges or with substantial US business presence may be subject to US jurisdiction through other mechanisms

The Frankfurt data center alone satisfies none of these conditions.

EU Data Act Art.32 — What It Does and Doesn't Do

The EU Data Act Art.32 (applying since 12 September 2025) imposes obligations on cloud service providers to:

Implement technical and organisational measures to prevent unlawful third-country government access
Notify the affected data holder of any government access request before disclosure, to the extent legally permissible
Challenge the request if it lacks a valid legal basis under EU law or the law of an EU member state

Art.32 creates a procedural firewall for EU-incorporated providers. A German GmbH serving as cloud provider must challenge a foreign government request that lacks EU-law basis. This is meaningful for EU providers facing non-EU government demands.

For US providers, Art.32 creates an interesting dual obligation: the Frankfurt entity must challenge under EU law, while the US parent entity must comply with a valid US court order. This creates legal friction — but legal friction at the provider level does not protect the customer's data if the US parent ultimately produces it to US law enforcement. The question is whether the US corporate structure can be legally isolated from EU subsidiary obligations, and in general, it cannot for purposes of customer data protection.

Practical Implications for Infrastructure Selection

The jurisdiction analysis produces clear guidance for specific workload categories:

EU AI Act Annex III High-Risk AI systems (August 2026 deadline): Art.12 audit log availability to NCAs, Art.17 technical documentation, and Art.9 risk management system records should be stored with EU-jurisdiction providers. US provider exposure creates a secondary access channel that NCAs have not been given authority to govern.

NIS2 Art.21 compliance (June 30, 2026 audit checkpoint): ENISA's NCAF 2.0 framework (April 2026) identifies supply chain jurisdiction as a security measure category. Using US-parent providers as essential infrastructure without addressing CLOUD Act exposure in the supply chain security documentation creates audit findings.

GDPR special category data (Art.9): The Schrems II TIA outcome for US providers processing Art.9 data (health, biometric, ethnic, political, religious) is negative without customer-held encryption. SCCs alone are insufficient.

Standard developer tooling and non-personal build infrastructure: CLOUD Act exposure is lower risk. The cost-benefit of EU-jurisdiction providers is less compelling for CI/CD pipelines, development environments, and non-personal-data services.

The Sovereignty Architecture

True jurisdictional sovereignty at the infrastructure layer requires one of three designs:

Option 1: EU-incorporated provider with no US parent. The data never enters a legal entity subject to CLOUD Act. This is the simplest approach and requires no additional technical measures beyond standard security practices.

Option 2: Customer-held encryption with any provider. If the customer holds the encryption keys and the provider never has access to plaintext, a CLOUD Act production order yields only ciphertext. This requires Key Management as a Service under customer control (e.g., AWS KMS with customer-managed keys where the key never leaves the customer's HSM) and is architecturally complex for most SaaS applications.

Option 3: Hybrid with data classification. Personal data and regulated data on EU-jurisdiction providers; non-personal infrastructure (CDN edges, build caches, analytics aggregates) on US providers with appropriate TIAs and contractual safeguards.

Most SaaS developers building GDPR-regulated applications benefit most from Option 1 for their application backend and database layer. The operational simplicity of eliminating the TIA requirement and CLOUD Act exposure documentation from compliance audits is itself a business advantage.

Jurisdiction Due Diligence Checklist

#	Check	Railway Frankfurt	Hetzner / sota.io
1	EU incorporation?	✗ (US Delaware)	✓
2	No US parent/owner?	✗ (US company)	✓
3	No US-listed securities?	✗	✓
4	CLOUD Act exposure?	✓ (exposed)	✗
5	Valid SCCs for transfers?	Required	Not required
6	TIA completed?	Required	Not required
7	EU Data Act Art.32 challenge feasible?	Limited	✓
8	NIS2 Art.21(2)(i) supply chain pass?	Risk item	✓
9	GDPR Art.9 TIA outcome?	Negative without encryption	Not required
10	AI Act Art.12 NCA access guaranteed?	No (US parallel channel)	✓
11	ENISA NCAF 2.0 supply chain risk?	High	Low
12	DPA enforcement action risk?	Present	Absent
13	Incident reporting jurisdiction?	US + DE dual	DE only
14	Contractual law governing DPA?	California	German/EU
15	Subprocessor chain EU-clean?	Requires audit	Shorter chain