DevOps is compatible with MDR Annex I Section 17 and EN 62304:2006+A1:2015 when the CI/CD pipeline is treated as the primary source of regulatory evidence, not as a workaround for the regulation. Continuous integration produces the verification evidence the standard requires at clause 5.6 and clause 5.7. Continuous deployment operates inside a release boundary where clause 5.8 controls which versions reach clinical use. Pipeline artefacts — build records, test logs, static analysis reports, signed binaries, deployment manifests — become the records the technical file references. The quality gate pattern, where a pipeline stage refuses to advance until defined evidence is present and passing, is how the manufacturer discharges the MDR Article 10 obligation to operate a documented, effective lifecycle process without manual ceremony at every change.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • DevOps for medical software means the CI/CD pipeline is the evidence engine for the EN 62304:2006+A1:2015 lifecycle, not a separate operational concern running beside it.
  • Continuous integration delivers the clause 5.6 integration testing and clause 5.7 system testing activities automatically, with logs retained as the verification record the technical file points at.
  • Continuous deployment is bounded: the pipeline can deploy freely to development and staging, but a release gate runs clause 5.8 before any build reaches clinical use under MDR Annex I Section 17.
  • Pipeline artefacts — build manifests, SBOMs, test results, static analysis, signed binaries, deployment records — are the configuration management and verification records under clause 8 and clause 5.
  • The quality gate pattern refuses to promote a build to the next stage unless specific evidence is present and passes defined thresholds. The thresholds map to the software safety class.
  • Pure continuous deployment to production breaks MDR when there is no release authorisation, no documented impact analysis, no traceability closure, and no named role accountable for the released version.
  • The common mistakes are predictable: treating the pipeline as infrastructure rather than as the QMS process it actually is, and treating regulatory documentation as a second track instead of as an output of the pipeline.

What DevOps adds to the EN 62304:2006+A1:2015 lifecycle

The reason DevOps is worth the reconciliation effort for medical software is not speed. It is evidence quality. A well-run CI/CD pipeline produces, as a by-product of normal engineering work, exactly the kind of reproducible, timestamped, signed, structured evidence that EN 62304:2006+A1:2015 asks for — evidence that a manual lifecycle struggles to match even with substantial documentation effort.

Consider what a mature pipeline does every time a commit lands. It fetches a known source at a known revision. It resolves dependencies against a pinned manifest. It builds the software in a reproducible environment. It runs unit tests, integration tests, system tests, static analysis, and security scans. It generates a software bill of materials. It signs the resulting artefacts. It records the full event in a log that is immutable, queryable, and retained. Every one of those outputs maps directly to an activity the standard expects. The pipeline is not replacing the lifecycle — it is executing it, and producing the evidence in the same motion.

The DevOps addition on top of EN 62304:2006+A1:2015 is the insistence that the evidence capture is automated, that the pipeline is itself a versioned, reviewed, controlled artefact, and that the path from a commit to a released version is visible end-to-end without a human reconstructing it. For a resource-constrained startup this is the only version of the lifecycle that scales — the manual version runs out of hours before it runs out of work.

For the deeper EN 62304:2006+A1:2015 activity map that the pipeline operationalises, see post 376. For the release activity the pipeline must still run at the boundary, see post 387.

Continuous integration as verification evidence

Continuous integration is where DevOps and clause 5.6 integration testing and clause 5.7 system testing meet directly. Every merge to the integration branch triggers the pipeline. The pipeline builds the software, runs the test suite, and produces a result. The result is not a green dot on a dashboard — it is a structured record containing the revision, the dependencies, the tests that ran, the tests that passed, the tests that were skipped, the coverage of the requirements, and the logs of any failures.

This record is the verification evidence the technical file references. It is not summarised into a separate Word document. It is the artefact itself, stored in a retention system, indexed by version and date, and linked from the requirements traceability matrix. When a Notified Body auditor asks "where is the evidence that requirement REQ-037 is verified for version 2.4.1," the manufacturer points at the CI record for version 2.4.1 and shows the test IDs that exercise REQ-037 and their pass status. The question closes in seconds, not in weeks of audit preparation.

Static analysis and security scans under EN IEC 81001-5-1:2022 run on the same trigger and produce the same kind of structured evidence. Code coverage reports provide the clause 5.6.5 integration test adequacy evidence. Dependency vulnerability scans feed the risk file under EN ISO 14971:2019+A11:2021 and the cybersecurity lifecycle. The pipeline becomes the single place where engineering activity and regulatory activity produce a shared output, and the duplication that usually kills startup compliance budgets disappears.

For the integration testing activity in depth, see post 386.

Continuous deployment as a release boundary

Continuous deployment under EN 62304:2006+A1:2015 is legitimate if, and only if, there is a release boundary between the internal pipeline and the versions that reach clinical use. The boundary is where clause 5.8 runs. Everything before the boundary is internal iteration. Everything after the boundary is released medical device software.

The practical pattern is a multi-stage pipeline. Code that passes CI deploys automatically to a development environment. A development build that passes a broader verification suite promotes to staging automatically. A staging build does not automatically reach production — it waits at a release gate. The gate runs the clause 5.8 release activity: the completeness check against the planned scope, the anomaly evaluation against the risk file, the configuration identification, the release authorisation by the named role, the creation of the release record. Only after the gate clears does the build deploy to production.

This pattern lets the team ship fast internally and slowly externally. The internal cadence is measured in minutes or hours. The external cadence is measured in whatever the product, the risk class, and the change-control procedure can absorb — sometimes daily, sometimes weekly, sometimes less. The two cadences are deliberately different, and the release boundary is the mechanical reason they do not collide.

For the release process and its interaction with clause 5.8, see post 387. For the software maintenance process that governs released versions, see post 388.

Pipeline artefacts as regulatory records

One of the mental shifts DevOps for medical software demands is that pipeline artefacts are the regulatory records, not a source for the regulatory records. The build manifest is the configuration identification under clause 8. The test results are the verification records under clauses 5.6 and 5.7. The signed binary is the controlled output under clause 5.8. The deployment record is the distribution record. The SBOM is the software items list. The dependency scan is the risk input.

Treating these as the records has three consequences. First, the records are produced automatically and cannot drift from the code they describe — the manifest and the code always match because the manifest was generated from the code. Second, the retention policy is a pipeline configuration, not a filing discipline — the pipeline writes to an immutable store and the retention is a property of the store. Third, the Notified Body auditor does not need a tour of a SharePoint folder; the auditor needs read access to the pipeline's artefact store and an index that maps release versions to artefact sets.

The index matters. Without an index that says "release 2.4.1 is built from commit abc123, with dependencies in manifest xyz, verified by test run 789, signed with key K, deployed with record D, risk file version R, requirements matrix M, and release authorisation A," the artefacts are a pile of files. With the index, they are a technical file. The index is itself a pipeline output, generated at the release gate and stored with the release record.

The quality gate pattern

The quality gate is the single most useful DevOps pattern for medical software compliance. A quality gate is a pipeline stage that refuses to advance the build unless specific evidence is present and passes defined thresholds. The gate is a machine-enforced rule, not a human checklist.

A minimum set of gates for a Class B or Class C device looks like this. Gate one: build reproduces, dependencies resolve, SBOM generated. Gate two: unit test coverage above the threshold for the safety class, zero failing unit tests. Gate three: integration tests pass, requirements-to-tests traceability matrix reaches the defined coverage of the requirements in scope. Gate four: static analysis reports no findings above the defined severity, security scan reports no vulnerabilities above the defined severity. Gate five: system tests pass against the full requirements set for the release scope. Gate six: the release gate — clause 5.8 activities complete, risk file current, named role authorisation present.

Each gate corresponds to specific EN 62304:2006+A1:2015 clauses. The gate configuration is part of the software development plan. The gate thresholds are part of the verification plan. When a gate fails, the pipeline stops and the team fixes the cause — not by lowering the threshold, not by skipping the gate, but by addressing the underlying issue. A gate that is routinely bypassed is a gate that does not exist, and a pipeline that has gates in principle but bypasses them in practice fails audit the same way a manual process that is ignored fails audit.

The threshold calibration scales with the software safety class. Class A software has lighter gates than Class B, which has lighter gates than Class C. The standard does not prescribe the numbers — the manufacturer defines them and defends them. The defence is based on the risk class, the device's intended purpose, and the state of the art.

What breaks MDR in pure continuous deployment

Pure continuous deployment — every green build ships to production, no gate, no boundary, no authorisation — is incompatible with MDR Annex I Section 17 and EN 62304:2006+A1:2015. The incompatibility is not about speed. It is about the absence of the specific controls the standard and the Regulation require.

There is no release authorisation, so there is no named role accountable for the released version. MDR Article 10 requires the manufacturer to operate a QMS and assign responsibility. An anonymous automated deploy satisfies neither obligation. There is no documented impact analysis, so there is no evidence that the change was evaluated against the risk file before it reached users. EN ISO 14971:2019+A11:2021 requires continuous risk management, not retroactive risk management. There is no traceability closure, so the requirements-to-tests-to-code chain is open at the moment of deployment. Clause 8 configuration management records do not exist as controlled outputs — only as the pipeline's operational state. And the definition of "release" under clause 5.8 is not satisfied at all, because clause 5.8 expects a controlled activity with documented criteria.

The fix is not to abandon continuous deployment. The fix is to insert a release boundary, a quality gate at that boundary, and the clause 5.8 activities at the gate — turning "every green build ships" into "every green build is ready for the gate, and the gate ships the ones that pass." The cadence changes less than teams fear. The compliance posture changes entirely.

Common mistakes teams make with DevOps for medical software

  • Treating the pipeline as infrastructure rather than as a QMS process. The pipeline is the lifecycle execution engine and its configuration is a controlled document. Changing a pipeline stage without a change record is changing the lifecycle without a change record.
  • Running parallel regulatory documentation beside the pipeline. The pipeline output is the documentation. Any parallel track drifts and becomes the source of audit findings.
  • Quality gates configured for green builds rather than for defensible verification. A gate that passes because the thresholds were set to whatever the current code achieves is not a gate.
  • Deploying to production from development environments to "move fast." There is exactly one path to production, and it goes through the release gate.
  • SBOMs generated but never consulted. An unread SBOM is not a control — it is a file. The vulnerability management process consumes the SBOM.
  • No retention policy on pipeline artefacts. The artefacts are the records. Losing them is losing the technical file.
  • Pipeline changes made by whoever is on call, without review. The pipeline is reviewed like the code it builds, and the review is recorded.
  • Treating "passed CI" as equivalent to "released." CI is verification. Release is authorisation. They are not the same activity.

The Subtract to Ship angle

DevOps for medical software is a Subtract to Ship exercise in its purest form. The bloated version runs a CI/CD pipeline for engineering purposes, runs a parallel document-driven regulatory process for compliance purposes, and keeps them in sync with heroic effort until the sync fails and an audit finding lands. The lean version runs one pipeline that produces both outputs simultaneously, with the evidence capture wired into the same tooling the engineers already use.

The subtraction moves in this category are these. Collapse the regulatory evidence pathway into the pipeline — one source of truth, not two. Make pipeline artefacts the records, not the inputs to records. Put quality gates at the pipeline stages where the standard expects verification and release. Put the release boundary at one place, named in the software development plan, enforced in the pipeline configuration, auditable from the release record backwards. Cut every parallel documentation track that mirrors something the pipeline already produces. Cut every manual sign-off that duplicates an automated gate. Cut every Word document whose content is generated elsewhere.

What survives is the lifecycle the standard actually requires, running at the cadence DevOps actually delivers, with evidence an auditor can verify in an afternoon. Trace every pipeline stage back to a specific clause of EN 62304:2006+A1:2015 and, through the standard, to MDR Annex I Section 17 — and cut any stage that does not trace. For the broader framework, see post 065.

Reality Check — Can your DevOps pipeline survive an MDR audit?

  1. Is your CI/CD pipeline itself documented as part of the software development plan, with each stage mapped to a specific clause of EN 62304:2006+A1:2015?
  2. Are pipeline artefacts (build manifests, SBOMs, test results, signed binaries, deployment records) retained as the regulatory records, or are they re-captured into a parallel document system?
  3. Do you have a defined release boundary between internal continuous deployment and production clinical use, enforced in the pipeline configuration?
  4. Does the release gate run the clause 5.8 activities — completeness, anomaly evaluation, configuration identification, authorisation by a named role, release record creation?
  5. Are your quality gate thresholds calibrated to the software safety class and defended against the state of the art, or set to pass the current codebase?
  6. For any released version in production right now, can you trace in under ten minutes from the running build back to commit, dependencies, test results, risk file state, and release authorisation?
  7. Is the pipeline configuration itself under change control, with pipeline changes reviewed and recorded?
  8. When a quality gate fails, does the pipeline stop and the team fix the cause, or is there a bypass path that has been used in the last quarter?

Any question you cannot answer with a clear yes is a gap the next audit will find. Closing the gap is a pipeline configuration and discipline exercise, not a methodology change.

Frequently Asked Questions

Is DevOps compatible with EN 62304:2006+A1:2015? Yes. The standard is process-neutral and does not prescribe how lifecycle activities are executed. A CI/CD pipeline that captures the required evidence at each stage — integration testing, system testing, configuration management, release control — satisfies the standard and often does so with higher evidence quality than a manual lifecycle. The compatibility depends entirely on whether the pipeline encodes the activities and produces the records the standard expects.

Can a medical device manufacturer deploy continuously to production? Continuous deployment to internal and staging environments is compatible with the standard. Continuous deployment directly to patient-facing production, without a release gate running clause 5.8, is not. The release gate can be fast — minutes, not months — but it must exist, it must produce a release record, and it must be authorised by a named role under MDR Article 10.

What pipeline artefacts count as regulatory records? Build manifests, software bills of materials, dependency manifests, unit and integration and system test logs, static analysis reports, security scan reports, code coverage reports, signed binaries, deployment manifests, and release records all count when they are generated by the pipeline, retained under a defined policy, and referenced from the technical file. The pipeline is the generator; the artefact store is the retention system; the technical file is the index.

How are quality gate thresholds set for a medical device pipeline? Thresholds are set by the manufacturer, documented in the verification plan, and defended against the software safety class and the state of the art. Class A software has lower thresholds than Class C. The standard does not prescribe numbers. It requires that the thresholds exist, that they are justified, that they are enforced, and that the evidence of enforcement is retained. A threshold set to whatever the current codebase already achieves is not a threshold.

Does the CI/CD pipeline configuration itself need change control? Yes. The pipeline executes the lifecycle, so the pipeline configuration is a controlled document under the QMS. Changes to pipeline stages, gate thresholds, deployment targets, or retention policies are changes to the lifecycle and must be reviewed and recorded. EN ISO 13485:2016+A11:2021 clause 4.2 document control applies.

How does DevOps affect post-market surveillance? Positively, when the pipeline is integrated with production telemetry. The same pipeline that deploys the software can collect operational signals, feed them into the PMS system under MDR Article 83, and close the loop with the risk file. DevOps and SRE practices generate exactly the kind of continuous production visibility that modern PMS expects. See post 395 for the SaaS PMS angle.

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 IT security requirements), Article 10 (manufacturer obligations including the QMS). 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). Harmonised standard referenced for the software lifecycle under MDR Annex I Section 17.2.
  3. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Harmonised standard referenced for the QMS under MDR Article 10(9).
  4. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices. Harmonised standard referenced for risk management under MDR Annex I.

This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on operating a DevOps CI/CD pipeline as the evidence engine for EN 62304:2006+A1:2015 and MDR Annex I Section 17 compliance. 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 ISO 13485:2016+A11:2021 are harmonised tools that provide presumption of conformity with specific MDR obligations, not independent authorities. For startup-specific regulatory support on DevOps pipeline design, quality gate calibration, and release boundary implementation, Zechmeister Strategic Solutions is where this work is done in practice.