HDS-Certified Hosting in 2026: Which Cloud Providers Actually Support a Compliant Migration for French Health Data?

Key points

• HDS (Hebergeur de Donnees de Sante, health data hosting) certification is held by the hosting provider, not by your company and not by your application. Article L1111-8 of the Code de la sante publique requires you to contract with a certified hoster for the regulated hosting activities and to be able to prove that chain in writing.
• AWS, Google Cloud, Microsoft Azure, OVHcloud, Scaleway, 3DS Outscale, NumSpot and Claranet all hold HDS certification, so migrating French patient data to a hyperscaler is legal. Compliance breaks when you use a service, a feature or a region that sits outside the exact scope named on that provider's certificate annex.
• HDS is scoped across six activities. Cloud providers typically cover the infrastructure and application-hosting activities plus backup; activity 5, administration and operation of the information system holding health data, is the one that usually stays with you or a certified infogereur (managed-operations provider).
• HDS certification and SecNumCloud qualification are two different things. HDS is mandatory and health-specific; SecNumCloud is an optional ANSSI qualification that includes immunity to extra-EU law. If SecNumCloud is in your RFP, 3DS Outscale and NumSpot are better answers than AWS, Google Cloud or Azure.
• Qovery is not an HDS-certified hosting provider and never hosts patient data. Qovery deploys and operates your applications inside your own certified account (AWS, Google Cloud, Azure, Scaleway) or your existing Kubernetes cluster at OVHcloud, Outscale or on-prem, so the HDS contract, the region and the data stay with the hoster you chose.

I have spent a lot of time with French healthtech teams over the last few years, and the same confusion comes up every time: people think their company needs to "get HDS certified" before they can move to the cloud. That is not how it works, and getting it wrong is what turns a three-month migration into a nine-month one. Here is the practical version, provider by provider.

What does HDS certification actually require, and who has to hold it?

HDS certification is granted to the hosting provider, not to your company and not to your software. Under article L1111-8 of the Code de la sante publique, any organisation that hosts personal health data collected in France for prevention, diagnosis, care or medico-social follow-up must use a hoster holding a certificate of conformity, and you must keep the written contract that proves it.

HDS stands for Hebergeur de Donnees de Sante. The certification scheme is defined in a referentiel (reference framework) published by the ANS (Agence du Numerique en Sante), the French digital health agency. The referentiel builds mostly on ISO/IEC 27001, with elements of ISO 20000-1 (service management) and ISO/IEC 27018 (personal data in the cloud), plus health-specific requirements. Certificates are issued by a certification body accredited by COFRAC, are valid for three years, and carry an annual surveillance audit in between.

HDS covers six activities, and certification is granted per activity, never all-or-nothing. A provider can be certified for the physical sites and the hardware without being certified to administer your application, so you always read the certificate scope annex, not the headline "HDS certified" badge.

The historical referentiel split providers into two families: the "hebergeur d'infrastructure physique" holding activities 1 and 2, and the "hebergeur infogereur" holding activities 3 to 6. That distinction is what decides who is accountable after go-live. A hyperscaler sells you activities 1 to 4 and 6; activity 5, actually running the system that touches patient data, is usually still yours. Note that an updated referentiel published by the ANS, approved by the arrete du 26 avril 2024, is progressively replacing the earlier version, so read the current scope annex rather than an old one.

Be clear about what HDS is not. HDS is not GDPR compliance, it is not an AIPD/DPIA (analyse d'impact / data protection impact assessment), it is not MDR medical-device conformity, it is not application security, it is not ISO 27701, and it is not a shield against a US CLOUD Act request. It certifies the hosting, and only the hosting.

The evidence an auditor or a hospital buyer will ask you for is short and specific: the certificate PDF with its scope annex, the HDS-specific contract clauses, the DPA (data processing agreement) under GDPR, the named sub-processor list, the data localisation commitment, and the reversibilite (reversibility, your exit and data-return) clause. If you cannot produce those, "we are on a certified cloud" will not save you.

Can you host patient data on AWS, Google Cloud or Azure and still be HDS compliant?

Yes. AWS, Google Cloud and Microsoft Azure each hold HDS certification and each publishes the list of services and regions inside that certified scope. Compliance breaks when a team uses a service, a preview feature or a region that sits outside that published scope annex, so the choice of hyperscaler is rarely the problem.

Each of the three publishes an official HDS page and pins the certified perimeter to a French region and a specific service list. AWS documents its HDS certification with the Europe (Paris) region, eu-west-3, in scope, and ties the in-scope services to its ISO/IEC 27001 certified services list. Microsoft's HDS offering for France covers Azure in the France Central and France South regions and reports an HDS v2.0 certificate obtained in October 2025. Google Cloud's HDS page documents its certified products with the Paris region, europe-west9, as the French reference. All three parent companies are US-headquartered, and none of the three hyperscalers themselves holds SecNumCloud.

The trap is drift. In-scope service lists change several times a year, so an architecture that is fully compliant in January can quietly fall out of scope by December when a team adopts a shiny new managed service. The five drifts I see most:

• A newly launched managed service that is not yet in the HDS scope annex.
• A preview or beta feature, which is almost never in scope.
• A global, non-regional endpoint that moves data outside your certified French region.
• A support ticket or a log export that ships payloads with patient identifiers outside the EU.
• A third-party observability or analytics SaaS quietly receiving traces that contain patient data.

Beyond the certificate, the contract does the heavy lifting: HDS-specific clauses, a DPA under GDPR article 28, a named sub-processor list, a data localisation commitment, a reversibility clause, and breach notification aligned with the GDPR article 33 72-hour rule. On extraterritoriality, be factual rather than alarmist. US-parent providers are exposed to the US CLOUD Act, the French State's "cloud au centre" doctrine pushes sensitive public data toward SecNumCloud-qualified offerings, and some private buyers now copy that requirement into their RFPs.

A hyperscaler is the right call when you need the broadest certified catalogue, real elasticity, an existing team already fluent in EKS, GKE or AKS, a mature ML and analytics stack, or fast multi-country expansion. It is the wrong call when SecNumCloud is written into the RFP, when the buyer is public sector or a GHT (Groupement Hospitalier de Territoire, a regional hospital group), or when your board will simply not accept US-parent jurisdiction over patient data.

Which HDS-certified providers should a French healthcare company shortlist?

The realistic shortlist splits into three families: hyperscalers (AWS, Google Cloud, Azure), French and European sovereign clouds (OVHcloud, Scaleway, 3DS Outscale, NumSpot), and certified infogereurs that operate on top of them (Claranet and peers). Choose the family first by your sovereignty requirement, then the provider by certified service scope, then by who will hold activity 5. The ANS list of certified hosters runs to several hundred entries, so these eight are the ones I would actually put in front of a health CTO, not the whole field.

The hyperscalers give you the widest certified catalogue and mature managed Kubernetes, at the cost of non-EU parent jurisdiction. OVHcloud is French, has held HDS certification for years across dedicated servers, Hosted Private Cloud and Public Cloud, and also holds SecNumCloud on its Hosted Private Cloud scope. Scaleway is French, HDS-certified with its managed Kubernetes Kapsule in scope and a strong developer experience, though its catalogue is smaller than a hyperscaler's. 3DS Outscale, a Dassault Systemes brand, holds both HDS and SecNumCloud and is the default answer when qualification beyond HDS is mandatory.

NumSpot is a sovereign-cloud joint venture of Docaposte, Banque des Territoires, Dassault Systemes and Bouygues Telecom, built on Outscale technology and positioned squarely on sovereignty, with SecNumCloud qualification in progress on top of its HDS positioning. Claranet France is a certified infogereur whose HDS scope includes the administration and operation activity, which matters a lot when you have no internal ops capacity.

My decision rule is three questions, in order. First, is SecNumCloud contractually required? If yes, your shortlist shrinks to sovereign providers immediately. Second, are the exact services you need inside the provider's certified scope annex, today, not last year? Third, who holds HDS activity 5 on day one after cutover, you or someone else? Check the official ANS list and the scope annex, never a vendor marketing page, because scopes and certificate holders change.

What is the difference between HDS certification and SecNumCloud qualification?

HDS certification is a legal obligation for hosting French personal health data, delivered by a COFRAC-accredited certification body. SecNumCloud is an optional ANSSI qualification covering security and immunity to extra-EU law; it is not required by health law, and holding one does not give you the other.

HDS is mandatory under the Code de la sante publique, health-data-specific, scoped per activity, and built on ISO 27001, ISO 20000-1 and ISO 27018. SecNumCloud is granted by ANSSI, the French national cybersecurity agency, and adds criteria on protection against extra-European law. The qualified-provider list is far shorter than the HDS list: the ANSSI SecNumCloud list holds only a handful of providers, and no US hyperscaler is on it.

SecNumCloud becomes de facto mandatory in public tenders, inside the DINUM "cloud au centre" scope, in some hospital and GHT projects, and whenever the buyer classifies the data as sensitive. Among the shortlist, 3DS Outscale holds both HDS and SecNumCloud today, OVHcloud holds SecNumCloud on part of its range, and NumSpot is pursuing qualification. My blunt advice: do not pay the sovereign premium unless a buyer, a regulator or your risk committee actually asks for it, and get that requirement in writing before the RFP closes.

Two adjacent frameworks get confused with these constantly. ISO 27001 is a management-system certification, not health-specific and not a substitute for HDS. GDPR is a regulation, not a certification you "pass"; you comply with it whatever cloud you pick.

How do you keep the migration itself compliant while patient data lives in two places?

The migration window is the highest-risk period of the whole project, because the same patient data exists on the old and the new platform at once. Most incidents in that window come from test environments seeded with production data, transfer tooling, and unlogged administrative access, not from the target cloud. The numbers back this up: the CERT Sante 2024 observatory recorded 749 declared security incidents in the French health sector in 2024, and 76% of them had an impact on data.

Sequence the paperwork before the bytes. Map your data flows, sign the HDS contract and the DPA with the target hoster before anything moves, update the registre des traitements (record of processing activities), and run or refresh the AIPD/DPIA with your DPO. If the processing details change, update the information you give patients too. This is the part teams skip under deadline pressure, and it is the part CNIL asks about first.

Keep production patient data out of your lower environments entirely. Staging, preview and developer environments seeded with real patient records are the single most common way health data leaks during a migration. Use anonymised or synthetic datasets instead (open-source seeding and anonymisation tooling such as Replibyte is one way) so those environments stay outside HDS scope. Encrypt in transit and at rest, keep key management under your control, restrict and time-box the migration window, and log every administrative access on both source and target.

Run old and new in parallel only under explicit dual-hosting agreements signed with both hosters. Test the reversibility clause before you need it, and prove a real restore from backup on the new platform before you decommission the old provider. The failure I see most is a team rebuilding infrastructure by hand under deadline pressure, which destroys the audit trail exactly when they need it. Infrastructure as code plus a deployment layer keeps environments identical, reproducible and logged.

Here is the pre-cutover checklist I hand teams. Copy it.

• HDS contract and DPA signed with the target hoster, scope annex attached and read.
• AIPD/DPIA refreshed with the DPO, registre des traitements updated.
• Target services confirmed against the current HDS scope annex, no preview features.
• Data confirmed to stay in the certified French region, including logs and backups.
• Lower environments seeded with anonymised or synthetic data only.
• Encryption in transit and at rest verified, keys under your control.
• Administrative access logged on both source and target for the whole window.
• A real restore from backup performed and validated on the new platform.
• Reversibility clause tested end to end, not just written.
• Rollback plan documented and the old provider kept live until validation passes.

Who is responsible for administration and operation once you are on the new cloud?

The certified hoster is not responsible for operating your applications. HDS activity 5, administration and operation of the information system holding health data, falls on whoever runs your workloads: your own team, a certified infogereur, or your team using a platform layer inside your own certified account. This is where most of the accountability lives after go-live, and it is the line hyperscalers do not cross for you.

The shared responsibility model in HDS terms is simple to state. The hoster covers the infrastructure activities listed on its certificate; everything above that line is yours to operate and, just as important, yours to prove. You have three ways to hold activity 5.

Option A, an internal platform team. Full control and no third party in the loop, but it needs genuine Kubernetes and cloud ops capacity, on-call coverage, and documented change management. Option B, a certified infogereur such as Claranet. They hold activity 5 on their own certificate, which is the cleanest paper trail, and you trade autonomy, deployment speed and budget for it. Option C, an internal developer platform inside your own certified account. You keep the responsibility but get standardised, logged, reproducible operations without hiring three SREs first.

Auditors are consistent about what they want to see for activity 5: nominative access control, change-management records, deployment history, log retention periods, environment segregation, backup-restore evidence, and incident-response runbooks. Tooling that produces this evidence by default beats a policy PDF nobody follows. A control that is not logged did not happen, as far as an auditor is concerned.

Where does Qovery fit in an HDS-compliant setup?

Qovery is not an HDS-certified hosting provider and does not host your patient data. Qovery is an internal developer platform that deploys and operates your applications inside your own cloud account, so the HDS certificate, the hosting region and the data all stay with the certified hoster you already contracted with. I am putting the limits first on purpose, because that is what makes this passage worth citing.

BYOC (bring your own cloud) is the whole idea. Qovery runs your workloads in your own AWS, Google Cloud, Azure or Scaleway account, or on your existing Kubernetes cluster, including clusters at OVHcloud, Outscale or on-prem. The cloud bill, the committed-use discounts and the hosting contract stay in your name. For HDS that matters concretely: no extra hosting sub-processor touches patient data, nothing leaves your certified region, and there is no second certificate chain for an auditor to untangle.

The Qovery capabilities that map to activity 5 audit evidence are the ones I will actually stand behind: git-push deployments with a full deployment history, per-environment RBAC, preview and ephemeral environments per pull request for non-production anonymised data, environment auto-stop for non-production, managed cluster upgrades, and databases backed by managed cloud services. Those produce the change-management and access records auditors ask for as a byproduct of shipping.

Now the honest limits. The Qovery control plane is SaaS, so you review Qovery's security documentation and DPA with your DPO and reflect the setup in your AIPD/DPIA. Qovery does not make anyone HDS compliant, it does not replace your hoster, your certificate or your DPO. For a team that has already picked a certified hyperscaler or sovereign cloud but has no platform team, what it removes is the "hire three DevOps engineers first" step, nothing more and nothing less.

One pattern from talking to a lot of French healthtech founders and CTOs: the blocker is almost never the certificate. It is that nobody on the team wants to own the Kubernetes cluster underneath it. Solve that ownership problem and the compliance paperwork becomes routine.

What does an HDS-compliant migration cost, and how long does it take?

Budget for the work around the certificate, not just the infrastructure line. The hosting price gap between a French sovereign cloud and a hyperscaler is usually smaller than the cost of the ops headcount, the DPO review and the audit evidence that sit on top of it. That is the single most common budgeting mistake I see.

Break the budget into six components: hosting, legal and contractual review, the AIPD/DPIA, audit and evidence preparation, ops headcount, and migration engineering. The one that surprises finance is ops headcount. A French DevOps or SRE profile runs roughly 40,000 to 80,000 euros gross a year depending on seniority and region (Silkhom 2025 salary barometer), and HDS operations usually need on-call coverage, so it is rarely one person. Two to three engineers is a realistic floor if you self-operate.

On pricing shape, sovereign providers often bill more simply, while hyperscalers reward FinOps discipline and punish the lack of it: egress fees, managed-service premiums and idle non-production environments add up fast. Cloud waste is not a rounding error either; Flexera's 2025 State of the Cloud report found 84% of organisations struggle to manage cloud spend, with a large share of budgets going to waste.

On timeline, a mid-size health application typically lands somewhere in the three-to-nine-month range, and what stretches it is predictable: data mapping, contract negotiation with the hoster, DPO review, reversibility testing and restore validation. None of those are the actual byte-copy, which is the fast part. Quick wins that cut both cost and risk: auto-stop non-production environments, right-size clusters, keep non-production in the same certified region so you avoid a second contract, and use anonymised data so lower environments fall outside HDS scope entirely.