Data sovereignty and data residency often appear together in infrastructure proposals, sometimes as though they were interchangeable promises. But the distinction is important when you assess whether a provider meets your organisation’s requirements, and it can change which suppliers belong on your shortlist.
Before committing to an EU hosting location or a service marketed as sovereign, you need to understand what the proposed arrangement covers throughout normal operations, support and recovery. This article takes you through three decisions: which rules apply to your data, which infrastructure model meets those requirements, and which commitments you need from the provider in writing.
What is the difference between data sovereignty and data residency?
Data residency describes the country or region where data is physically stored and processed, while data sovereignty concerns the laws that apply to that data and the authorities able to compel access. An EU data centre address answers the question “Where is the data stored?”, but leaves another question open: “Whose laws apply, and who can compel access?”
These questions require different evidence. To establish residency, you need the locations used by the service, including its backup and recovery arrangements. To assess sovereignty, you also need to understand the provider’s legal structure, ownership and control over the data.
| Criterion | Data residency | Data sovereignty |
|---|---|---|
| Question answered | Where is the data stored? | Whose laws apply, and who can compel access? |
| Nature | Geographic, covering storage and processing locations | Legal, covering jurisdiction and access powers |
| Who determines it | You and the provider select locations within applicable constraints | Applicable laws, jurisdiction and the provider’s legal circumstances |
| Evidence to request | Named facilities, countries and a map of data locations | Contracting entity, ultimate owner and assessment of applicable access laws |
| Example | Production data and backups remain in Romania | The provider’s ownership and legal exposure are assessed alongside its Romanian hosting location |
Residency is often a location choice agreed with the provider, although a contract or sector-specific rule can make that choice mandatory. Data localisation refers specifically to a legal requirement that certain data remain within a country or territory. Where such a requirement applies, you should check if it covers storage alone or also processing, copies and access from abroad.
Server location is one input to the legal assessment and does not decide every law that reaches the provider. Ownership needs a closer look when the company operating the infrastructure belongs to an international group.
Can data reside in one country but be legally controlled by another?
Yes, data stored in one country can fall within the reach of another country’s authorities through the provider that controls it. The US CLOUD Act, enacted in 2018, clarified this principle in 18 U.S.C. § 2713. A covered provider subject to US jurisdiction must comply with qualifying legal demands for data in its possession, custody or control, even when the data is stored abroad. This extraterritorial reach means that choosing an EU storage region does not, by itself, remove exposure to US disclosure orders. On the EU side, Article 48 of the GDPR addresses disclosure demands from foreign authorities. Recognition or enforcement requires an applicable international agreement, such as a mutual legal assistance treaty, without excluding other lawful transfer grounds under Chapter V. A foreign order alone does not establish a GDPR legal basis and transfer mechanism.
Consider data hosted in an EU facility by a provider headquartered in the US. The agreed storage location is respected, while the provider remains exposed to US legal demands. During a French Senate hearing in June 2025, a US cloud provider’s representative acknowledged under oath that he could not guarantee French customer data would never be disclosed following a US government injunction without French authorities’ approval. He also mentioned this had not happened in the circumstances being discussed.
Two measures deserve attention when reducing this exposure:
- Examine ownership and control. A provider without a non-EU corporate parent, the company controlling it through the ownership chain, removes one potential route of foreign influence. Its other jurisdictional connections still need assessment.
- Keep encryption keys under your control. Protection is stronger where the provider cannot obtain the keys or readable data. A customer-managed key setting alone does not establish this, particularly when the service decrypts data during processing.
EU data sovereignty rules: GDPR, DORA, NIS2 and the Data Act
The relevant contract requirements depend on your data, sector and service, so use the following rules to identify what your infrastructure proposal must address.
| Rule | Who it applies to | What to check in the infrastructure and contract |
|---|---|---|
| GDPR | Controllers and processors within its territorial scope | Chapter V conditions for personal-data transfers outside the EEA, including onward transfers and relevant overseas access |
| DORA | Covered financial entities and their ICT third-party arrangements, with oversight for designated critical providers | Countries or regions of service delivery, processing and storage, advance notice of location changes, and exit strategies for critical or important functions |
| NIS2 | Essential and important entities covered by national implementing legislation | Supplier security, evidence supporting risk assessments, and management approval and oversight of cybersecurity measures |
| Data Act | For these provisions, providers of data processing services offered to EU customers | Safeguards against conflicting foreign-government access to non-personal data held in the EU, plus contractual and technical arrangements for switching services |
DORA has applied since 17 January 2025. Article 30(2)(b) requires location details in ICT contracts, while Article 28(8) requires financial entities to prepare exit strategies for services supporting critical or important functions. Those requirements affect both the initial service agreement and the arrangements for moving workloads later.
NIS2’s transposition deadline was 17 October 2024. Article 21(2)(d) includes supply-chain security, and Article 20 requires management bodies to approve and oversee the measures. They can be held liable for infringements, with the applicable liability rules determined through national law.
The Data Act has applied since 12 September 2025. Article 32 requires safeguards where foreign-government access would conflict with EU or relevant national law. Under Article 29, switching charges will be prohibited from 12 January 2027, so contracts signed now should already address that transition.
Keep in mind that this article represents general information, and should not be taken as legal advice.
Does GDPR require data to stay in the EU?
No, GDPR does not impose a general requirement to store personal data in the EU. Article 44 requires international transfers to meet Chapter V conditions. These include an adequacy decision recognising essentially equivalent protection, or safeguards such as standard contractual clauses (SCCs), the Commission-approved terms for transferring personal data abroad. GDPR covers processing connected with EU establishments and, in specified circumstances, non-EU organisations offering goods or services to, or monitoring, people in the EU.
For transfers to participating US organisations, the EU-US Data Privacy Framework provides an adequacy route. As of 12 October 2026, the Court’s register lists the related appeal, C-703/25 P, as pending. Check the recipient’s participation and the mechanism’s status when contracting.
Breaches of transfer rules attract maximum fines of €20 million or, for an undertaking, 4% of worldwide annual turnover, whichever is higher, under Article 83(5).
EU data residency: when it is enough and when you need sovereignty
You should always start with the requirement your organisation must satisfy, because a restriction on location calls for different evidence from a restriction on foreign legal access.
Residency is usually enough when
- Your contract requires storage and processing in an agreed EU location, with no additional restriction on the provider’s ownership or jurisdiction.
- Ordinary personal-data processing remains within the agreed region, and the provider’s security, processing and transfer arrangements meet the remaining GDPR requirements.
- You are documenting locations for DORA purposes, while addressing its other contractual and operational obligations separately.
You need sovereignty when
- Your risk assessment or contract requires protection against particular forms of non-EU government access or control.
- Public-sector, healthcare, defence or critical-infrastructure workloads carry specific restrictions on who operates the service and which laws reach it.
- Trade secrets or sensitive customer information require controls that extend beyond the physical location of storage.
Before accepting an EU residency promise, you should check the full service. Backups and replicas might use another region, logs and telemetry might feed a global monitoring platform, and support staff abroad might access data remotely. During an outage, automatic failover could also move processing outside the agreed area. Remote access from abroad leaves the stored copy in place but raises processing and transfer questions of its own.
In order to give procurement a defensible basis for selecting the appropriate model and deciding which providers qualify, ask your legal and security teams to identify the requirement for each workload.
How to choose compliant EU infrastructure for data sovereignty
Compare infrastructure models against the location, access and ownership requirements you have established, using the table below to identify what each proposal needs to demonstrate.
| Model | Where the data resides | Applicable laws and who can compel access | Who holds the keys | Suitable for |
|---|---|---|---|---|
| EU region of a US hyperscaler | Selected EU region, subject to service settings and exceptions | EU rules apply alongside potential US legal demands on the provider | Provider-held or customer-managed, depending on configuration | Workloads needing EU hosting and services whose legal exposure is acceptable |
| Hyperscaler sovereign offering operated through EU entities and staff | Defined EU service boundary | Depends on the legal structure and control retained by the parent. Ask the provider for a written answer | Varies by service and key-management architecture | Workloads needing restricted overseas operational access |
| Cloud provider owned and governed in the EU | Contracted EU locations | EU and national authorities have applicable powers. Verify other jurisdictional connections | Provider-held or customer-controlled | Workloads requiring EU ownership and governance |
| Dedicated private cloud at an EU provider | Agreed EU facility or facilities | Depends on the provider’s ownership and jurisdiction, despite dedicated hardware | Customer-controlled where the design supports it | Sensitive workloads needing dedicated resources and administrative control |
| Colocation with your own hardware in an EU data centre | Selected facility, with copies placed by your team | Your organisation’s and the operator’s legal exposure both remain relevant | Your team, if retained within your own systems | Workloads needing direct control of hardware, software and encryption |
Dedicated hardware gives you more control over the technical environment, but ownership and jurisdiction still require separate checks. The same applies to encryption: customer-managed encryption keys let you control aspects such as creation, rotation and permissions, while exclusive key custody requires an arrangement in which the provider cannot obtain or use them. Ask whether administrators or the service itself can access decrypted data.
The sovereign cloud is generally an attempt to keep data, operations and legal control within a defined jurisdiction, though the label alone does not establish a uniform set of protections. In its July 2025 market analysis, Synergy Research Group put European providers’ share of Europe’s cloud infrastructure market at around 15%, against 70% for the three largest global providers. On 3 June 2026, the Commission adopted its proposal for the Cloud and AI Development Act. It proposes four Union assurance levels for assessing cloud sovereignty, with progressively stronger requirements. At level 4, the provider and relevant subcontractors must not be controlled by a third country or a legal entity established there. This is a proposed framework, so procurement should distinguish its criteria from obligations already applicable under existing law.
What should you evaluate when buying EU data infrastructure?
Evaluate the provider’s legal identity, the locations of every relevant data copy, the people and systems able to access it, and the arrangements for leaving the service. Turn those checks into written evidence requests, so legal, security and procurement teams assess the same proposed deployment.
- Which legal entity signs the contract, and who is its ultimate owner?
Request the entity’s registration details, ownership chain and explanation of any non-EU parent’s control over the service or data. This helps assess jurisdictional exposure beyond the hosting address. (CLOUD Act and foreign-access risk.)
- Which facility and country will store our primary data?
Ask for named locations in the service agreement, together with the process and notice period for changes. A general promise of “European hosting” leaves too much unspecified. (DORA, Article 30(2)(b), where applicable.)
- Where are backups and other copies stored?
Request a location map covering replicas, disaster-recovery copies, logs and telemetry. Include the destinations used during failover and the controls that prevent an unauthorised regional change. (Residency commitments and GDPR transfer requirements.)
- Who has administrative and support access, and from which countries?
Obtain an access matrix, approval process and logging arrangements. Include the control plane, the administrative layer through which the provider’s staff and systems manage your environment. (Overseas access and supply-chain risk.)
- Who holds the encryption keys?
Request an architecture showing where keys are generated and stored, who can use them, and if the provider can decrypt data or access it during processing. (Confidentiality and foreign-disclosure risk.)
- Which subcontractors support the service, and where are they based?
Ask for the current list, each party’s function, data-access permissions and the notification process for changes. Include subcontracted support and management services. (GDPR processor obligations and NIS2 supply-chain security.)
- How do you handle a disclosure demand from a non-EU authority?
Request the policy for legal review, challenges, customer notification where permitted, and assessment of conflicting obligations before disclosure. (GDPR, Article 48, and Data Act, Article 32.)
- How will we retrieve our data and leave the service?
Obtain export formats, migration responsibilities, timescales and a breakdown of charges, including their treatment from January 2027. Financial entities should build this into their exit strategy. (Data Act, Article 29, and DORA, Article 28(8).)
- Which certificates and audit reports cover this service?
Request the documents, their scope, validity and relevant findings. Check that they cover the proposed location and operations, and use them as evidence within your supplier assessment. (NIS2, Article 21(2)(d), where applicable.)
How M247 supports EU data residency
You can host your workloads in Romania with M247 Global, choosing private cloud or colocation at our Bucharest facilities, M247 Europe DC1 and DC2. To meet your EU data residency requirements, the contract should specify where your data will be stored and processed, including any backup and recovery copies. The relevant options address different levels of technical control:
- Dedicated private cloud: M247’s private cloud infrastructure provides dedicated resources and administrative access for configuring the environment. The service also includes restricted firewall and VPN access, which supports the implementation of your access policies.
- Colocation for your own equipment: Hosting your servers in a selected Romanian facility lets your team choose the software, configure encryption and manage the data stored on that hardware.
- Backup and recovery services: you can add optional backup and disaster-recovery services to M247 private cloud. The storage destinations, replication paths and access arrangements should form part of the agreed residency scope.
An EU facility location does not establish exclusive EU legal control over the service, so you can ask us to confirm the contracting entity, ownership, support locations, subcontractors and key-management arrangements for your proposal, together with the locations of all backup and recovery copies.
First, establish whether each workload requires an agreed hosting location, additional protection from foreign legal access, or both. Then choose the infrastructure model that satisfies those requirements alongside your operational needs. Obtain the answers in writing and incorporate the agreed commitments into the contract. To assess a deployment in Romania, discuss private cloud or colocation for your own infrastructure with one of our consultants.