Healthcare DevOps Under ISO 13485 and ISO 27001: Traceability as a Side Effect of the Pipeline
Healthcare DevOps has a problem ordinary SaaS delivery does not: under ISO 13485 and ISO/IEC 27001 every production change needs traceability, verification, validation and a controlled release, and a team that meets those demands with documents alone stops shipping. For a HealthTech company running a cloud platform for remote patient monitoring and virtual care, Valletta's platform engineers built a GitHub Actions, Helm and Flux GitOps delivery path on Kubernetes in which the pull request, the scan reports, the SBOM and the declared state of each environment are the evidence.
Key Takeaways
- Kubernetes, Helm, Flux GitOps and GitHub Actions delivered independently deployable services across four isolated environments: development, staging/integration, UAT, production
- Five security checks ran on every change: SAST, dependency vulnerability scanning, container image scanning, SonarQube quality gates, SBOM generation
- Deployment state was declarative: production ran what Git declared, and a production change was a reviewed commit, not a manual step
- ISO 13485 demands (traceability, change control, verification, validation, release) and ISO/IEC 27001 controls (access control, change management, auditing) mapped onto pipeline stages that produce evidence as a side effect
- The platform went through processes related to both standards; this story describes the engineering, not a certification
The client is a HealthTech company running a cloud platform for remote patient monitoring and virtual care: connected medical devices, an HL7 FHIR R4 clinical data layer, a clinician portal, a patient mobile application and remote consultations. Valletta's senior backend, FHIR and platform engineers were embedded in the client's product team and owned Kubernetes architecture, CI/CD, GitOps, security tooling and supply-chain analysis, the work behind our DevOps and platform engineering service. The clinical data platform is covered in the HAPI FHIR on Kubernetes story and device integration in the remote patient monitoring story. For confidentiality we describe the engagement without naming the company or the people involved.
The Challenge: Ship Like a Cloud Team, Prove It Like a Device Manufacturer
The platform processed sensitive clinical information, so security was a first-order concern. It operated within a regulated healthcare environment and went through processes related to ISO/IEC 27001 and ISO 13485. The consequence: changes to production required greater traceability and process discipline than in an unregulated software environment. Independently deployable services made that harder: small changes, many releases, and every release is a place where a manual step can go unrecorded.
- Every production change had to be traceable: who changed what, why, what was verified, how it was released
- Security controls had to cover every change, not a sample: source code, dependencies, container images, secrets and the open-source supply chain
- Four environments had to stay consistent, so verification and validation happened on what production would run, and deployment itself could not put remote monitoring availability at risk
The Approach: Make the Pipeline the System of Record
Two ways exist to meet demands like these: document what people did afterwards, or design the delivery path so that doing the work leaves the record. The team chose the second, with one rule: if a control matters, it runs in the pipeline on every change and its output stays with the change. GitOps is the sharpest form of that rule. The desired state of every environment lives in Git as declarative configuration and Flux reconciles each cluster toward it, so nobody deploys by hand and a hand edit is reverted to what Git says. That is what change control wants and the habit engineers must unlearn, at the price of a Git-shaped detour and some reconciliation latency. The alternatives, a CI runner with long-lived cluster credentials or a person with kubectl, are where auditability quietly breaks.
The Solution: Seven Stages From Pull Request to Kubernetes
Seven stages followed the developer: Git repository, pull request, build with tests and security checks, container image, container registry, GitOps configuration, Kubernetes deployment.
Pull request to registry: build, tests and five security checks
GitHub Actions ran on the pull request: build, automated tests, then security. Source code went through SAST and a SonarQube quality gate, declared dependencies through vulnerability scanning, and the built container image through vulnerability scanning and SBOM generation. A failed gate stopped the merge, so every merge was reviewed by a person and by tooling; the output was a registry image with its scan reports and SBOM tied to the same change.
Dependency and image scanning both ran because they see different layers, declared packages and base-image packages, and the SBOM was generated in the build because an inventory produced with the artifact is accurate by construction, where one reconstructed for an audit is a guess. CISA's SBOM guidance treats that inventory as the supply-chain baseline.
Flux, Helm and four isolated environments
Services were packaged with Helm, environment-specific configuration was centralized apart from application code, and Flux reconciled each environment toward the GitOps configuration. Promoting a release meant a reviewed Git change referencing a new image version, with the same chart and pipeline behind every environment and only the values differing.
Four environments cost more than two, so the split has to earn its keep. Staging/integration is where services are verified together: does the change do what was specified. UAT is where product and clinical stakeholders validate the release: is it the right thing. Those are distinct ISO 13485 terms, and an isolated environment for each lets each be evidenced separately before production.
Ingress controllers, automated TLS certificate management, secrets management, access control and environment separation were platform properties, not per-service code: a control implemented once is evidenced once; per service it is evidenced many times and drifts.
Where ISO 13485 and ISO/IEC 27001 meet the pipeline
An engineering map, not a compliance opinion: the pipeline does not write the risk file or the requirements, it evidences that a change passed the controls.
| Pipeline stage | Control it enforces | Process demand it evidences |
|---|---|---|
| Pull request with review | Every change is proposed, reviewed and approved first | ISO 13485 change control, traceability; ISO/IEC 27001 change management |
| Build and automated tests | The change does what was specified, repeatably | ISO 13485 verification |
| SAST, SonarQube gate, dependency scan, image scan, SBOM | Defects, known vulnerabilities and a component inventory caught before promotion | ISO/IEC 27001 secure development, supplier management; ISO 13485 risk management |
| Flux reconciling Helm releases from Git | A declarative record of what ran where, and when it changed | ISO 13485 release process, documentation; ISO/IEC 27001 auditing |
| Isolated UAT before production | The release is validated against user needs | ISO 13485 validation |
| Access control, secrets, TLS, environment separation | Who reaches which environment; how secrets and transport are protected | ISO/IEC 27001 access control, infrastructure management |
The Results: Questions the Pipeline Answers Without a Meeting
- Every production change is a reviewed, scanned, declarative commit. Pull request, pipeline run, image, GitOps change and cluster state link to each other
- The artifact that was scanned is the artifact that runs. The registry image is the one the GitOps configuration references
- "What open-source is in this release" is a lookup, not an investigation. Each image ships with its SBOM and scan reports
- Deployment state is declarative and drift is visible. Manual steps were reduced, and a gap between Git and the cluster is something Flux reports and reverts
Availability followed from the same design. Remote monitoring may support ongoing patient care, so the platform leaned on Kubernetes primitives (restarts, scheduling, controlled rollouts) and on a GitOps property most teams miss: a rollback is a Git revert that Flux reconciles, recorded like the change it undoes. Independent services kept one capability's fault from spreading. More on this layer: what platform engineering services cover.
In a regulated environment the pipeline is not there to move code faster. It is there so that moving code produces its own evidence.
Frequently Asked Questions
What is ISO 13485?
ISO 13485 is the international standard for quality management systems in organizations that design, produce or service medical devices, including medical software. It adds process discipline around traceability, requirements management, change control, risk management, verification, validation, documentation and release processes. For engineers it means every production change must trace to a reviewed, verified and approved release, which is what a GitOps pipeline records on every change.
Can Kubernetes and GitOps be used in an ISO 13485 or IEC 62304 regulated environment?
Yes. Neither standard prescribes a deployment technology; both demand that changes are controlled, verified, traceable and released through a defined process. GitOps fits well because the desired state of every environment is a reviewed Git commit that Flux reconciles into the cluster, so deploying produces the audit trail. This platform ran Kubernetes, Helm, Flux and GitHub Actions within processes related to ISO 13485 and ISO/IEC 27001.
What is an SBOM and is it required for medical device software?
A software bill of materials (SBOM) is a machine-readable inventory of the components inside a software artifact, including open-source packages and their versions. Regulators increasingly expect one: US FDA premarket cybersecurity guidance asks for an SBOM for devices containing software, and CISA treats it as a supply-chain baseline. Generating it inside the build, as this pipeline did, makes it accurate by construction.
What is IEC 62304 and why does it matter for DevOps?
IEC 62304 is the international standard for medical device software life cycle processes: planning, requirements, architecture, implementation, verification, release and maintenance, scaled by a software safety classification. It matters for DevOps because the pipeline is where several of those activities happen: verification through automated tests, configuration management through Git, controlled release through deployment. General guidance: this project went through ISO 13485 and ISO/IEC 27001 processes.
How long does it take to get ISO 13485 certified?
It depends on how mature the quality management system is, how much required documentation exists, how many products and sites are in scope, and the certification body's availability. Valletta is an engineering partner, not a certification body, so we do not quote a duration. What engineering can do is take the pipeline off the critical path: when traceability, verification records, scan reports and SBOMs are produced on every change, that evidence is already done.
Need a Delivery Pipeline Your Auditors and Your Engineers Both Trust?
Regulated medical software teams face a false choice: ship slowly with a paper trail, or ship fast and reconstruct it before each audit. A GitOps pipeline with the controls built in, offered through our DevOps services, removes the choice, because the trail is produced by shipping.
Valletta works the forward-deployed way: the engineer who hears your problem builds the pipeline inside your repositories and clusters, verifies it with your QA and regulatory people, and leaves when you can run it without us. Read what a forward deployed engineer is, or go straight to hiring DevOps engineers.
Tell us what your release process looks like today: vallettasoftware.com/contact-us