What you will learn
By the end of this topic, you should be able to define the regulated system boundary; control infrastructure and delivery pipelines; implement security, observability and recovery; protect data; clarify cloud-provider responsibilities; and produce evidence that connects each deployed environment to an approved product configuration.
The cloud, platform and DevOps role
Where a hosted service contributes to a medical-device function, the platform is part of the product system—not merely an IT utility. Platform teams translate architecture, safety, security, privacy, availability and regulatory needs into reproducible environments and controlled operations.
Platform engineer
Provide controlled runtime, networking, identity, storage and deployment capabilities.
Delivery engineer
Make build, test, approval and deployment paths repeatable and traceable.
Reliability engineer
Define service indicators, alerts, capacity, recovery and incident learning.
Evidence contributor
Retain configuration, change, access and operational records suitable for review.
Define the product and responsibility boundary
Map device software, applications, APIs, cloud services, administrative interfaces, mobile clients, identity providers and external integrations. For every interface, identify data, trust, timing, availability and failure assumptions. Use MTL-111 — Data, Connectivity and Interoperability to connect this work to the system architecture.
Treat infrastructure as a controlled product configuration
- Define infrastructure through reviewed, version-controlled code where practical.
- Separate development, test and production environments with explicit access rules.
- Control images, packages, regions, service tiers, feature flags and runtime parameters.
- Detect configuration drift and unauthorised changes.
- Link each environment to its approved application, database and interface versions.
- Protect backups and verify restoration.
Make the delivery pipeline part of the evidence chain
Secure pipeline credentials, protect artefact integrity and ensure a failed gate cannot be silently bypassed.
Engineer security into platform operations
Apply least privilege, strong workload identity, secrets management, encryption, network segmentation, hardened baselines, dependency control and vulnerability response. Security controls must support safety and intended clinical use. Coordinate with MTL-109 — Medical-device Cybersecurity.
Observe what matters without creating new risk
Define logs, metrics, traces and audit events from safety, performance, security and support needs. Synchronise time, preserve event provenance and protect records from alteration or excessive access. Alerts need owners, thresholds, escalation and a tested response—not merely a dashboard.
Design for failure, recovery and degraded operation
Set measurable availability, latency, durability and recovery objectives based on clinical impact. Test backup restoration, regional failover, capacity limits, dependency failure and rollback. Define what users and connected devices should do when the service is slow, unavailable or inconsistent.
Control data throughout its hosted lifecycle
Document collection, location, tenancy, access, encryption, retention, deletion, backup and transfer. Production data should not drift casually into development environments. Privacy professionals should review technical choices using MTL-112 — Privacy and Data Protection by Design.
Control continual delivery by impact, not ceremony
Classify application, infrastructure, dependency and provider changes; assess safety, security, privacy and regulatory impact; define proportionate verification; and retain the decision. Emergency changes need rapid control, explicit authority and retrospective review. Canary or progressive deployment can reduce exposure only when monitoring and rollback are trustworthy.
Cloud services create shared responsibility, not transferred responsibility
Evaluate providers and critical managed services for capability, availability, security, data location, change notification, incident support, subcontractors and exit arrangements. Record which controls belong to the provider and which remain with the manufacturer. Test the assumptions that the architecture places on each service.
Common misconceptions
“The cloud provider is compliant, so the product is compliant.”
Provider certifications do not validate the manufacturer’s architecture, configuration, intended use or evidence.
“Infrastructure changes do not change the device.”
A platform change can alter security, availability, performance, data handling or clinical behaviour.
“More telemetry is always safer.”
Monitoring must be useful, proportionate and designed around privacy, security and retention obligations.
Authoritative starting points
The deployed platform is part of the medical-device evidence
Make infrastructure, delivery, operations and change as controlled and traceable as the application they support.