8 Sovereign Cloud Providers for EU Healthcare Data in 2026: A Ranked Shortlist (HDS, C5, SecNumCloud)

Key points:

• There is no single "EU healthcare cloud" certificate. Each country adds its own gate on top of GDPR: HDS certification in France (article L1111-8 of the Code de la santé publique), a BSI C5 Type 2 attestation in Germany since 1 July 2025 (§ 393 SGB V), and NEN 7510 for Dutch care providers. Pick the provider that clears the gates of every country you sell into.
• My ranked shortlist for a multi-country health company: OVHcloud, Scaleway, 3DS Outscale, STACKIT, T Cloud Public (formerly Open Telekom Cloud), S3NS, the AWS European Sovereign Cloud, and the EU regions of AWS, Azure and Google Cloud. The first six are EU-owned or EU-operated under French or German law; the last two carry US parent jurisdiction.
• SecNumCloud is the only French label that adds immunity from non-EU law. 3DS Outscale, OVHcloud (on specific offers) and S3NS hold it; Scaleway and Bleu are still in qualification as of November 2026.
• The AWS European Sovereign Cloud launched in January 2026 but its first C5 report is Type 1 (AWS, March 2026). German statutory health providers need Type 2 for established systems, so check the attestation type before you shortlist it for German patient data.
• The European Health Data Space applies from 26 March 2027 (European Commission). It adds interoperability and logging duties for EHR systems; it does not replace HDS, C5 or GDPR.
• Qovery is not a cloud provider and never hosts patient data. It deploys your applications on Kubernetes inside your own account at the provider you choose, so you can run France on Scaleway or OVHcloud and Germany on STACKIT without a second platform team.

The question I get most from health CTOs sounds like this: "we sell to hospitals in France and Germany, and both procurement teams sent us a different checklist". One wants an HDS certificate. The other wants a C5 Type 2 report. Both want patient data to stay in the EU, and more and more of them want a provider that no US court can reach.

This guide ranks the providers I would evaluate in that situation, on criteria you can check yourself. If you only sell in France, our list of HDS-certified hosting providers goes deeper on that single certificate. If you are not in healthcare, start with our general sovereign cloud comparison for Kubernetes.

How did we pick and rank these providers?

We ranked each provider on six criteria that health procurement teams in France, Germany and the Netherlands ask for, in this order of weight: national health certification, sovereignty level, ownership and jurisdiction, managed Kubernetes and databases inside the certified scope, EU region footprint, and exit terms. A provider that fails the health certification of your main market drops out, however good the rest is.

Here is what each criterion means in practice:

1. National health certification. HDS for French personal health data, which is mandatory under article L1111-8. A C5 Type 2 attestation for German statutory health insurers, hospitals, doctors and their processors under § 393 SGB V. NEN 7510 alignment for Dutch care providers.
2. Sovereignty level. Data residency in an EU region is the floor. Above it sit EU operations by EU staff, and at the top, the French SecNumCloud qualification, which requires immunity from non-EU laws. Our explainer on the four levels of EU cloud sovereignty covers the ladder in detail.
3. Ownership and jurisdiction. A US-headquartered parent is subject to the US CLOUD Act, whatever the region. An EU-owned provider is not.
4. Certified scope for what you run. A certificate covers named services. Managed Kubernetes, managed PostgreSQL, object storage and backups all need to sit inside it, or your architecture falls out of scope.
5. EU footprint. Two or more regions or availability zones in the countries you serve, for disaster recovery that stays inside the EU.
6. Exit terms. Reversibility clauses and data portability, which the EU Data Act now backs with switching rights from September 2025.

I deliberately did not rank on price. List prices for compute across these providers vary less than the cost of failing an audit or losing a hospital tender.

Which sovereign cloud providers should a healthcare company evaluate in 2026?

For a healthcare company that needs patient data to stay in the EU, evaluate OVHcloud, Scaleway, 3DS Outscale, STACKIT, T Cloud Public, S3NS, the AWS European Sovereign Cloud and the EU regions of the three US hyperscalers. Choose by the certification your main market demands: HDS for France, C5 Type 2 for Germany, SecNumCloud when a buyer requires immunity from non-EU law.

"Not listed" means I could not find the certification on the provider's own compliance pages as of November 2026, not that it is impossible. Always confirm against the certificate scope annex or the attestation report itself, never against a marketing badge.

What do HDS, C5, SecNumCloud and the EHDS actually require?

HDS and C5 are national entry tickets for health data, SecNumCloud is an optional French sovereignty qualification, and the EHDS is a new EU regulation on health record interoperability and secondary use. GDPR article 9 sits under all of them. You need to know which one each buyer is asking for, because they are not interchangeable.

HDS is changing version. The ANS published a new referentiel approved by the arrêté of 26 April 2024, and existing certified hosts had 24 months, until 16 May 2026, to recertify against it (Squire Patton Boggs). The new version also adds data localisation in the EEA for health data. Ask every provider for the certificate issued under the current version.

C5 Type 2 replaced Type 1 for German health data on 1 July 2025. Until 30 June 2025, a Type 1 attestation was enough under § 393 SGB V. Since then, Type 2 is the standard, with an 18-month Type 1 grace period only for systems placed on the market after 30 June 2025 (SRD Rechtsanwälte). The same law limits processing to Germany, the EU, the EEA, Switzerland or an adequacy country, and requires the processor to have an establishment in Germany.

The EHDS has a long fuse. Regulation (EU) 2025/327 entered into force on 26 March 2025. It applies generally from 26 March 2027, with major obligations phasing in on 26 March 2029 and 26 March 2031. For a cloud choice, the practical impact is logging, access control and interoperability requirements on EHR systems, which are far easier to meet on infrastructure where you control the audit trail.

1. Is OVHcloud the right choice for patient data in Europe?

OVHcloud is the strongest all-round pick for a health company that starts in France and expects to grow into stricter sovereignty requirements. It is French-owned, HDS-certified across its Public Cloud catalogue, and holds SecNumCloud on dedicated offers. Do not pick it if you need the breadth of a hyperscaler's managed AI and analytics services.

• HDS: OVHcloud's HDS documentation lists Public Cloud instances, managed containers and a long list of managed databases (relational, document, in-memory, column-oriented) as certified. HDS projects require a Business or Enterprise support level and the HDS option activated per project.
• SecNumCloud: qualified on its Bare Metal Pod, Hosted Private Cloud and, since September 2026, its SNC Cloud Platform (OVHcloud). The standard Public Cloud is not the SecNumCloud perimeter.
• C5: OVHcloud publishes a C5 attestation. If you serve German statutory health actors, confirm it is Type 2 and covers the exact services and German region you use.

My caveat: the HDS scope, the SecNumCloud scope and the C5 scope are three different product lists. Map your architecture to each list before signing, especially managed Kubernetes and backups.

2. Why does Scaleway rank so high for healthtech?

Scaleway is the best fit for developer-led healthtech teams in France who want a modern cloud with managed Kubernetes inside the HDS scope. The French state validated that choice in April 2026, when it selected Scaleway to replace Microsoft Azure as host of the national Health Data Hub, with migration planned between late 2026 and early 2027 (Euronews). Do not pick it if your tender requires SecNumCloud today.

• HDS: certified, with Kapsule (managed Kubernetes) in scope (Scaleway HDS).
• SecNumCloud: Scaleway passed the J0 milestone in 2025 and remains in qualification as of November 2026 (Scaleway). Plan for it, do not contract on it.
• Germany: no C5 attestation listed, so German statutory health data is a poor fit.

The Health Data Hub decision is the clearest signal I have seen that French public health data is moving off US-parent clouds. Private buyers tend to copy what the state does within a year or two.

3. When is 3DS Outscale the safest answer?

3DS Outscale is the safest answer when a French hospital group or public buyer writes SecNumCloud into the contract. It holds both SecNumCloud 3.2 and HDS, which is still a short list. Do not pick it if your team wants a large self-service catalogue or plans to sell mostly outside France.

• Certifications: SecNumCloud 3.2, HDS, SOC 2 Type 2, ISO 27001, 27017 and 27018, per its certifications page.
• Ownership: a Dassault Systèmes brand, so French jurisdiction end to end.
• Germany: no C5 attestation on its certifications page.

NumSpot, the sovereign cloud joint venture built on Outscale technology, targets the same buyers. Compare the two on the exact services you need, since our NumSpot, OVHcloud and Scaleway comparison shows how much their SecNumCloud perimeters differ.

4. Is STACKIT the best choice for German health data?

STACKIT is my first pick for German health data. It holds a C5 Type 2 attestation covering its infrastructure and 21 cloud products, runs data centres only in Germany and Austria, and is owned by Schwarz Digits, part of the Schwarz Group behind Lidl and Kaufland. Do not pick it for French patient data: I found no HDS certification on its pages.

• C5: Type 2, which is exactly what § 393 SGB V requires since July 2025.
• Kubernetes: STACKIT Kubernetes Engine (SKE), built on Gardener.
• Other certifications: ISO 27001, 27017, 27018, ISO 20000 and TISAX Level 3.

For a DiGA vendor or a hospital software company selling only in Germany, STACKIT removes the CLOUD Act question from the procurement conversation entirely.

5. What does T Cloud Public (Open Telekom Cloud) offer health providers?

T Cloud Public, the January 2026 rebrand of Open Telekom Cloud, is the most established German option for statutory health and social data at scale. It holds a BSI C5 Type II attestation and lists compliance support for social data under section 35 SGB I and professional secrecy holders under section 203 StGB. Do not pick it if your team wants a lightweight developer experience.

• C5: Type II, audited annually; the platform has been C5 audited since 2018 (Open Telekom Cloud).
• Regions: German data centres (Magdeburg and Biere) plus a Netherlands region.
• Spain: it also holds the ENS high-level certification, useful if you sell to Spanish public health.

6. Should you consider S3NS for sovereign Google Cloud services?

S3NS is worth evaluating when you want Google Cloud services under a French SecNumCloud qualification. S3NS, majority-owned by Thales and running Google Cloud technology, obtained SecNumCloud 3.2 on 17 December 2025 for IaaS, CaaS and PaaS, the first time ANSSI qualified all three scopes at once, covering more than twenty services (Thales). Do not pick it until you have confirmed the HDS status of the exact services you need.

• SecNumCloud: qualified on the PREMI3NS offering.
• HDS: I could not confirm it on a primary source for the qualified offering. Ask for the certificate.
• Comparison: Bleu, the Orange and Capgemini venture running Microsoft technology, passed SecNumCloud J0 in April 2025 and now targets qualification at the end of 2026 (Next). Treat it as a roadmap item for now.

7. Is the AWS European Sovereign Cloud enough for healthcare?

The AWS European Sovereign Cloud is a credible option for AWS-native teams that need EU-only operations, but it is too young for most health procurement checklists today. It became generally available on 15 January 2026 in Brandenburg, Germany, physically and logically separate from other AWS regions (Amazon). Do not pick it for German statutory health data until a Type 2 C5 report covers your services.

• C5: its first attestation, published in March 2026, is C5 Type 1, alongside SOC 2 and seven ISO certifications, covering 69 services (AWS). Type 1 only works under § 393 SGB V for a system placed on the market after 30 June 2025, and only for 18 months.
• HDS: I found no HDS certification for it; AWS's HDS scope covers the standard Paris region (AWS HDS).
• Jurisdiction: operated by an EU entity with EU-resident staff, but the ultimate parent is American. Whether that satisfies your buyer is a question for your lawyers.

8. When are AWS, Azure or Google Cloud EU regions still the right call?

The standard EU regions of AWS, Azure and Google Cloud are still the right call when you need the broadest certified catalogue, mature AI and analytics services, or fast expansion across many countries. All three hold HDS for their French regions and C5 for German regions. Do not pick them when a buyer requires SecNumCloud or refuses US parent jurisdiction.

• HDS: AWS (Paris eu-west-3), Azure (France Central, France South), Google Cloud (Paris europe-west9).
• C5: AWS lists Frankfurt, Paris, Ireland, Milan, Stockholm, Zurich, Spain and London among regions in C5 scope (AWS C5).
• NEN 7510: Microsoft and Google publish NEN 7510 mappings for Dutch customers, even though cloud providers are not required to hold it.

The trade-off is that you get the deepest service catalogue in exchange for exposure to the CLOUD Act and to FISA section 702. For many private clinics and medtech vendors, a signed DPA, EU region pinning and encryption with your own keys are enough. For French public hospitals, increasingly, they are not.

How do I choose between them if I sell in several EU countries?

If you sell in several EU countries, pick one provider per regulatory perimeter instead of forcing one provider to clear every gate. In practice that means a French provider with HDS for French patient data and a German provider with C5 Type 2 for German statutory health data, with the same application stack deployed to both.

Two-provider setups scare teams because they picture two platform teams. The application layer (containers, Helm charts, managed PostgreSQL, secrets, CI/CD) can be identical across both clouds if you deploy it on Kubernetes with the same tooling. We wrote a full playbook for running the same Kubernetes workloads on an EU sovereign cloud and AWS.

What does differ per country is evidence: certificates, DPAs, sub-processor lists, and who administers the system holding health data. In France, that last point is HDS activity 5, and it usually stays with you even when the hoster is certified.

What should the contract with a sovereign cloud provider include for patient data?

The contract must name the certified scope, the data location, the sub-processors and the exit path. A certificate on a website is not a contract term, and hospital buyers will ask for the documents behind the logo.

Ask every shortlisted provider for these seven items:

1. The certificate or attestation itself, with the scope annex listing the exact services and regions (HDS certificate, C5 report, SecNumCloud attestation).
2. A data processing agreement under GDPR article 28, naming the provider as processor.
3. The full sub-processor list, including support and follow-the-sun operations. A support engineer outside the EU with access to production is a transfer.
4. A data localisation commitment covering primary data, backups, logs and telemetry.
5. A reversibility clause with formats, timelines and costs, aligned with your EU Data Act switching rights.
6. Breach notification terms short enough for you to meet the 72-hour rule under GDPR article 33.
7. For German statutory health data, confirmation of an establishment in Germany, as § 393 SGB V requires for the processor.

Your error tracker, log pipeline, CI runner and observability SaaS also touch patient data if a stack trace contains an identifier, so put your own tooling on the same checklist.

Where does Qovery fit in a sovereign healthcare architecture?

Qovery is the deployment and operations layer that runs on top of whichever sovereign cloud you pick. It is not a cloud provider and never hosts your application or patient data: the Qovery control plane is separate from the data plane, which stays in your own account at OVHcloud, Scaleway, AWS, GCP or Azure, or on any existing Kubernetes cluster at STACKIT, T Cloud Public, Outscale or on-premise.

What that gives a health team without a dedicated platform team:

• The same deployment model in every perimeter. Git-push deployments, Helm and Terraform services, and environment cloning work the same way on a Scaleway Kapsule cluster in Paris and on a STACKIT SKE cluster in Germany, attached through the Qovery Operator (Kubernetes 1.31 and later).
• Evidence for auditors. RBAC per environment and audit logs of every deployment and configuration change help you answer "who changed what, when" for HDS activity 5 or a C5 audit. Qovery helps you meet those controls; it does not make you compliant on its own.
• Region and account control. You choose the cloud account and the region per cluster, so data residency is a configuration you can show an auditor.
• Agent guardrails. If your team uses coding agents, OPA-based policy tokens restrict what an agent may deploy, and where.

Cross-cloud networking between the French and German clusters is not built in. If you need it, it is configurable with a site-to-site VPN, Cilium Cluster Mesh or Tailscale, and most health architectures I see avoid it on purpose, keeping each country's patient data strictly in its own perimeter.

How do I set this up with Qovery from Claude Code or Cursor?

If your team works with a coding agent, you can hand it the setup. Install the Qovery Agent Skills, connect the MCP Server read-only, and ask in plain language, for example "deploy this API to my Scaleway account in Paris with Qovery".

curl -fsSL https://skill.qovery.com/install.sh | bash

# 2. Or for the current project only
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# 3. MCP Server in Claude Code over OAuth, read-only by default
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

• Step 1 or 2 installs the skills (qovery-onboard, qovery-deploy, qovery-troubleshoot and others). The onboarding skill asks about your industry and compliance needs before it recommends a cloud and region, and asks you to approve each change.
• Step 3 connects the MCP Server over OAuth in read-only mode, so the agent can inspect clusters and environments but not change them. Only add write access, with "https://mcp.qovery.com/mcp?read_write=true", when you explicitly want it, and enable it in the Qovery Console too.

Start with the AI agent quickstart or the Claude Code integration.