Why 'EU-Hosted' Is Not the Same as 'EU-Compliant'

· Eurtifact Platform Team

Context

EU public sector procurement increasingly requires “EU-compliant” infrastructure. Most vendors respond by highlighting where their servers are located. This conflates data residency with regulatory compliance.

Physical server location is one factor. It is not the defining factor.

Compliance is about control, governance, and demonstrable sovereignty over data processing operations. Hosting in Frankfurt does not guarantee these properties.

Reality Check

Common Belief

“We host our infrastructure in EU regions, so we’re compliant with EU data sovereignty requirements.”

Why That’s Incomplete

EU data sovereignty regulations focus on who controls the data, not just where it resides.

A service hosted in an EU data center but operated by a non-EU entity, governed by non-EU law, or subject to foreign intelligence jurisdiction does not satisfy sovereignty requirements.

Example: A US-based SaaS provider using AWS eu-central-1 (Frankfurt) is EU-hosted. But if the provider is subject to CLOUD Act jurisdiction, US authorities can compel data disclosure regardless of where the servers are physically located. This creates a sovereignty gap.

GDPR Article 48 addresses this explicitly: data transfers in response to foreign government requests must go through mutual legal assistance treaties (MLATs), not direct corporate compliance. EU-hosted infrastructure under foreign legal control undermines this protection.

Engineering Implications

EU compliance requires technical controls that enforce sovereignty, not just regional deployment.

1. Legal Jurisdiction of the Operator

Requirement: The entity operating the infrastructure must be subject to EU law, not merely using EU servers.

What this means:

  • Incorporation in an EU member state
  • Data processing agreements governed by EU law
  • No parent company or headquarters in jurisdictions with extraterritorial data access laws (CLOUD Act, National Security Letters)

Common failure: Subsidiaries of US corporations operating “EU regions” while the parent company retains administrative access and legal obligations to foreign governments.

2. Access Control and Key Management

Requirement: Encryption keys and administrative credentials must not be accessible to entities outside EU jurisdiction.

What this means:

  • Customer-managed encryption keys (CMEK) with hardware security modules (HSMs) located in the EU
  • No “break-glass” or “lawful access” mechanisms controlled by non-EU entities
  • Role-based access control (RBAC) ensuring no foreign personnel have privileged access to customer data

Common failure: Cloud providers offering EU regions but retaining global support teams with administrative access for troubleshooting.

3. Data Processing Agreements and Subprocessors

Requirement: All subprocessors (third-party services, monitoring tools, support vendors) must also be EU-compliant.

What this means:

  • Comprehensive subprocessor lists disclosing jurisdiction and access scope
  • Contractual terms prohibiting data transfer outside the EU
  • Regular audits of subprocessor compliance

Common failure: Using EU-based compute but routing logs, metrics, or telemetry to US-based observability platforms (Datadog US, New Relic, Splunk Cloud).

4. Organizational and Technical Measures (Article 32 GDPR)

Requirement: Technical measures to prevent unauthorized access, including from the service provider itself.

What this means:

  • Data minimization: collect only what’s necessary
  • Pseudonymization and anonymization where possible
  • Multi-tenancy isolation enforced at the database level (row-level security)
  • Audit logging of all privileged access attempts

Common failure: Shared SaaS platforms where the vendor can query customer data for “support purposes” without explicit per-request authorization.

Failure Modes

Pattern 1: Hosted in the EU, Controlled Elsewhere

A vendor deploys infrastructure in Hetzner (Germany) but operates from a US-based parent company. Support tickets, admin access, and disaster recovery procedures are managed by teams in the US.

Why this fails: Legal control remains with the US entity. CLOUD Act applies. Data can be compelled without EU oversight.

Pattern 2: EU Hosting with Non-EU Subprocessors

A vendor uses OVH (France) for compute but routes application logs to Datadog (US), error tracking to Sentry (US), and analytics to Google Analytics.

Why this fails: Personal data flows to non-EU processors. GDPR Article 28 requires Data Processing Agreements with all subprocessors. Cross-border transfers require Standard Contractual Clauses (SCCs) or Adequacy Decisions, neither of which eliminate foreign jurisdiction risk.

Pattern 3: Compliance Theater

A vendor publishes a “GDPR-compliant” badge, lists EU data centers, and provides a generic Data Processing Agreement template downloaded from a legal website.

Why this fails: Compliance is not a document. It is an operational state. Auditors will request evidence of technical controls, subprocessor audits, access logs, and incident response procedures. Generic templates do not satisfy these requirements.

What “Good” Looks Like

A genuinely EU-compliant infrastructure system has these properties:

  1. Legal Sovereignty: The operating entity is incorporated in the EU, governed by EU law, and has no foreign parent company with conflicting legal obligations.

  2. Technical Sovereignty: Encryption keys, access credentials, and administrative interfaces are exclusively controlled by EU-based personnel. No foreign entity has privileged access, even for support or disaster recovery.

  3. Processor Transparency: All subprocessors are disclosed, categorized by function, and subject to EU jurisdiction. Data Processing Agreements explicitly prohibit cross-border transfers.

  4. Audit Trail: Access logs, configuration changes, and privileged operations are immutably recorded and available for regulatory inspection. Logs demonstrate that no unauthorized foreign access occurred.

  5. Contractual Enforceability: Service agreements specify EU-exclusive jurisdiction for dispute resolution, prohibit foreign data requests, and include termination rights if sovereignty is compromised.

These are system properties, not marketing claims.

Limits & Trade-offs

This approach does not:

  • Eliminate all foreign dependencies: Open-source software, firmware, and hardware often originate outside the EU. True digital sovereignty would require EU-designed chips and operating systems, which do not yet exist at scale.
  • Guarantee zero foreign access: Sophisticated state actors can compromise systems regardless of jurisdiction. Sovereignty reduces legal exposure, not technical risk.
  • Resolve geopolitical uncertainty: Future EU-US data transfer frameworks (post-Privacy Shield, post-Schrems II) may change legal requirements. Compliance is a moving target.

Sovereignty is about reducing the surface area for foreign legal compulsion. It is not absolute protection.

Key Takeaways

  • Hosting in EU regions satisfies data residency. It does not satisfy sovereignty unless the operator, keys, and subprocessors are also EU-controlled.
  • GDPR Article 48 prohibits responding to foreign government data requests without MLATs. This protection is undermined if the service provider is subject to foreign jurisdiction.
  • Technical controls (CMEK, RBAC, audit logging) must enforce sovereignty. Organizational structure determines whether these controls are meaningful or theatrical.
  • Procurement teams should ask: Who can access our data? Under what legal framework? What happens if a foreign government requests it?
  • Compliance is demonstrated through technical evidence, not policy documents. Auditors will request logs, key management procedures, and subprocessor audit reports.

This article reflects the Eurtifact platform team’s understanding of EU digital sovereignty requirements as of February 2026. It is not legal advice. For compliance questions specific to your procurement or deployment, consult qualified legal counsel.