If you build software for hospitals, private clinics, telehealth platforms, medical laboratories, pharmacies, care coordination platforms, or digital health apps in France, HDS is more than just another certification acronym thrown into procurement to keep everyone humble. It is a real requirement that shapes how healthcare organizations evaluate vendors, approve infrastructure, and decide whether platforms are fit to host personal health data.
For development leaders, that makes HDS much more than a compliance footnote. It affects vendor selection, cloud architecture, data residency decisions, subcontractor risk, and the contract language that later appears with a legal redline and an unexpectedly aggressive deadline. Because apparently shipping healthcare software wasn't challenging enough already.
At a high level, HDS gives healthcare organizations a structured way to assess whether a vendor handling hosted health data can meet the security, operational, and contractual expectations required in the French market. And for development teams, understanding HDS early is much easier than discovering halfway through procurement that your “secure by design” story now needs an awkward call with compliance.
HDS overview
Before getting into the weeds of the 31 requirements, it helps to clarify what HDS is actually regulating. Here is some new vocabulary:
- A health data host is any natural or legal person that provides all or part of a hosting service for personal health data and acts as a processor under Article 28 of the GDPR.
- The healthcare organization itself is often the data controller, because it determines the purposes and means of processing, while the host provides the hosting service on that controller’s behalf.
In practice, a health data host is not always just a traditional infrastructure provider. Depending on how a solution is designed, a software vendor, backend platform, managed service provider, cloud provider, or application-layer partner can also fall into the hosting chain if it provides part of the service used to host personal health data. That is why HDS matters so much for healthcare software procurement: your vendor stack is often part of your compliance posture, not just your technical architecture.
The framework defines hosting broadly through six regulated hosting activities:
- Physical hosting sites: the facilities where the hosting environment is located and secured
- Hardware infrastructure: the physical servers, storage, and related equipment supporting the environment
- Virtual infrastructure: the virtualized compute, network, and storage layers used to run systems and services
- Application hosting platform: the platform layer used to host and deliver healthcare applications
- Management and operation of information systems containing health data: the administration, monitoring, and day-to-day running of systems that store or process health data
- Backup of health data: the outsourced backup and recovery services used to protect hosted health data
HDS compliance is not limited to the company that owns the data. It can apply across the layers that keep healthcare systems and applications running, from infrastructure and hosting environments to operational administration and outsourced backups. For healthcare organizations and software teams alike, that broader scope is the point: if a vendor touches the hosted environment in a meaningful way, it may be part of the regulated hosting picture.
That broader definition also explains why the HDS framework includes 31 requirements instead of a short checklist. Those requirements are designed to cover not just technical security, but also governance, contractual obligations, operational controls, auditability, and customer protections. So, when we break down the requirements next, the key thing to keep in mind is that HDS is evaluating whether a host can responsibly support healthcare data across the full lifecycle of the service, not just whether it can keep servers online and call it a day.
Requirements 1–16: Security management and operational discipline
The first block of requirements is about the host’s information security management system. Requirement 1 states that certification depends on an ISO 27001-certified ISMS, contracts that satisfy HDS rules, compliance with sovereignty requirements, and the communication of guarantees to clients. Requirements 2 through 16 then expand that foundation: the host must scope its ISMS around health data processing, account for legal obligations, assess risk scenarios specific to hosted health data, control subcontractor changes, support French-language interfaces and support at certain levels, define security objectives tied to GDPR, train staff, maintain client contacts, communicate certificates, define responsibility boundaries, address subcontractor certification risk, support customer verification and auditability, and perform internal audits including access-trace reviews.
For data controllers, this is the “Is this provider actually running a disciplined security program?” section. It is less about pretty policy PDFs and more about whether the provider can consistently manage risk, demonstrate accountability, and provide customers with visibility when something goes wrong. In plain English: HDS expects the host to run healthcare infrastructure, understanding that downtime, weak access control, and fuzzy subcontractor chains are not the vibe.
Requirements 17–27: Contractual protections buyers should care about
The second block turns compliance into contract language. Requirements 17 through 27 map directly to what the hosting contract must include: certificate scope and renewal dates, service descriptions, protections for data subject rights, named incident contacts, service quality and performance indicators, subcontractor terms, access control methods, obligations around technical changes, guarantees for host failure, restrictions on using hosted health data for any other purpose, and reversibility obligations at the end of service. Reversibility specifically includes return of entrusted information, destruction of copies, cost and timing rules for return, and usable export formats.
This is one of the most important parts for healthcare organizations. A strong HDS story is not just “our team passed an audit.” It is also “our contract clearly tells you what we do, what we do not do, how incidents are handled, how subcontractors are managed, and how you get your data back.” That is the difference between compliance posture and procurement theater.
Requirements 28–31: Data sovereignty and transfer transparency
The newest four requirements are where HDS gets especially relevant for modern cloud, SaaS, and AI-era vendor evaluations. Requirement 28 requires storage of hosted personal health data within the European Economic Area. Requirement 29 addresses remote access from outside the EEA and requires either an Article 45 adequacy basis or appropriate safeguards under Article 46 GDPR, plus customer disclosure. Requirement 30 covers situations where the host or one of its processors is subject to third-country laws that may compel access in ways that conflict with EU protection standards; in that case, the host must disclose the relevant laws, mitigation measures, and residual risks. Requirement 31 requires the host to publicly maintain and update a mapping of transfers outside the EEA, including relevant information on remote access and residual access risk.
For data controllers, these four requirements mean HDS now speaks more directly to the cloud governance questions:
- Where is the data stored?
- Who can access it remotely?
- Could foreign law force access?
- Can I see that exposure clearly before signing?
That is a meaningful shift. It does not eliminate all sovereignty risk, but it gives healthcare organizations better visibility into it, which is a lot more useful than vague assurances.
Which vendors do healthcare teams need to verify HDS compliance with?
For data controllers, one of the most important questions is which vendors in their stack must meet HDS requirements for a given project. Data controllers need to look carefully at the third parties involved in building, running, and supporting healthcare applications, especially when those vendors handle backend infrastructure, managed hosting, application environments, system administration, or data backup.
For application development leaders, this is where software architecture and vendor governance collide. A vendor involved in hosting or operating health-data environments may be part of the regulated hosting chain that supports your healthcare system or application. That is why backend and software development vendors matter so much in HDS-sensitive projects: if they store, process, operate, or support the environment that contains personal health data, they can affect whether your project clears security review, procurement, and deployment in the first place. In healthcare, your backend vendor is not just helping you ship faster. It may also be helping determine whether you can ship at all.
What exactly should be evaluated in these vendors?
When evaluating software vendors for sensitive workloads, healthcare teams should look past the certification badge and focus on operational fit.
- Certification scope: Confirm which of the six HDS hosting activities the vendor actually covers
- Subprocessors: Understand which providers support the stack and how subcontractor risk is managed
- Data residency and access: Review where data is stored and whether remote access from outside the EEA is possible
- Contract terms: Check reversibility, service levels, incident handling, limits on data use, and more - this is so important that it gets its own section (see below)!
- Governance support: Look for role-based access, auditability, repeatable backend patterns, and clear architectural visibility
Why a solid HDS contract matters so much
A weak hosting contract creates three problems at once: security ambiguity, procurement friction, and ugly exits.
French law requires the HDS hosting contract to contain specific clauses, including the certificate scope, service descriptions, hosting locations, support for data subject rights, incident contacts, service levels, subcontractor conditions, access-control methods, commitments around technical changes, guarantees against provider failure, prohibitions on secondary use of hosted health data, and reversibility terms including return and destruction of data.
That means buyers should not accept vague assurances like “we’re aligned with HDS principles.” They should ask to see how those principles are operationalized in the contract. If a vendor cannot clearly explain subcontractor use, incident reporting paths, reversibility timelines, export formats, or cross-border access exposure, the issue is not only legal. It is a sign that the architecture is being held together by optimism.
A strong HDS contract should help an end user answer five practical questions:
- What exact hosting activities are covered by the provider’s certificate?
- What service levels and controls are contractually committed?
- Who can access the data, under what conditions, and with what traceability?
- What happens if the vendor changes infrastructure, loses certification, or adds subprocessors?
- How do we get our data back cleanly if the relationship ends?
Where Xano fits naturally
This is the part where I mention Xano without turning into a product monologue wearing a compliance mustache.
The reality is that for healthcare teams in France, backend decisions carry regulatory weight. They need a vendor that supports API standardization, reusable logic, controlled access, and a lower operational burden while still meeting procurement and governance expectations.
Xano fits naturally here by providing these teams with a visual backend-as-a-service platform for APIs, business logic, and application development, with greater standardization and less infrastructure overhead. Xano also offers a dedicated HDS package to support regulatory and compliance needs. Xano’s HDS certification covers hosting activities 1–4 and 6, and the package includes an HDS contract in both English and French to help streamline procurement and compliance review.
Looking to build an HDS-compliant app? Learn more from the Xano Trust Center or schedule a demo.
