GDPR and HDS on Azure: residency, transfers, health hosting

Most of the regulation is governance. A handful of articles land squarely on the estate.

Article 25, data protection by design and by default. The second half is the harder one. Defaults must be the restrictive option: minimal collection, minimal retention, minimal access, unless a decision was made to widen them. In an Azure estate that means the policy set is the default, not the exception process.

Article 30, records of processing. A register of processing activities, purposes, categories, recipients, transfers and retention. It cannot be accurate without a real data inventory, and an inaccurate register is the first thing a supervisory authority notices.

Article 32, security of processing. Pseudonymization and encryption, confidentiality, integrity, availability and resilience, the ability to restore access in a timely manner, and a process for regularly testing the effectiveness of the measures. That last clause is an obligation, and it is the one most organizations have no record of meeting.

Articles 33 and 34, notification. 72 hours to the supervisory authority from becoming aware. The architecture question is how long awareness takes.

Articles 15, 17 and 20. Access, erasure and portability, each with a deadline, each requiring a path through every system that holds the data including backups and analytics copies.

Chapter V, transfers. Adequacy, standard contractual clauses, and a transfer impact assessment where the destination legal framework matters. Canada holds a partial adequacy decision covering commercial organizations subject to PIPEDA, which simplifies many Canada-to-EU arrangements without removing anything in Article 32.

Article 28, processors. Sub-processor authorization and a documented chain. In practice this means knowing every service that touches the data, which returns to the inventory.

What HDS adds when the data is French health data

Hosting personal health data collected during prevention, diagnosis, care or medico-social follow-up on behalf of a third party requires certification as an hébergeur de données de santé under article L.1111-8 of the Code de la santé publique. The referential is built on ISO 27001, ISO 20000-1 and ISO 27018 plus health-specific requirements, and it is audited by an accredited certification body.

Two points decide most projects. First, the certification is scoped to activities, six of them, running from physical infrastructure through virtual infrastructure, application platform, maintenance, administration and backup. Hosting on a certified provider covers the activities that provider performs, not yours. If you operate the platform, administer the infrastructure or hold the backups for a health customer, the obligation may attach to you. Second, the updated referential tightens expectations on hosting within the European Union and on disclosing exposure to non-EU law, which makes region and sub-processor choices a certification question rather than a preference.

Because the referential rests on ISO 27001, the work described on the ISO 27001 page is a prerequisite here rather than an alternative.

What we design and enforce in Azure

Region as an inherited policy. An allowed locations assignment at the management group level, covering EU regions or the specific French regions where the health scope requires them. Every future subscription inherits it, and the exception process is visible.

The EU Data Boundary, configured and understood. We enable what it covers and write down what it does not, rather than treating it as a blanket answer. A commitment you cannot describe precisely is not a commitment you can defend to a supervisory authority.

The four things that actually break residency. Diagnostic settings routed to a Log Analytics workspace in another region. Monitoring or ticketing outside the EU. Support and administration paths. And model deployments: a global deployment type can process a prompt wherever capacity exists, so for EU-scoped workloads the deployment type is a residency decision and not a footnote. We check all four, and at least one is usually wrong.

Encryption with a key story. Platform encryption as a baseline, customer-managed keys in Key Vault or Managed HSM where you need to hold the key, documented rotation, and TLS minimums enforced by policy.

No public path, and identity as the control point. Private endpoints on data and AI services, private DNS, hub-and-spoke segmentation as described on the Azure landing zone page, Microsoft Entra ID with Conditional Access and Privileged Identity Management, and scheduled access reviews.

Erasure, export and retention as tested procedures. Retention set per category, lifecycle rules on storage, an export path producing structured output for one individual, and a deletion path that has been executed in a test including against backups. Building these under a one-month statutory clock is how organizations end up running manual database queries.

Restore testing as an Article 32 control. Backup policies as code, recovery objectives written down, restores scheduled and recorded, because the regulation asks for the ability to restore in a timely manner and for evidence that you test it.

Detection sized to 72 hours. Microsoft Defender for Cloud for posture, Microsoft Sentinel rules for exfiltration and anomalous access, and an escalation path naming who assesses the risk and who contacts the authority.

What the evidence pipeline produces

Azure Policy compliance state for allowed locations, with dated history proving where data has been permitted to land.
A resource inventory by region and by service, including log workspaces and AI endpoints.
The data flow and sub-processor register that feeds Article 30 and the transfer assessment.
Erasure and export execution logs with response times.
Restore test records against stated recovery objectives, satisfying the testing clause.
Access logs, PIM activation history and access review outcomes.
The ISO 27001 evidence pack, reused directly where HDS is in scope.
A written determination of which HDS activities you perform and which the provider performs.

What you keep

The records of processing input pack: flows, categories, recipients, regions, retention.
A transfer impact assessment input pack, including the region and deployment-type decisions and the reasoning behind them.
The policy set as code, including the region assignment, in your repository.
Tested erasure, export and restore runbooks.
The HDS activity scope analysis, in writing, so the question is settled before a customer asks.

Who this is for

Canadian and American companies selling into the European Union whose first EU customer sent a data protection questionnaire. French and European health technology companies whose customers require an HDS-hosted platform. Organizations whose DPO looked at the Azure estate and could not answer where the logs go. Teams already holding ISO 27001 who now need the residency and transfer half in place.

Who this is not for

We are not an HDS-certified hoster, we do not host, and we cannot issue any certificate. We do not act as your data protection officer, and we are not lawyers: transfer assessments and DPIAs are signed by people accountable inside your organization. If your personal information is Quebec data with no European nexus, Loi 25 is the page that applies, and the transfer question there is answered differently.

Compliance architecture, the engagement that delivers this.
ISO 27001 on Azure, the prerequisite where HDS is in scope.
Loi 25 and data residency, the Quebec equivalent.
Healthcare, the sector context.
Compliance, the pillar.

Questions we get

Is Azure GDPR compliant?

Microsoft provides the contractual terms and the technical capability, including the EU Data Boundary. Compliance is a property of your processing: which regions you deploy in, what you log, what you retain, who you send data to, and whether you can erase and export on request. That configuration is the work.

Can a Canadian company process EU personal data?

Yes. The EU maintains a partial adequacy decision covering Canadian commercial organizations subject to PIPEDA, which removes the need for standard contractual clauses in many arrangements. It does not remove Article 32 security obligations or the need to know where the data actually sits.

Are you HDS certified?

No, and we will not imply otherwise. HDS certification is issued by an accredited body against the French referential, and it applies to hosting activities. We design and build the Azure architecture on top of a certified provider, and we help you determine which of the six regulated activities you perform yourselves.

Does hosting on an HDS-certified provider make our platform HDS compliant?

No. The certification covers the activities the provider performs. If you operate the application platform, administer the infrastructure or run the backups for a health customer, those are separate regulated activities and the obligation may fall on you. Determining that scope honestly is the first deliverable.

What breaks EU residency in practice?

Rarely the database. It is diagnostic logs shipped to a workspace in another region, a monitoring tool outside the EU, a support path, and model deployments that process prompts wherever capacity exists. Those are the four we check first, and at least one is usually wrong.

How does the 72-hour breach clock affect the architecture?

The clock starts when you become aware, so the design question is how long awareness takes. Detection rules, alert routing to a named person, and a documented assessment path are what make 72 hours achievable. Without them the deadline is met by luck.

Have a question about this work?

Three fields. An architect reads it and answers within one business day.

What GDPR actually requires of an architecture