# Data residency vs data sovereignty in cloud hosting

Last updated: 2026-11-10

**Data residency** is a fact about geography: the country or region where your data is stored and processed. **Data sovereignty** is a question of power: which company operates the service, who can decrypt the data, and which country's laws can compel access to it. Residency is one part of sovereignty, and it's the easiest part to promise, so read any "sovereign cloud" claim level by level.

This guide isn't legal advice. For the US CLOUD Act in particular, read [EU region vs EU company](/i/eu-region-vs-eu-company-cloud-act).

## The four levels at a glance

| Level | The question it answers | A residency promise covers it? | Evidence to ask for |
|---|---|---|---|
| Location | Where are the data, backups and logs stored and processed? | Yes | Region list, backup and log locations |
| Operator | Which company runs the service, and who staffs admin and support? | No | Legal entity, ownership, where staff with access work |
| Keys | Who can decrypt the data? | No | Key management docs, who holds the master keys |
| Jurisdiction | Which courts and governments can order the operator to hand data over? | No | Governing law, parent company, subprocessors |

The four levels are independent of each other. Data can sit in Frankfurt, be operated from another continent, be encrypted with keys the operator controls, and fall under a foreign court order, all at once.

## What to check before you trust a label

- **The whole data path, not the main region.** Backups, logs, analytics, support tickets and error tracking often live somewhere else.
- **Remote access.** The EDPB counts it as a transfer when an organisation "otherwise makes personal data available" to a party outside the EEA, so an admin abroad can matter as much as a server abroad.
- **The contracting entity.** The company named on the terms is the one that receives legal orders.
- **Who holds the keys.** Encryption at rest helps against theft. It doesn't help against the operator if the operator holds the keys.
- **The subprocessor list.** A European platform can rely on non-European suppliers for code hosting, email or payments.
- **The certificate itself.** Ask for the certificate or qualification and its scope. A label on a landing page isn't a scope.

## Level 1: location

Residency is what a region picker gives you. It's useful: latency is lower, and some contracts and sector rules ask for it directly.

The GDPR treats location through its transfer rules. The [EDPB's guide for small businesses](https://www.edpb.europa.eu/sme-data-protection-guide/international-data-transfers_en) explains that personal data may only leave the EEA under the conditions of Chapter V, through an adequacy decision, appropriate safeguards or narrow derogations. Those conditions apply in addition to the rest of the GDPR, so data stored in the EU still needs a legal basis, security measures and a processor contract.

## Level 2: operator

The operator is the company that runs the machines and the people who can log in to them. Two providers can offer the same region and differ completely here. Ask where the staff with production access sit, and whether support is outsourced. Ask whether the provider rents its infrastructure from a third party, because that third party is part of the chain too.

## Level 3: control of keys

If you hold the only copy of the keys, the operator can store your data without being able to read it. That's the strongest technical answer to an access request, but it's also the hardest to run: an app usually needs to decrypt data to use it, and lost keys mean lost data. In practice, ask three things: who generates the keys, where they are stored, and whether the provider's staff can use them without you.

## Level 4: legal jurisdiction

Jurisdiction follows the company, its parent and its suppliers, not the data centre. This is where the CLOUD Act sits, and it's covered in detail in [EU region vs EU company](/i/eu-region-vs-eu-company-cloud-act). For sovereignty, the useful questions are which law governs the contract, whether a non-EU parent can direct the provider, and whether any supplier in the chain answers to another country.

## What EU schemes say

### EUCS

The European Cybersecurity Certification Scheme for Cloud Services is prepared by ENISA, the EU cybersecurity agency, under the Cybersecurity Act. ENISA's [December 2020 announcement](https://www.enisa.europa.eu/news/enisa-news/cloud-certification-scheme) describes the draft as voluntary, valid across member states, covering every kind of cloud service, with three assurance levels, Basic, Substantial and High, and a three-year renewable certificate. It also includes transparency requirements such as the location of data processing and storage.

On 10 November 2026, ENISA's [certification library](https://certification.enisa.europa.eu/certification-library/draft-candidate-schemes-technical-documents_en) still lists EUCS as a draft candidate scheme. ENISA explains that a draft scheme takes effect only once it becomes an EU implementing act. That has happened for EUCC, a scheme for ICT products, which was adopted by [Implementing Regulation (EU) 2024/482](https://eur-lex.europa.eu/eli/reg_impl/2024/482/oj), but not for EUCS. So no provider can show you an EUCS certificate today.

### SecNumCloud

SecNumCloud is a French qualification issued by ANSSI, the French national cybersecurity agency. [Scalingo's summary](https://scalingo.com/blog/referentiel-secnumcloud-3-2-evolutions-futur) of version 3.2, released in March 2022, lists rules on the operator and its owners: the provider must be headquartered in Europe, any single non-EU owner may hold no more than 24% and non-EU owners together no more than 39%, and primary administration and maintenance must take place in Europe. [OVHcloud's page](https://www.ovhcloud.com/en/compliance/secnumcloud/) says its qualified services are operated and monitored only by staff based in Europe. Qualification covers specific services, not a whole company, so check which service is qualified.

Scalingo offers a SecNumCloud region built on Outscale, and OVHcloud lists several qualified services on that page.

## How to test a provider's claim

1. Find the legal entity on the terms of service, then look up who owns it.
2. Read the subprocessor list and mark every entry outside the EU.
3. Ask where backups, logs, monitoring and support data are stored, in writing.
4. Ask where engineers with production access work, and how access is logged.
5. Ask who can decrypt your data without you.
6. Ask for any certificate or qualification, with its scope and expiry date, and check it with the issuer.
7. Compare the answers with your own requirement. A tender or regulator may ask for one level only, or for all four.

If the provider can't answer one of these in writing, treat that level as unproven.

## Where Eurobase sits on the four levels

| Level | Eurobase |
|---|---|
| Location | Apps, functions, containers, files and logs run on Scaleway infrastructure in the EU |
| Operator | A business registered in Warsaw, Poland, on European infrastructure operated by Scaleway, a French provider |
| Keys | No customer-held key option is documented |
| Jurisdiction | EU operator and EU host. GitHub, Inc. and GitLab Inc. are US subprocessors when you connect them, and Stripe handles billing |

Eurobase doesn't hold EUCS, SecNumCloud, ISO 27001 or SOC 2. ISO 27001 and SOC 2 are in progress. If your tender requires a SecNumCloud qualification, Eurobase doesn't meet it. You can keep your source code in Europe by deploying from Codeberg, a German association, instead of GitHub. The [host in the EU guide](/docs/guides/host-in-the-eu) shows what runs where.

## Frequently asked questions

### Is data residency enough for GDPR?

Storing data in the EU doesn't settle GDPR compliance by itself. You still need a legal basis, security and a processor contract, and remote access from outside the EEA can count as a transfer.

### Is data sovereignty the same as data localization?

No. Localization is a rule that data must stay in a given country, which is a residency requirement. Sovereignty also asks who operates the service, who holds the keys and which laws apply.

### Is EUCS in force?

Not as of 10 November 2026. ENISA's certification library lists it as a draft candidate scheme, and a scheme takes effect only once it's adopted as an implementing act.

### Does encryption make a US cloud sovereign?

Only if the provider can't decrypt your data. If the provider manages the keys, it can be ordered to use them, so encryption protects against theft but not against the operator.

### Can a European provider using a US supplier be sovereign?

At the operator level, yes. At the jurisdiction level, only partly: the US supplier can be reached for what it holds, so check what data passes through it.

## Sources

- [EDPB: International data transfers](https://www.edpb.europa.eu/sme-data-protection-guide/international-data-transfers_en)
- [ENISA: EUCS draft announcement](https://www.enisa.europa.eu/news/enisa-news/cloud-certification-scheme) and [EUCS publication page](https://www.enisa.europa.eu/publications/eucs-cloud-services-scheme)
- [ENISA: Draft candidate schemes](https://certification.enisa.europa.eu/certification-library/draft-candidate-schemes-technical-documents_en) and [Developing certification schemes](https://certification.enisa.europa.eu/about-eu-cyber-certification/developing-certification-schemes_en)
- [EUR-Lex: Implementing Regulation (EU) 2024/482 on EUCC](https://eur-lex.europa.eu/eli/reg_impl/2024/482/oj)
- [Scalingo: SecNumCloud 3.2](https://scalingo.com/blog/referentiel-secnumcloud-3-2-evolutions-futur)
- [OVHcloud: SecNumCloud](https://www.ovhcloud.com/en/compliance/secnumcloud/)
- [EU region vs EU company: the CLOUD Act](/i/eu-region-vs-eu-company-cloud-act)
- [Eurobase: host a web app in the EU](/docs/guides/host-in-the-eu) and [Eurobase subprocessors](/legal/subprocessors)