A signed Data Processing Agreement with a customer in Germany or France does not by itself create an EU-storage requirement. The requirement arises from the contract's actual residency or processing terms, the parties' roles, and applicable data-protection or sector rules – not from the customer's location alone. Still, this scenario plays out regularly during vendor audits, security reviews, or contract renewals, when procurement teams discover that "EU-based" marketing claims and actual legal exposure are two different things, particularly when the underlying data technically runs on infrastructure whose operator is subject to foreign disclosure law.
This article does not rank another list of storage providers. Instead, it lays out a step-by-step evaluation process that separates server location from legal jurisdiction and helps B2B decision-makers document a defensible choice. This framework focuses on EU residency and EU GDPR; buyers handling EEA, UK, or Swiss data should assess the relevant transfer regime separately, since these are not interchangeable jurisdictions.
What Does "EU Cloud Storage" Actually Mean?
EU cloud storage is not a single, legally defined category. It spans a spectrum from "EU-hosted" (data physically stored on servers within EU territory) to "EU-owned and operated" (a company legally headquartered in the EU, with EU ownership and no foreign parent entity subject to extraterritorial law).
The difference between GDPR compliance and data sovereignty is the first distinction that matters. GDPR compliance is a legal minimum: it requires appropriate technical and organizational measures, lawful processing bases, and data subject rights. Data sovereignty, by contrast, is not a single, legally fixed status. In procurement terms, it usually describes the degree of control an organization retains over its data: residency, provider ownership and jurisdiction, sub-processors, administrative access, and – critically – who can technically obtain the plaintext.
Server location and provider jurisdiction are both relevant, but neither alone determines the level of sovereignty a service actually provides. A company incorporated in the United States, or a subsidiary of one, generally remains subject to the US CLOUD Act even if it stores data exclusively on servers physically located in Frankfurt or Amsterdam. The CLOUD Act allows US authorities to compel disclosure of data held by a company under US jurisdiction, independent of where the servers sit. This does not mean an EU-incorporated provider is automatically immune from every foreign disclosure attempt, nor that a US-owned provider can never offer meaningful protection – a lot depends on contractual structure, sub-processors, and whether the provider ever holds usable plaintext at all.
A US-owned provider can process EU personal data lawfully, but contracts alone may not be sufficient. Depending on the transfer route, organizations may rely on an adequacy decision such as the EU-U.S. Data Privacy Framework for certified recipients, or use Standard Contractual Clauses together with a transfer impact assessment and, where needed, supplementary measures such as strong encryption. In Schrems II, the Court of Justice of the EU invalidated the EU-US Privacy Shield primarily over concerns about US surveillance law (including FISA Section 702 and Executive Order 12333) and the lack of effective judicial redress for EU data subjects – it did not invalidate SCCs, which remain a valid transfer mechanism when properly assessed.
Initiatives such as Gaia-X and the more recent EuroStack proposal exist precisely to address this layered problem: they aim to establish infrastructure and governance standards where EU legal control, not just EU geography, shapes data protection. For organizations evaluating storage vendors, this context explains why "hosted in the EU" and "EU cloud storage" in the sovereignty sense are not interchangeable terms, and why jurisdiction is one important factor among several rather than the single decisive one.
Step 1: Classify Which Data Actually Needs EU Storage
Not every file requires EU-jurisdiction storage. Classification should happen before any vendor comparison, because it determines scope, budget, and migration effort.
A practical starting point is a four-tier sensitivity model:
- Health data and other Article 9 special categories: subject to GDPR's stricter processing conditions. Ordinary customer records and financial data are not automatically Article 9 data simply by nature, but sector-specific rules (banking, insurance, healthcare) may still impose additional handling or residency requirements.
- Contractually triggered data: any dataset covered by a DPA clause specifying EU-only processing or storage – often a direct requirement from enterprise customers in regulated sectors, and independent of whether the data itself is a special category.
- Internal operational data: HR records, financial planning documents, internal communications – sensitive but not always contractually bound to EU storage.
- Marketing and public-facing material: brochures, public website assets, non-personal analytics – generally low risk and rarely worth migrating for compliance reasons alone.
Does every file need to move to an EU cloud? In most organizations, no. GDPR itself does not generally mandate EU-only storage; obligations of that kind typically come from specific contracts, sector rules, or a documented risk assessment rather than from the regulation as a whole.
A realistic approach is to identify, through an actual data inventory, which share of data carries a genuine contractual or regulatory trigger, and treat the rest under normal operational handling. Migrating everything indiscriminately increases both storage costs and migration effort without a corresponding compliance benefit. Overclassification is a common and avoidable cost driver in EU cloud migrations.
Step 2: Check Legal Jurisdiction, Not Just Server Location
Jurisdiction is one of several factors that determine whether a provider could be compelled to disclose data – alongside actual control over the data, sub-processor arrangements, and technical access to plaintext. This combination is the most overlooked part of vendor evaluation, and the reason many companies that market themselves as "EU cloud storage" still carry meaningful foreign-disclosure exposure.
Can a US company with EU servers still be called "EU cloud storage" in a marketing sense? Yes – and this is exactly the ambiguity that creates risk. The company may store data in Dublin or Frankfurt while remaining a US-incorporated entity, or a subsidiary of one, which can keep it within reach of US disclosure orders regardless of physical data location, subject to the specifics of its ownership and operations.
The following documents and points should be requested from any prospective provider before signing a contract. Review the contracting entity and its ownership or control structure, all processing and support locations, the current sub-processor list together with change-notification terms, and the transfer mechanism used for any data leaving the EU:
| Document / Question | What It Reveals |
|---|---|
| Country of incorporation and parent company structure | An indicator of possible exposure to foreign disclosure law, though actual control and business activity also matter |
| Full sub-processor list, with notice terms for changes (Article 28 GDPR) | Whether backup, CDN, or support functions route through non-EU vendors, and how changes are communicated |
| History of government data requests (transparency report, if published) | Track record of disclosure requests and how the provider responded |
| Signed Data Processing Agreement (DPA) | Processing terms and governing law for the contract itself – note that a governing-law clause does not determine how the provider handles government disclosure orders |
| Applicable Chapter V transfer mechanism (SCCs, adequacy decision, etc.) | Legal basis for any data flow that leaves the EU, however limited |
A provider unwilling to share its sub-processor list within a reasonable timeframe – set a clear deadline in the procurement plan and treat missed deadlines as a signal – is itself worth noting during due diligence. Many providers marketed as "European" rely on non-EU hyperscalers for backup redundancy or content delivery, which can reintroduce the same jurisdictional exposure the buyer is trying to avoid.
Step 3: Compare Providers Against Fixed Technical and Compliance Criteria
Provider comparison should follow fixed criteria rather than feature marketing, since marketing language ("secure," "GDPR-ready," "enterprise-grade") is not independently verifiable and varies in meaning across vendors.
What criteria actually distinguish EU cloud storage providers from one another? The following table outlines the core comparison dimensions, why each matters, and what to ask a vendor directly – deliberately without naming specific products or prices, since verified figures were not available at the time of writing.
| Criterion | Why It Matters | What to Ask |
|---|---|---|
| Server location and data center redundancy | Determines physical data residency and disaster recovery scope | Which countries host primary and backup copies? |
| Ownership and control structure of the parent company | Contributes to potential exposure to non-EU disclosure laws, alongside actual data control | Is the parent entity incorporated outside the EU, and who can compel it? |
| Encryption model and technical access to plaintext | Determines whether the provider itself could ever access readable data | Is encryption client-side or end-to-end, and can the provider technically obtain plaintext? |
| Independent assurance (ISO/IEC 27001, BSI C5, SecNumCloud) | Scoped evidence about selected security and compliance controls – not a blanket GDPR guarantee | Which legal entity, regions, and services are covered, and is the certificate or attestation current? |
| Sub-processor transparency | Reveals hidden third-party dependencies, including non-EU ones | Can the full sub-processor list be provided in writing? |
| Pricing model and total cost of ownership | Base storage price rarely reflects migration or egress costs | What are the migration, API, and data egress fees? |
On encryption specifically: server-side encryption with a customer-managed key can improve control, but depending on the architecture the provider may still be able to access plaintext during processing, or technically control decryption. Meaningful protection against provider access generally requires client-side or end-to-end encryption where the provider never holds the key or the plaintext – though metadata, identity information, and usage patterns can still remain visible even then. Ask about the encryption architecture directly rather than only asking who stores the key.
On certifications: ISO/IEC 27001 certifies an information security management system within a defined scope; BSI C5 is typically demonstrated through a current attestation report rather than a certificate in the ISO sense; SecNumCloud is a French ANSSI qualification with its own technical and legal criteria. None of these confirms GDPR compliance for an entire provider by itself – what matters is which legal entity, regions, and time period each document actually covers.
Price comparisons that ignore migration effort and integration costs are also misleading, since a lower monthly storage fee can be offset by substantial engineering time spent rebuilding integrations that a previous provider offered natively.
Step 4: Verify Integration With Existing Business Tools
Compatibility with existing workflows is a cost factor that is easy to underestimate during vendor selection. A storage solution that requires custom scripting to connect with existing collaboration tools adds ongoing maintenance overhead that rarely appears in the initial price comparison.
Key integration points to verify before committing:
- Native sync clients for desktop and mobile operating systems, tested under actual file volumes rather than vendor demos.
- API availability and documentation quality, particularly for automated backup or workflow triggers.
- SSO/SAML support, so the storage provider can plug into existing identity management rather than requiring separate credentials.
- Compatibility with European collaboration suites, reducing dependency on non-EU productivity tools for day-to-day document handling.
- File versioning and conflict resolution behavior, especially for teams collaborating on shared documents in real time.
How long does a migration to EU cloud storage actually take? This depends heavily on file count, available bandwidth, the complexity of the permission model, data quality, the number of integrations, testing requirements, and the staff available to run the project. Rather than relying on a generic estimate, it is more reliable to derive a timeline from the pilot described in the next step, since a pilot surfaces most of these variables directly. Organizations without dedicated internal resources for the project should expect timelines to extend accordingly.
Step 5: Run a Pilot Before Full Migration
A pilot project reduces the risk of committing to a provider based on documentation alone. Support-level agreements and marketing claims are easy to write; actual performance under real conditions is not.
A structured pilot should include:
- Scope limited to one team or department, running long enough to surface realistic usage patterns before any decision on full rollout.
- Sync reliability testing under normal daily file volume, tracked for conflicts, duplication, or sync failures.
- A recovery test that distinguishes between the provider's built-in recovery features and an independent backup. Synchronization, trash/recycle bins, and version history are not automatically an independent backup: errors, compromised accounts, ransomware, or faulty sync can affect replicated copies and versions as well. Test both the provider's native recovery and a separate backup capable of restoring data after accidental deletion, account compromise, or a service failure.
- Access rights and permission testing, verifying that role-based access controls behave as configured, not just as described.
- Direct support response testing, submitting a real ticket and measuring actual response time rather than trusting the published SLA.
- A documented rollback plan, defining in advance what conditions would trigger reverting to the previous storage solution.
How should an organization test a provider before committing long-term? The combination of a defined pilot window, measurable technical tests – including a genuine backup test, not just a recovery-feature test – and a documented exit trigger turns vendor selection into an evidence-based decision rather than a trust-based one.
Step 6: Plan Rollout and Exit Strategy Together
Vendor lock-in risk is easiest to manage before a contract is signed, not after. Planning the exit strategy alongside the rollout plan avoids a situation where switching costs quietly become the deciding factor in future renewals.
Before finalizing a contract, the following points should be clarified in writing:
- Data export formats and any associated export fees, confirmed in the contract rather than assumed from the sales conversation.
- Bulk export timeframes at contract termination, since commitments vary meaningfully between providers and should be fixed contractually rather than assumed.
- A phased rollout by department rather than a single organization-wide cutover, limiting the impact of unexpected issues to one team at a time.
- Internal documentation of the selection rationale, including the criteria used and vendor responses, kept on file for future audits or customer due-diligence requests.
What should organizations look for in the exit clause of an EU cloud contract? The clause should specify export format, a defined maximum timeframe for data return, and any deletion confirmation process – vague language such as "reasonable notice" without a defined timeframe should be treated as a negotiation point, not accepted as standard.
Frequently Asked Questions About EU Cloud Storage
Is EU cloud storage automatically GDPR-compliant?
No. GDPR compliance depends on the processing agreement, technical safeguards, and sub-processor arrangements – not on server location alone. A provider can host data in the EU and still fail GDPR requirements through weak access controls or undisclosed non-EU sub-processors.
Can a US company with EU-based servers still be called "EU cloud storage"?
In marketing terms, yes, and this is precisely the ambiguity that creates confusion. Depending on its ownership and control structure, the company may remain subject to foreign jurisdiction, including the US CLOUD Act, regardless of where the servers are physically located – though the specifics depend on the entity involved and the transfer safeguards in place.
How does EU cloud storage compare in cost to non-EU providers?
Pricing varies significantly by provider and storage tier, and no reliable general figure applies across the market. As a rule of thumb, smaller EU-native providers may carry a price premium reflecting smaller-scale infrastructure, but total cost of ownership depends heavily on migration and integration effort rather than list price alone.
Does switching to EU cloud storage automatically guarantee data sovereignty?
No. Meaningful data sovereignty generally depends on a combination of storage location, the operating entity's jurisdiction, sub-processor structure, and technical control over encryption keys – not on any single factor. Switching providers without verifying all of these can leave a similar exposure in place under a different brand.
What happens if a provider is later found non-compliant?
This depends on the nature of the finding and the applicable supervisory authority's decision, which can range from required remediation to processing restrictions. Maintaining an alternative export path and up-to-date documentation of the original vendor selection reduces the operational disruption if a provider's status changes.
EU Cloud Storage Is an Ongoing Governance Decision, Not a One-Time Purchase
Jurisdiction, ownership structure, and sub-processor lists are not fixed at the point of signing – providers get acquired, expand infrastructure, or add new sub-processors over time. A vendor that met all sovereignty criteria at contract signing may not meet them 18 months later.
The central takeaway for EU cloud storage selection is that server location, provider jurisdiction, contractual control, and encryption architecture each answer a different part of the question, and no single one of them determines data sovereignty on its own. Treating the questions raised across this framework as a recurring internal checklist – reviewed at each contract renewal, sub-processor update, or annual compliance audit – keeps the original decision defensible rather than a one-time assumption that quietly goes stale.
