Hosting a medical device backend on AWS, Azure, or GCP is an infrastructure choice with regulatory consequences. The notified body will read cloud configuration as part of the cybersecurity file and the supplier qualification file. Getting it right means understanding the shared responsibility model, EU data residency, and which vendor certifications actually count as evidence.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • The three hyperscalers are all technically capable of hosting a CE-marked medical device backend. None of them make the manufacturer compliant by default.
  • The shared responsibility model means the cloud provider secures the infrastructure, and the manufacturer secures everything built on top. Notified bodies audit the manufacturer's half.
  • EU data residency for GDPR is not just a region selection. It is a contractual, architectural, and monitoring question covering backups, logs, and support access.
  • HIPAA Business Associate Agreements are US artifacts. They do not substitute for GDPR data processing agreements under Article 28.
  • Vendor certifications (ISO 27001, SOC 2 Type II, ISO 27017, ISO 27018, HDS in France) are evidence for supplier qualification under EN ISO 13485 clause 7.4 and MDR Article 10, not a free pass.
  • Tibor has seen startups fail supplier qualification audits because the ISO 27001 certificate in the file was for the wrong legal entity inside a parent cloud group.

Why the cloud choice is a regulatory choice

Tibor has audited startups who picked a cloud provider in a founder weekend and discovered eighteen months later that the notified body wanted a supplier qualification file, a cybersecurity risk analysis, a data flow diagram, a transfer impact assessment, and a documented shared responsibility boundary for every single service they used. The cloud is not just infrastructure. Under MDR Annex I §17 and the QMS requirements of EN ISO 13485:2016+A11:2021, the cloud vendor is a supplier, the cloud region is a data processing location, and the cloud configuration is part of the device design.

Felix has seen the same pattern from the startup side. Founders usually pick a cloud provider based on credits, familiarity, or the preferences of the CTO. None of these are wrong. They just stop being sufficient the moment the device becomes regulated. The playbook is not to change providers. It is to document the choice inside the QMS so it survives audit.

What MDR and GDPR actually require

MDR Annex I §17.2 requires that software be developed and manufactured in accordance with the state of the art, taking into account the principles of development lifecycle, risk management including information security, verification and validation. §17.4 requires manufacturers to set out minimum requirements concerning hardware, IT networks characteristics, and IT security measures, including protection against unauthorised access, necessary to run the software as intended.

These two provisions together mean that the hosting environment is part of the device. If the device cannot run safely without a specific cloud configuration, that configuration is an input into the design and into the IFU. A notified body auditor will ask: where is the design decision recorded, where are the minimum IT requirements for the hosting environment documented, and how do you monitor that the environment continues to meet those requirements?

GDPR adds a second regulatory lens. Health data is a special category under Article 9. Processing requires a lawful basis and, for international transfers, an adequacy decision or standard contractual clauses under Chapter V. Hosting with AWS, Azure, or GCP in an EU region does not automatically solve the transfer question, because support staff, logs, and backups may touch other regions.

The state of the art for the cybersecurity side is EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1. Both assume that the security lifecycle covers the full operating environment, not just the source code.

The shared responsibility model, in plain terms

Every hyperscaler publishes a shared responsibility model. The specifics differ but the shape is the same. The cloud provider is responsible for the security of the cloud: physical datacentres, hypervisors, managed service internals. The customer is responsible for security in the cloud: identity and access management, network configuration, encryption keys, application logic, data classification, patching of anything the customer runs.

For a medical device manufacturer, this split is critical. The notified body does not audit Amazon or Microsoft or Google. The notified body audits the manufacturer. Every item on the customer side of the line must appear in the manufacturer's cybersecurity file, the manufacturer's supplier qualification file, or both.

Tibor gives startups a simple mental model: draw the line once, draw it explicitly, and put it in the design history file. Every service the device uses (object storage, database, serverless compute, identity provider, monitoring) gets a row. Each row has a provider-responsibility column and a manufacturer-responsibility column. The manufacturer-responsibility column is the cybersecurity work plan.

A worked example

Consider a Class IIa SaMD that processes diagnostic images. The team picks AWS, Frankfurt region, and uses S3 for image storage, RDS Postgres for clinical metadata, Lambda for image preprocessing, Cognito for authentication, and CloudWatch for logging.

The manufacturer draws the shared responsibility table. Provider responsibility: physical datacentre security, hypervisor patching, managed service internals, hardware lifecycle. Manufacturer responsibility: S3 bucket policies and encryption keys, RDS encryption at rest and in transit, Lambda code including all dependencies, Cognito password policies and MFA, CloudWatch log retention and access control, all IAM roles and policies, backup encryption, cross-region replication decisions, and the data processing agreement under GDPR Article 28.

The cybersecurity risk analysis then attacks each manufacturer responsibility. The threat model asks what happens if an IAM role is overly permissive, if a bucket is accidentally public, if a Lambda dependency has a CVE, if logs leak PII, if backups are exfiltrated. Each threat gets a control. Each control gets a verification activity. The activities feed into EN 62304 testing and EN IEC 81001-5-1:2022 security verification.

EU residency gets its own analysis. Frankfurt region covers primary storage. Backups are configured to stay in the EU. Support access is restricted to EU-based engineers where the provider offers it. CloudWatch logs are configured with a retention policy that matches the privacy notice. The data processing agreement and the associated standard contractual clauses cover any residual non-EU access.

That single worked example, written up as one section of the technical documentation, addresses MDR Annex I §17, GDPR Article 28 and Chapter V, and the supplier qualification requirements of EN ISO 13485 clause 7.4 in a single pass.

HIPAA BAAs versus EU processing agreements

US-focused cloud vendors love to talk about HIPAA Business Associate Agreements. These are genuine artifacts with real legal force in the United States. They are not the right instrument for an EU medical device.

The EU equivalent is a data processing agreement under GDPR Article 28. It covers the same ground (confidentiality, security measures, sub-processors, audit rights, breach notification) but against the GDPR framework, not HIPAA. Tibor has seen startups put a HIPAA BAA in their supplier file and assume it was enough. It was not. The notified body flagged the missing Article 28 agreement as a nonconformity, not because HIPAA is bad, but because it is not the applicable law.

For a startup targeting both markets, the answer is usually to execute both instruments: the HIPAA BAA for US processing and the GDPR Article 28 agreement for EU processing. All three hyperscalers offer both.

Certifications as vendor qualification evidence

Supplier qualification under EN ISO 13485 clause 7.4 requires the manufacturer to evaluate suppliers and keep records of the evaluation. For a cloud provider, the evidence usually includes third-party certifications.

The certifications that carry weight:

ISO 27001 is the baseline. All three hyperscalers hold it for all major services. The certificate scope and the certification body matter. Tibor has seen files where the certificate was for a subsidiary that did not actually operate the service in use. Check the scope statement.

SOC 2 Type II reports are produced in the United States but are widely accepted. Type II means the controls were tested over time, not just designed. These are usually available under NDA.

ISO 27017 covers cloud-specific security controls. ISO 27018 covers protection of personally identifiable information in public clouds. For health data workloads, both are relevant.

HDS certification (Hébergeurs de Données de Santé) is a French requirement for hosting health data. AWS, Azure, and GCP all offer HDS-certified regions. For EU-wide products this is not mandatory outside France but it strengthens the file.

C5 (Cloud Computing Compliance Criteria Catalogue) is a German BSI framework. Useful for German-language audits.

The trap: collecting certificates without reading them. Tibor has rejected supplier files where the ISO 27001 certificate was expired, issued to the wrong legal entity, or covered a different service than the one the startup was actually using. Supplier qualification means reading the scope, checking the expiry, and re-reviewing on a defined cycle.

The Subtract to Ship playbook

Felix has distilled the cloud qualification workflow into a compact sequence that a two-person startup can execute in one focused week.

Step one: pick one provider and one region, and write it down. Multi-cloud sounds sophisticated and creates three times the audit work. Startups should pick the provider with the best credits, the best team familiarity, and an EU region that fits the target market, and commit.

Step two: list every service used and draw the responsibility table. One row per managed service. Provider side on the left, manufacturer side on the right. This is the single most useful document in the supplier file.

Step three: collect the certifications. Download ISO 27001, ISO 27017, ISO 27018, SOC 2 Type II. Store them with expiry dates and a re-review trigger. Add HDS if selling in France and C5 if selling in Germany.

Step four: execute the GDPR Article 28 agreement. All three hyperscalers offer a standard data processing addendum online. Sign it, store it, reference it in the privacy notice.

Step five: configure the region and residency. Lock backups to the EU, configure log retention, restrict support access, document the decisions. Enable provider-side monitoring and alerts for misconfigurations.

Step six: attack the manufacturer side. Threat-model each row of the responsibility table, add controls, verify them, and feed the results into the cybersecurity risk file per EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1.

The outcome is a supplier qualification file and a cybersecurity file that reference each other. That pair will pass a notified body review.

Reality Check

  1. Can the team name the single cloud provider and region that hosts production, and produce a document that justifies the choice in regulatory terms?
  2. Is there a shared responsibility table listing every managed service used, with provider and manufacturer responsibilities clearly separated?
  3. Are ISO 27001, SOC 2 Type II, ISO 27017, and ISO 27018 certificates stored in the supplier qualification file with a re-review date?
  4. Is a GDPR Article 28 data processing agreement in place with the cloud provider, and does it cover sub-processors?
  5. Is backup data, log data, and support access restricted to EU regions, or is there a documented transfer impact assessment covering the gaps?
  6. Are IAM policies, network configurations, and encryption keys managed through infrastructure-as-code, with changes traceable to EN 62304 change control?
  7. Is there a documented process for monitoring provider announcements about new regions, deprecated services, and certification scope changes?

Frequently Asked Questions

Can a startup use the free tier of AWS, Azure, or GCP for a CE-marked medical device? Technically yes, but the supplier qualification and data processing agreements still apply. The price tier does not change the regulatory obligations.

Is on-premise hosting a safer bet for regulatory reasons? Not inherently. On-premise hosting shifts more responsibility onto the manufacturer, including physical security, hardware lifecycle, and disaster recovery. For most startups, a well qualified hyperscaler is lower risk than a self-managed server room.

Do the three hyperscalers offer the same level of regulatory evidence? Largely yes for the EU. All three hold ISO 27001, ISO 27017, ISO 27018, SOC 2 Type II, and HDS for relevant regions. Differences exist at the service level and in specific regulatory programs, so the choice should be driven by technical fit and team skills, not certification count.

What about newer EU-sovereign cloud offerings? These are relevant for public sector and sensitive health data workloads, particularly in France and Germany. For most medical device startups, the established hyperscaler regions in the EU remain the default.

Does the notified body audit the cloud provider directly? No. The notified body audits the manufacturer. The cloud provider is treated as a supplier, and the certifications plus the data processing agreement plus the supplier qualification file are what the auditor reads.

How often should supplier qualification be refreshed? At least annually, and on any major provider change, certification expiry, or new sub-processor. This should be a scheduled item in the QMS under EN ISO 13485 clause 7.4.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §17.2, §17.4.
  2. EN ISO 13485:2016+A11:2021, Medical devices, Quality management systems, Clause 7.4 (Purchasing).
  3. EN IEC 81001-5-1:2022, Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, Activities in the product lifecycle.
  4. MDCG 2019-16 Rev.1 (December 2019, Rev.1 July 2020), Guidance on Cybersecurity for medical devices.
  5. Regulation (EU) 2016/679 (GDPR), Article 28 and Chapter V.