"We host in the EU" appears in many proposals and satisfies few procurement teams for long, because it can mean several different things. This article separates the guarantees that selecting an EU region gives you from the ones it does not, and describes how to design for each.
Four different questions
When an organisation asks for EU hosting it usually has one or more of the following in mind:
- Data residency. Where is my data stored and processed?
- Data access. Who can reach it, including the provider's own staff?
- Operational locality. Where does support happen, and where are backups and logs kept?
- Legal exposure. Which laws can compel disclosure of my data?
Choosing a region answers the first question well, the second and third partly, and the fourth not at all on its own.
What choosing a region does
On all three major providers, selecting a region such as Frankfurt, Paris, Dublin or Stockholm means that the core storage and compute services you deploy there keep customer data at rest within that region. Databases, object storage, virtual machines and container platforms follow this rule, and the providers document it.
Backups, replicas and disaster-recovery copies follow the configuration you choose. Replicating to a second EU region is straightforward; replicating outside the EU is a decision you would have to make explicitly.
What a region does not settle
Global services. Some services are inherently global or have components that are. Identity services, content delivery networks, DNS, some AI and machine learning services, and support tooling may process metadata or, in some cases, content outside the region. Each provider publishes which services are regional and which have exceptions. Read that list for every service in your architecture, not just the obvious ones.
Telemetry and support data. Diagnostic logs, usage metrics and the data engineers see when handling a support ticket may be processed centrally. Providers offer controls to restrict this, and enterprise agreements can commit to EU-only support handling for some services, but it is a separate configuration and often a separate contractual term.
Provider staff access. Provider engineers can, under controlled procedures, access infrastructure for operations and support. Each provider publishes how this is governed and offers features that require your approval before access to your data, or that give you sole control of encryption keys. These features exist, but you have to turn them on.
Legal exposure. All three providers are headquartered in the United States and are subject to United States law, including legislation that can compel the disclosure of data held by a United States company regardless of where it is stored. The providers publish the requests they receive, contest overbroad ones, and note how rarely such requests concern enterprise customers. The exposure is small, but a region does not remove it. Only the design of your own controls, above all key management, changes what such a request could yield.
Designing for the guarantee you actually need
Most organisations need a defensible position, not an absolute one. The following measures, in increasing order of effort, give progressively stronger guarantees.
1. Regional discipline
Deploy only regional services in EU regions, list every exception, and configure backups and logs to stay in the EU. Document the list. This is the minimum for any credible EU hosting claim and it costs little beyond care.
2. Encryption with keys you control
Use the provider's key-management service with customer-managed keys for everything that supports it, so data is encrypted at rest with keys whose use you can audit and revoke. For the highest sensitivity, use keys held outside the provider entirely, in a hardware module or a third-party key service, so the provider cannot decrypt your data without your system participating. This is the single most effective control against both operational and legal access, and it is available on all three providers.
3. Restricted support and access approval
Turn on the features that require your approval before provider staff access your data, and use enterprise support terms that keep support handling within the EU where the provider offers them. Review the audit logs these features produce.
4. Sovereign and partner-operated options
All three providers now offer or are developing options operated in whole or part by EU entities, with additional legal and operational separation. They cost more, support fewer services and evolve quickly. They are appropriate where regulation or contracts require them, and unnecessary for most commercial workloads.
Do not forget the rest of the chain
Your cloud provider is one processor among several. Email, identity, monitoring, support desks and the SaaS products your teams use every day all move data too. A residency claim that covers the application platform but ignores the ticketing tool where customer data is pasted into incident reports will not survive a supplier questionnaire. Map the whole chain and apply the same questions to each link.
Writing it down
Whatever level you choose, document it in a short data residency statement: which services, which regions, where backups and logs live, which exceptions exist and why, how keys are managed, and which contractual terms apply. Procurement teams, auditors and your own engineers all need the same document, and producing it forces the decisions that "EU hosting" otherwise leaves vague.
Summary
Choosing an EU region is necessary and not sufficient. Residency of core data is well handled by all three major providers. Access, support locality and legal exposure are addressed by configuration, key management and contract, and they are your decisions to make. Make them deliberately and the claim on your proposal will mean something.