--- title: Cloud Services for Medical Devices: Regulatory Implications Under MDR description: Running a medical device on cloud infrastructure brings lifecycle, cybersecurity, and data protection obligations. Here is what MDR requires for cloud-hosted medical software. authors: Tibor Zechmeister, Felix Lenhard category: Software as a Medical Device primary_keyword: cloud services medical devices MDR canonical_url: https://zechmeister-solutions.com/en/blog/cloud-services-medical-devices-mdr source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # Cloud Services for Medical Devices: Regulatory Implications Under MDR *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* > **A medical device that runs on cloud infrastructure is still a medical device, and the cloud is part of the device. MDR Annex I Section 17.2 requires software to be developed under the state of the art, including the principles of development lifecycle, risk management, and information security. Section 17.4 requires the manufacturer to set out the minimum requirements concerning hardware, IT networks characteristics, and IT security measures, including protection against unauthorised access, necessary to run the software as intended. For a cloud-hosted medical device, those minimum requirements have to describe the cloud environment the device depends on. Provider, region, configuration, redundancy, patching cadence, and the cybersecurity controls the manufacturer relies on. The cloud provider is SOUP, the deployment is part of the technical documentation, and the manufacturer. Not the hyperscaler. Owns the regulatory obligations.** **By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.** --- ## TL;DR - A cloud-hosted medical device is a medical device whose operating environment includes third-party infrastructure. The cloud is inside the regulatory perimeter, not outside it. - MDR Annex I Section 17.2 and Section 17.4 apply to cloud-deployed software the same way they apply to on-premise software. Including the obligation to specify minimum hardware, IT network, and IT security requirements. - Cloud platform components (compute, storage, managed databases, identity services, container runtimes) are SOUP under EN 62304:2006+A1:2015 Section 3.29 and must be managed under Sections 5.3, 7, and 8. - Cybersecurity obligations run through EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1. The manufacturer is responsible for the full cybersecurity lifecycle of the cloud-deployed device. The hyperscaler's shared responsibility model does not transfer regulatory accountability. - Data protection under the GDPR intersects with MDR obligations but does not replace them. A cloud configuration that is GDPR-compliant is not automatically MDR-compliant, and vice versa. - When the cloud provider updates the underlying service, the manufacturer has to evaluate the change under EN 62304:2006+A1:2015 Section 8 configuration management and Section 9 problem resolution. Auto-updated managed services require explicit change-handling processes. - Regional deployment decisions (EU versus non-EU) affect both data protection and the credibility of the Notified Body's review of the IT environment. --- ## When cloud services are in scope of the MDR A cloud service is in scope of the MDR whenever the medical device depends on it to perform its intended purpose. The test is functional, not contractual. If the device cannot deliver its intended purpose without the cloud component, the cloud component is part of the device for regulatory purposes. Three deployment patterns cover most of what Tibor sees in practice. The first is the pure cloud-hosted SaMD. The medical function runs entirely on cloud infrastructure, users interact through a browser or a thin client, and the cloud is where the device exists. The second is the hybrid device. A hardware device or a local application that calls cloud services for part of its function, for example a mobile app that performs local capture and sends data to a cloud model for interpretation. The third is the auxiliary cloud. The medical function runs locally, but the cloud holds supporting services like updates, license checks, logging, or analytics that the manufacturer claims are part of the medical device. In all three patterns the cloud is inside the MDR perimeter if the medical function depends on it. The second and third cases are where founders sometimes try to argue the cloud is "just infrastructure" and outside the regulated scope. That argument fails if the device cannot be used as intended when the cloud component is absent. A Notified Body will ask the same question the intended purpose asks: what does the device do, and does it do it without this cloud service? If the answer is no, the cloud is in scope. What is not in scope: cloud services that have no bearing on the medical function and no path to it. A marketing website hosted on the same cloud account is not part of the device. An internal finance system is not part of the device. The scoping exercise is real and worth doing carefully, because every component that ends up inside the regulatory boundary carries lifecycle weight under EN 62304:2006+A1:2015 and cybersecurity weight under EN IEC 81001-5-1:2022. See post 391 on SOUP scoping and post 425 on architectural boundaries for the narrowing move. ## SOUP treatment for cloud components Every cloud component the device relies on is SOUP. The managed compute service is SOUP. The managed database is SOUP. The object storage bucket backing clinical data is SOUP. The identity provider is SOUP. The container orchestrator is SOUP. The load balancer is SOUP. The cloud provider's TLS termination is SOUP. The fact that the manufacturer did not write any of this code, and often cannot inspect it, is the exact condition EN 62304:2006+A1:2015 Section 3.29 describes. Software already developed, generally available, not developed for incorporation into the device, with no adequate development records available to the manufacturer. The SOUP obligations follow. Under EN 62304:2006+A1:2015 Section 5.3, each cloud component in scope has to have functional and performance requirements specified from the device's point of view. "We use managed database service X, version/tier Y, in region Z, and the device depends on the following behaviours. Read latency under N milliseconds, durability guarantees, transactional consistency for operation class W". That is the content. The requirement is not to re-document the cloud provider. The requirement is to state what the device depends on, so that a change to the provider can be evaluated against what the device actually needs. Section 7 requires risk analysis of cloud components that could contribute to hazardous situations identified in the EN ISO 14971:2019+A11:2021 risk file. Cloud components can fail in ways first-party code cannot. Regional outages, provider-side configuration errors, credential revocation, shared-tenancy noisy-neighbour effects, silent API deprecations. Each of these failure modes needs to be considered where it could reach a patient. The mitigations sit either inside the cloud configuration (multi-AZ redundancy, automated failover, timeouts, circuit breakers) or in the device's handling of cloud failure (graceful degradation, explicit error states visible to the user, local fallback where possible). Section 8 requires configuration management. Identifier, version/tier, supplier, region, and the exact configuration state of each component, reproducibly linked to each release of the device. Infrastructure-as-code (Terraform, Pulumi, CloudFormation, Kubernetes manifests) is the engineering expression of this obligation. A cloud deployment that is configured manually through a provider console cannot satisfy configuration management at audit quality, because the state is not reproducible and not version-controlled. Every serious cloud-hosted medical device Tibor has seen treats infrastructure-as-code as non-negotiable for exactly this reason. The SBOM for a cloud-hosted device extends beyond the application dependencies into the infrastructure. The full component inventory includes the application SOUP (libraries, frameworks) and the cloud SOUP (services, runtimes, managed components) with their configuration state. That combined inventory is the basis for the vulnerability monitoring process under EN IEC 81001-5-1:2022. See post 391 for the SOUP and SBOM foundations. ## Cybersecurity implications. Annex I Section 17.4 and EN IEC 81001-5-1:2022 MDR Annex I Section 17.4 is explicit. For devices that incorporate software or that are themselves software, the manufacturer shall set out the minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended. For a cloud-hosted device, the minimum requirements have to describe the cloud environment the device is intended to run in, because that is the operating environment. In practice the minimum requirements document for a cloud-hosted device covers: the cloud provider(s) the device is validated to run on, the regions the device is deployed in, the service tiers and configurations required (network isolation, encryption at rest and in transit, identity and access controls, logging and monitoring), the patching and update cadence for the underlying services, the operator's responsibilities (for professional users accessing the device), and the cybersecurity controls the manufacturer has implemented and the ones the operator is expected to maintain. EN IEC 81001-5-1:2022 provides the harmonised cybersecurity lifecycle that operationalises these obligations. For cloud-hosted devices the relevant activities include: secure design of the cloud architecture (network segmentation, least-privilege IAM, secrets management, defence in depth), secure implementation (infrastructure-as-code under review, image scanning, hardened base images), vulnerability monitoring across both application and cloud components, patching and release under controlled change, and decommissioning including data destruction. MDCG 2019-16 Rev.1 is the interpretive guidance on medical device cybersecurity that sits alongside EN IEC 81001-5-1:2022. Its single most important point for cloud-hosted devices is that the manufacturer cannot transfer cybersecurity responsibility to the cloud provider. The hyperscaler's "shared responsibility model" is a useful engineering concept. The provider secures the platform, the customer secures the configuration and the workload. But it is not a regulatory transfer. The CE-marked manufacturer owns every cybersecurity obligation for the device. The shared responsibility model describes where the work is done, not who is accountable to the Notified Body when something goes wrong. ## The data protection intersection The GDPR applies to personal health data processed by a medical device independently of the MDR. The two regulations intersect but do not overlap. An MDR-compliant device is not automatically GDPR-compliant, and a GDPR-compliant deployment is not automatically MDR-compliant. The cloud deployment has to satisfy both. For cloud-hosted medical devices the practical intersections are three. First, regional deployment. Where the personal data is processed affects the legal basis and transfer mechanisms under the GDPR, and it affects the Notified Body's ability to inspect the environment. Second, the data processing agreement between the manufacturer and the cloud provider. A standard provider DPA is a starting point, not the end of the analysis, and the specific clauses around sub-processors and incident notification matter for both GDPR and MDR vigilance. Third, data subject rights. The ability to satisfy access, rectification, and erasure requests has to be built into the cloud architecture, not retrofitted. The two regulations should be treated as parallel workstreams that reference the same cloud architecture document. The architecture is designed once; the MDR file and the GDPR file both point to it. Trying to satisfy each regulation with a separate architecture leads to inconsistencies that fail both reviews. We address the GDPR intersection in more depth in post 395. ## Change control when the cloud provider updates Cloud providers update their services continuously. Some updates are transparent, some are announced with a deprecation window, some change behaviour silently. The manufacturer's change control process has to handle all of these without pretending they do not happen. The classification that works. Provider patches with no behaviour change to the APIs and capabilities the device depends on are recorded and subject to lightweight evaluation. Provider updates that change behaviour in APIs the device uses, or that deprecate capabilities, trigger a full evaluation under EN 62304:2006+A1:2015 Section 8. Requirements impact, risk impact, verification impact, regression test plan. And potentially a change-to-the-device analysis under MDCG change guidance. Provider outages and incidents feed into the problem resolution process under Section 9 and, where patient impact is plausible, into the vigilance system under MDR Articles 87-92. The operational move that supports this is a deliberate version- and configuration-pinning posture on every cloud component the device depends on. Pin the service tier. Pin the runtime version. Pin the image versions. Pin the library versions inside managed runtimes where the provider allows it. Where the provider does not allow pinning (fully managed services that auto-update), the manufacturer has to have a monitoring channel for provider change announcements and a process to act on them before the change reaches production. "The cloud provider will handle it" is not a change control process. ## Regional deployment. Where the workload runs matters The region in which a cloud-hosted medical device runs is not just a latency decision. It is a regulatory decision that touches data protection, cybersecurity review, and the credibility of the technical file. Deployment in an EU region keeps personal data within the EU/EEA and removes the international transfer question from the GDPR analysis. It also gives the Notified Body an environment that its auditors can reason about under European data protection and cybersecurity norms. Deployment in a non-EU region is not automatically non-compliant, but it adds layers of analysis. Adequacy decisions, standard contractual clauses, transfer impact assessments, and the credibility of the cybersecurity assurance in a jurisdiction with different legal visibility. For a startup shipping a cloud-hosted medical device in the EU, the default should be EU-region deployment unless there is a specific reason to choose otherwise. The reason should be documented, and the alternative region's suitability assessed and recorded. Tibor has seen Notified Body questions on this exact point land with manufacturers who had chosen a non-EU region for cost reasons and could not produce a coherent justification. ## Common mistakes - **Assuming the cloud provider handles MDR.** It does not. The cloud provider is SOUP. The manufacturer owns the regulatory file. No AWS, Azure, or GCP contract transfers MDR accountability. - **Configuring the cloud manually through the provider console.** Manual configuration cannot satisfy EN 62304:2006+A1:2015 Section 8 configuration management. Infrastructure-as-code is the minimum. - **Treating the cloud as outside the SBOM.** The cloud components are SOUP and belong in the inventory, the risk analysis, and the vulnerability monitoring process. - **Ignoring provider auto-updates.** Managed services change. A change control process that pretends they do not is the one most Notified Bodies will probe first. - **Conflating GDPR compliance with MDR compliance.** They are parallel. Each needs its own analysis, grounded in a single documented cloud architecture. - **Choosing non-EU regions without documented justification.** Legal and not always wrong, but expensive to defend without advance preparation. - **Writing an Annex I Section 17.4 minimum requirements document as a one-line reference to the cloud provider's marketing page.** The document has to describe the environment the device needs, not the environment the provider sells. ## The Subtract to Ship angle Cloud infrastructure is a category where subtraction compounds fast. Every cloud service inside the regulatory perimeter is another SOUP item to identify, specify, risk-analyse, configuration-manage, and vulnerability-monitor. The team that adopts five managed services "because they are convenient" has added five permanent process loads to the lifecycle. The team that chooses two managed services and does more in-house has a smaller surface to manage. The subtraction moves that work in practice. First, narrow the regulated boundary. The cloud components that serve the medical function stay inside EN 62304:2006+A1:2015 treatment. Non-medical services (marketing, billing, analytics-that-do-not-feed-the-device) stay outside if the architecture separates them cleanly. This is the same boundary move we apply to application SOUP in post 391. Second, prefer fewer, well-understood services over more services that each carry a separate lifecycle burden. A smaller managed-service list is cheaper to audit, monitor, and change-control than a large one. Third, pin everything you can. Pinning is free; reconstructing what version of a service was running six months ago when an incident happened is not. Fourth, choose the region deliberately. EU by default, non-EU only with documented justification. The cost of a late region change is high. For the broader methodology, see post 065. For the cybersecurity lifecycle that runs on top of this, see post 393. For MDR risk controls that the cloud architecture has to implement, see post 425. ## Reality Check. Is your cloud deployment audit-ready? 1. Have you written a minimum requirements document under MDR Annex I Section 17.4 that describes the specific cloud environment the device needs to run as intended. Provider, region, services, configurations, security controls? 2. Is every cloud component the device depends on listed in the SBOM, with identifier, version/tier, supplier, region, and configuration state? 3. Is the cloud deployment defined entirely in infrastructure-as-code under version control, and is the exact state of each release reproducible from that code? 4. Does your EN ISO 14971:2019+A11:2021 risk file address cloud-specific failure modes. Regional outages, provider configuration errors, API deprecation, credential compromise, shared-tenancy effects. Where they could reach a patient? 5. Do you have a running vulnerability monitoring process under EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1 that covers both application SOUP and cloud service SOUP? 6. Do you have a documented change control process for cloud provider updates, including managed services you cannot pin, with evaluation, verification, and rollout steps? 7. Is the regional deployment decision documented with its rationale, and does the GDPR analysis match the architecture the MDR file describes? 8. If the cloud provider had a significant incident tomorrow, could you trace exactly what was running, what was affected, and what the device did during the incident? Any question you cannot answer with a clear yes is a gap between current practice and what the Notified Body will want to see. ## Frequently Asked Questions **Is a cloud-hosted SaaS medical device treated differently from an on-premise medical device under the MDR?** No. The MDR does not distinguish by deployment model. A medical device is a medical device under Article 2(1) regardless of where it runs. What changes with cloud deployment is how the Annex I Section 17.4 minimum requirements document is written and how the SOUP, cybersecurity, and change-control processes are executed. Because the operating environment is infrastructure the manufacturer does not own. The obligations are identical; the operational pattern is different. **Does my cloud provider's certifications (ISO 27001, SOC 2, HIPAA) mean I am MDR-compliant?** No. Provider certifications demonstrate that the provider's platform meets certain security standards. They do not transfer MDR accountability to the provider, and they do not satisfy the manufacturer's obligations under EN 62304:2006+A1:2015, EN IEC 81001-5-1:2022, or MDR Annex I Section 17. Provider certifications are useful evidence to cite inside the manufacturer's own file, but they are not a substitute for the file. **Can I deploy a cloud-hosted medical device in a non-EU region?** Yes, but the decision has to be documented and justified, and the data protection and cybersecurity analyses have to reflect the region actually used. For CE marking the MDR does not prohibit non-EU deployment, but the GDPR transfer rules, the Notified Body's ability to review the environment, and the credibility of the supporting evidence all become harder outside the EU/EEA. The default recommendation for a first CE mark is EU-region deployment. **How do I handle a managed cloud service that auto-updates without my control?** You cannot stop the updates, but you can and must have a process that expects them. The process includes subscribing to the provider's change announcements, maintaining a documented understanding of which behaviours the device depends on, running integration tests on a schedule that catches breaking changes, and having a change control path that evaluates and responds before the change reaches the production device. If no such process exists, the configuration management obligation under EN 62304:2006+A1:2015 Section 8 is not being met. **Is cloud deployment SOUP or something else under EN 62304:2006+A1:2015?** Cloud services that the device depends on are SOUP under the Section 3.29 definition. Software already developed, generally available, not developed for incorporation into the device, with no adequate development records available to the manufacturer. The SOUP obligations in Sections 5.3, 7, and 8 apply. The standard pre-dates the current cloud era but the definition fits cleanly, and Notified Bodies treat it that way. **Do I need EN IEC 81001-5-1:2022 compliance if my device only uses well-known hyperscaler services?** Yes. EN IEC 81001-5-1:2022 is the harmonised cybersecurity lifecycle standard for health software and health IT systems under MDR Annex I Section 17.2 and Section 17.4. The choice of cloud provider does not remove the manufacturer's lifecycle obligations. It just shapes how the activities are executed. Using a hyperscaler makes some controls easier to implement and some monitoring easier to source; it does not make the standard inapplicable. ## Related reading - [What Is Software as a Medical Device (SaMD)?](/blog/what-is-software-as-medical-device-samd-mdr) – the qualification and classification foundations this post builds on. - [SOUP and OTS Software Under MDR](/blog/soup-ots-software-mdr) – the parent SOUP treatment that cloud components plug into. - [Medical Device Cybersecurity Under MDR and EN IEC 81001-5-1:2022](/blog/medical-device-cybersecurity-mdr) – the cybersecurity lifecycle this post references. - [GDPR and MDR Intersection for Medical Software](/blog/gdpr-mdr-medical-software) – the data protection layer the cloud deployment also has to satisfy. - [Software Architecture Boundaries for MDR Scope Control](/blog/software-architecture-mdr-scope) – the boundary move that keeps the regulated cloud surface small. - [Annex I Section 17 Software Requirements](/blog/annex-i-section-17-software-requirements) – the GSPRs this post operationalises for cloud deployment. - [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) – the methodology pillar this post applies to cloud infrastructure. ## Sources 1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex I, Section 17 (software and electronic programmable systems), including Section 17.2 (development lifecycle, risk management, information security, verification and validation) and Section 17.4 (minimum requirements concerning hardware, IT networks, and IT security measures). Official Journal L 117, 5.5.2017. 2. EN 62304:2006+A1:2015. Medical device software. Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015). Sections 3.29 (SOUP definition), 5.3 (software requirements analysis), 7 (software risk management), 8 (software configuration management), 9 (software problem resolution). 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 life cycle (IEC 81001-5-1:2021). 4. EN ISO 14971:2019+A11:2021. Medical devices. Application of risk management to medical devices. 5. EN ISO 13485:2016+A11:2021. Medical devices. Quality management systems. Requirements for regulatory purposes. 6. MDCG 2019-16 Rev.1. Guidance on Cybersecurity for medical devices. December 2019; Rev.1 July 2020. --- *This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on the regulatory implications of deploying medical device software on cloud infrastructure. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post. EN 62304:2006+A1:2015 and EN IEC 81001-5-1:2022 are the harmonised tools that provide presumption of conformity with the software-lifecycle and cybersecurity aspects of MDR Annex I Section 17, not independent authorities. For startup-specific regulatory support on cloud architecture, SOUP management, and cybersecurity lifecycle implementation for cloud-hosted medical devices, Zechmeister Strategic Solutions is where this work is done in practice.* --- *This post is part of the [Software as a Medical Device](https://zechmeister-solutions.com/en/blog/category/samd) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*