HDS health data hosting in France: what software vendors need to know
Who needs HDS certification, what the v2 referential and the 24 March 2026 decree changed, how to split the six hosting activities between IaaS and vendor, and the architecture checklist to settle before the audit.
Ala Ben Aicha
Direct answer
French law requires HDS certification from anyone who hosts personal health data on behalf of someone else (a hospital, a health professional, a patient) when that data was collected during prevention, diagnosis, care or social and medico-social follow-up. A SaaS vendor running on a certified IaaS is not automatically covered: if its own staff administer production, it performs activity 5 and needs certification for it. Since 16 May 2026 every valid certificate is issued against the v2 referential, and since late September 2026 a decree requires storage exclusively in the EU or EEA.
Scope: who counts as a "host"?
The regime comes from article L.1111-8 of the French Public Health Code (CSP). The ANS (Agence du numérique en santé) summarises its scope: hosting on behalf of a data controller, of data collected in a care context. Three practical consequences:
- A hospital running its EHR (DPI) on its own infrastructure is not a host in the legal sense. GDPR and its security obligations still apply.
- A healthcare organisation hosting for others (a hospital group serving its members, for instance) is in scope. The ANS counted 14 certified healthcare establishments in October 2025.
- A wellness app collecting data outside any care pathway raises a qualification question. Read the ANS FAQ and document your analysis instead of assuming.
Accredited certification bodies issue the certificates, and the ANS publishes the list of certified hosts on its HDS certification page. A certificate names the service, the sites, the dates and the activities covered. Read that scope, not the logo on the sales deck.
The six activities
Article R.1111-9 CSP splits hosting into six activities. The v1 referential bundled them into two certificate types (physical infrastructure and managed services); in v2 the scope is stated activity by activity.
| Activity | Content (R.1111-9) | Usually performed by |
|---|---|---|
| 1 | Providing and keeping operational the physical sites | Data centre operator |
| 2 | Hardware infrastructure of the information system | Data centre or cloud operator |
| 3 | Virtual infrastructure of the information system | IaaS provider |
| 4 | Application hosting platform | PaaS provider, or the vendor if it runs its own middleware |
| 5 | Administration and operation of the information system containing health data | Whoever holds admin access, often the vendor |
| 6 | Backup of health data, including electronic archiving since decree 2026-209 | Backup or third-party archiving provider |
Activity 5 is where vendors get caught. In its 15 October 2025 webinar, the ANS defined it as control over interventions on the provided resources, with four ancillary activities: granting and annually reviewing named, justified access rights; securing the access procedure; collecting and keeping access traces and their reasons; approving interventions in advance. The stated rule is blunt: a host that performs any one of those ancillary activities must be certified for activity 5.
What the v2 referential and the 2026 decree changed
The v2 referential was approved by an order dated 26 April 2024 and published in the Journal officiel on 16 May 2024. New applicants have been audited against v2 since 16 November 2024; hosts already certified had until 16 May 2026 to move over. The referential builds on ISO/IEC 27001 and adds health-specific requirements. An ISO 27001 certificate helps only if its scope matches the service being certified; a certificate held for another offering or another group entity solves nothing.
The sovereignty part comes down to four requirements:
| v2 requirement | What it demands |
|---|---|
| 28 | Data stored in the EEA, by the host and by its subcontractors. Only sites located in the EEA can be certified for activities 1, 2 or 6 |
| 29 | Remote access from outside the EEA must rest on an adequacy decision or GDPR article 46 safeguards, detailed in the contract |
| 30 | The contract lists the non-EU laws that could force the host or a subcontractor into a transfer or unauthorised access (in the sense of GDPR article 48), the mitigation measures and the residual risks |
| 31 | Publication of a URL: either the transfer map and table of safeguards, or the statement that there is no risk of access imposed by third-country law in breach of EU law (the case, among others, for a SecNumCloud 3.2 qualified host) |
The SREN law of 21 May 2024 then moved these rules into the code itself. Decree no. 2026-209 of 24 March 2026 creates article R.1111-9-1: when hosting involves storage, that storage takes place exclusively on the territory of an EU member state or a party to the EEA agreement. It also extends the mandatory content of the hosting contract (R.1111-11). Both parts came into force six months after publication in the Journal officiel of 26 March, so at the end of September 2026.
Next step: the ANS has announced a version 2.1 of the referential, aligned with the decree, with publication planned for October 2026 and requirements applying three months later, checked at the surveillance or renewal audit. Check whether the order has been published by the time you read this. Either way, existing contracts may need amending.
HDS and SecNumCloud are not interchangeable
HDS does not require ANSSI's SecNumCloud qualification. The two cover different scopes: a SecNumCloud-qualified host is still subject to HDS if it hosts health data on behalf of others, and HDS certification is not a SecNumCloud qualification.
SecNumCloud becomes mandatory by another route. Article 31 of the SREN law and decree no. 2026-272 of 14 April 2026 require a cloud protected from extraterritorial laws, for particularly sensitive data, from State administrations, certain State operators and certain public interest groupings; the list covers the Plateforme des données de santé and the ANS. If you sell to those buyers, expect SecNumCloud in the tender. For a clinic or a private practice, HDS remains the legal baseline; read the tender anyway, since some buyers go further.
Decision table: does the vendor need certification?
The pattern "IaaS covers activities 1 to 4, vendor covers 5 and 6" gets repeated a lot. As a general rule it is wrong. Two questions settle it: who contracts the hosting with the client, and who actually does what in production.
| Situation | Activities performed by the vendor | Vendor certification |
|---|---|---|
| Software installed in the hospital's data centre, run by its IT department | None | Not required. GDPR processor agreement if the vendor connects remotely |
| The hospital contracts directly with a host certified for 1 to 6; the vendor ships software with no admin access to production | None | In principle not required; the contract and real access rights must show it |
| Vendor SaaS on an IaaS certified for 1, 2, 3 and 6; vendor staff manage OS, databases, deployments and accounts | 4 and 5 | Required for the activities actually performed |
| SaaS on a managed PaaS certified for 1 to 5, but developers keep read access to the production database | Part of 5 | Required for 5, since an ancillary activity is performed |
| Backup or archiving outsourced to a third party | None if the third party runs it | The third party must be certified for 6, electronic archiving included |
Have the certification body confirm your split before the audit. The ANS webinar flags a recurring case: shared-responsibility models that push account and identity management entirely onto the client, when that is precisely the core of activity 5.
HDS is a French regime. Switzerland and Belgium have their own frameworks, which this article does not cover.
Architecture checklist before choosing a host
Location of every copy. A primary database in a French region is not enough. Replicas, backups, the disaster recovery site, search indexes, application logs that contain data, analytics exports: all of it stays in the EEA, including at subcontractors.
Encryption and keys. Encryption at rest and in transit, keys in a KMS or HSM located in the EEA. Decide who can use the keys: the provider, the vendor, the client. That decision feeds directly into the residual-risk table of requirement 30.
Access traces. Activity 5 means collecting and keeping access traces and their reasons. In practice: named accounts, a mandatory ticket reference for every production session, immutable logs. Those logs often contain health data themselves, so the same location rules apply.
Support access. No standing production access. Just-in-time access, MFA, recorded sessions, annual rights review, prior approval of interventions. A support team outside the EEA is remote access from a third country: it needs an adequacy decision or article 46 safeguards, written into the contract. Authenticating health professionals inside the application is a separate topic, covered by Pro Santé Connect.
Subcontractors. Inventory every service that receives data: error tracking, APM, email, SMS, the ticketing tool where people paste screenshots, LLM APIs. The ANS notes that proving each subcontractor meets the sovereignty constraints takes time. A register versioned with the code helps (fictional providers, reviewed at each release):
service: example-dpi-saas
hds_scope:
iaas_provider:
certificate_activities: [1, 2, 3, 6]
regions: [eu-fr-paris-1, eu-fr-paris-2]
vendor:
certificate_activities: [4, 5]
data_stores:
- name: postgres-primary
region: eu-fr-paris-1
encryption_at_rest: true
key_ref: kms://eu-fr-paris-1/keys/dpi-prod
- name: backups
region: eu-fr-paris-2
retention_days: 35
sub_processors:
- name: error-tracking
region: eu-de-frankfurt
receives_health_data: false
scrubbing: request-body-and-headers
- name: transactional-email
region: eu-ie-dublin
receives_health_data: false
remote_access:
- team: support-l2
location: EEA
mode: just-in-time, ticket-required, session-recorded
A receives_health_data: false line is only worth something if a test checks it: for example, an integration test that triggers an error on a synthetic record (DOE^JANE) and asserts that the payload sent to the error tracker contains no name, no INS identifier and no clinical text.
Reversibility. The hosting contract must cover returning the data at the end of the service. Define the format (FHIR, CSV with a data dictionary), the timeline and the proof of deletion, and test the export at least once a year.
Environments. No real data in staging or development. If an incident requires production data, handle it inside the certified environment, with a trace.
GDPR, DPIA and NIS2: what HDS does not cover
HDS certifies a host; it does not make a processing operation compliant. Processing health data at scale requires a data protection impact assessment under article 35 of the GDPR. The vendor is usually a processor under article 28 and must help the controller carry it out: provide a reusable technical description (flows, locations, subcontractors, measures). The matching architecture choices are covered in GDPR-compliant healthcare data architecture.
NIS2 adds its own risk-management and incident-reporting duties for in-scope entities, providers as well as hospitals; see NIS2 for healthcare IT teams. To place HDS among the other European texts (MDR, AI Act, EHDS), the EU healthcare compliance landscape is a good starting point.
Common mistakes
- Accepting "HDS certified" without reading the certificate: activities, sites, exact service.
- Database in France, but logs and traces shipped to an observability SaaS outside the EEA.
- Level-2 support outsourced outside the EEA with no contract clause on remote access.
- Forgetting already-signed contracts during the move to v2, and again for v2.1.
- Mixing up HDS and SecNumCloud in a tender response.
If you need to split hosting activities between your provider and your team, or shape the architecture ahead of an HDS audit, that technical scoping is part of the HealthTech development work I take on.