CI/CD for medical device software

What does a delivery pipeline owe when the build is a medical device?

Two things a general-purpose pipeline never produces: a record per system test run with named contents, and a release step that a human decides. IEC 62304 Edition 1.1 sets both. The record contents are at 5.7.5, whose stated purpose is to support the repeatability of tests, and Amendment 1 marked that subclause [Class A, B, C]. The release conditions are at 5.8.1, all software verification activities completed and the results evaluated before release, and at 5.8.2, known residual anomalies documented. Amendment 1 moved 5.8.2 from classes B and C to A, B and C, so a class A product owes the anomaly list as well.

The third thing is the one teams find last. 5.8.7, Archive software, also moved to [Class A, B, C]. An archive is a different obligation from a build cache, and it survives the retention policy of whatever system ran the job.

Which subclauses bind at which safety class, and how the classification is assigned in the first place, are set out on the IEC 62304 testing requirements page. This page is about the shape a pipeline has to take to satisfy them on every run.

Which artefacts does every run have to leave behind?

The seven items 5.7.5 names. A pipeline can produce all seven, and a default pipeline produces several of them incidentally and then lets them expire with the job output. The mapping below is the useful form, because it shows which items need a deliberate step.

The seven test record items of IEC 62304 subclause 5.7.5 mapped to CI/CD pipeline outputs, with the responsible person the only item no pipeline supplies.

Item required at 5.7.5	Where a pipeline gets it
Reference to test case procedures with required actions and expected results	The suite definition at the commit that ran, referenced by identifier and not by branch name
Test result as pass or fail, with a list of anomalies	The job result, plus the problem reports raised from the failures in it
The version of the software tested	The build identifier, resolved to something that still names a build a year later
The relevant hardware and software test configurations	The environment definition, captured at run time and not read back from the current one
The relevant test tools	The resolved tool versions of that run, including transitive ones
The date tested	The job timestamp
The identity of the person responsible for executing the test and recording the results	Nowhere. This one is assigned, and a scheduled trigger does not assign it

The last row is where a continuous pipeline differs from a manual test campaign, and it does not close with a service account name. What automation is allowed to be signed off by, and what it can never execute on a person's behalf, is worked through at test automation in a validated environment.

Is a build that never reaches a customer a release?

Sometimes, and the definition is narrower than deployment. Amendment 1 added definition 3.37 RELEASE: "particular VERSION of a CONFIGURATION ITEM that is made available for a specific purpose". The trigger is availability for a stated purpose. A candidate handed to a clinical evaluation team, to a regulatory consultant, or to a customer running a pilot is inside that wording, and the customer plays no part in it.

Three consequences for branch strategy follow.

• A pipeline with one path to production and no notion of a candidate has no place to attach the 5.8 conditions, because nothing in it is identifiable as the version that was made available.
• A pre-production build given to anyone for a purpose reopens the same verification-complete question at 5.8.1 as the shipped one, and the answer is recorded either way.
• The device release is outside all of this. Clause 1.2, Field of application, ends with a sentence that has been in the standard since the 2006 first edition: "This standard does not cover validation and final release of the MEDICAL DEVICE, even when the MEDICAL DEVICE consists entirely of software." The pipeline's green result and the act of placing a device on the market are governed by two different documents.

Continuous deployment is compatible with the first two and not with the third by default. A team that automates the software release step still has to name where the device release decision is taken, and by whom.

Which decisions can no job take on its own?

The ones the standard assigns to the manufacturer and the ones whose criteria were never written into a threshold. A pipeline is good at applying a rule and has nothing to say about whether the rule was the right one.

Item 4 is the one most often encoded as a quality gate and most often encoded wrong. The criteria are the manufacturer's own, written in the risk management plan, and a numeric gate copied from a template asserts a level of acceptable risk that nobody in your organisation set. What the risk management file holds and how testing feeds it is covered on the ISO 14971 page.

Item 3 is the decision that a fast pipeline is under the most pressure to skip, because re-running everything is easier to automate than justifying a subset. The method for selecting the subset and defending the exclusions afterwards belongs to regression testing for regulated software, and nothing here replaces it.

What does the pipeline itself have to answer for?

Its own qualification, on a different track from the device build it produces. FDA's computer software assurance guidance, issued 3 February 2026, sorts software by intended use, and places development tools that test or monitor software systems or automate testing activities, including firmware embedded in production equipment, in the bucket used to support production or the quality management system. Its scope stops short of the output, in its own words: the guidance "does not provide recommendations for the design and development verification or validation requirements for device software functions".

One pipeline therefore sits on both sides of a line the guidance draws. The runner, the test harness and the reporting job can fall under the assurance framework; the device software they build does not. What that framework asks for, and the process-risk test it turns on, is set out on the FDA computer software assurance page.

For a device with an approved premarket approval or humanitarian device exemption, changing production or quality management system software carries a reporting consequence with a stated split. The guidance says a change that may result in a quality problem that foreseeably compromises safety should generally go in a 30-day notice, and one that would not may be appropriate for the annual report. Its worked contrast is a manufacturing execution system managing workflow and alerts against one that automatically controls and adjusts established critical production parameters such as temperature, pressure and process time. Upgrading the tooling that releases a device is a change with a paperwork consequence, and the release schedule is the wrong place to discover which of the two it was.

Where do the release record and the pipeline log stop being the same thing?

At retention, at retrievability, and at what the record is allowed to omit. FDA recommends the digital form: "As a least-burdensome approach, FDA recommends incorporating the use of digital records, such as system logs, audit trails, and other data generated and maintained by the software, as opposed to paper documentation, screenshots, or duplicating results already digitally retained by the software". The guidance attaches conditions to that in the same breath, asking manufacturers to consider accuracy, reliability, integrity, availability and authenticity of the record. A log that no longer exists fails the availability condition, and a log any maintainer can rewrite fails the integrity one.

The general validation objectives are worded the same way. 21 CFR 11.10(a) requires "validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records", and the last of those four is the one a log store rarely provides. Which of a pipeline's outputs fall under Part 11 at all is decided per output, and the test is on the 21 CFR Part 11 page.

Under IEC 62304 the record has homes with names. The configuration management process is clause 8, with 8.1 Configuration identification, 8.2 Change control and 8.3 Configuration status accounting. The problem resolution process is clause 9, and 9.8 is titled Test documentation contents. A pipeline that files its outputs into none of these has produced evidence with no index, and assembling the index during an audit is the work described at validation documentation.

What changes on the first release after the device is on the market?

The pipeline stops feeding only the design file and starts feeding the post-market process. ISO 14971:2019 carries clause 10, Production and post-production activities, with 10.1 General, 10.2 Information collection, 10.3 Information review and 10.4 Actions. ISO/TR 24971:2020 reads the obligation back at 4.4.8: ISO 14971:2019 "requires the manufacturer to establish a system to actively collect and review information about the medical device in the production and post-production phases and to review this information for relevance to safety". Release telemetry, crash reports and support tickets are inputs to that system, and a pipeline that discards them at the end of a deployment window has removed an input from a process that has to run.

IEC 62304 names the receiving side in clause 6, Software maintenance process, with 6.1 Establish software maintenance plan, 6.2 Problem and modification analysis and 6.3 Modification implementation. Clause 7.4 is titled RISK MANAGEMENT of software changes. Each of the three is a place a post-release finding lands, and each expects a record with an owner.

Environments seeded for release rehearsals are the other thing that outlives a single release, because a promotion path gets copied more often than it gets reviewed. We do not need production PHI to test. Environments run on synthetic and de-identified data. The two questions on that subject this site still records as unanswered are published alongside the answered ones at how we work with protected health information.

Which pipeline habits cost you the release argument?

• The test record lives as job output, and 5.8.7 Archive software is answered by a build cache that expires on the runner's schedule.
• The record names a service account where 5.7.5 asks for the person responsible for executing the test and recording the results.
• Tool versions are resolved at install time, so the 5.7.5 test tool entry cannot be reconstructed for a run from last quarter.
• The quality gate encodes a risk threshold that appears in no risk management plan, although ISO 14971:2019 leaves the acceptability criteria to the manufacturer.
• Candidate builds are handed to evaluators without being identified as versions, so definition 3.37 has nothing to attach to.
• Deployment to production is treated as the device release, and the exclusion in clause 1.2 is never read.
• The assurance framework is applied to the device software because it was applied to the build tooling, and the guidance's own scope sentence says it does not reach device software functions.
• Post-release telemetry expires before it reaches the information collection activity at 10.2 of ISO 14971:2019.

Clause numbers, titles, class markers and quoted wording from IEC 62304 Edition 1.1 (2015-06 consolidated version) and ISO 14971:2019 on this page were read on 2 September 2026 against the IEC and ISO catalogue entries and first-party preview texts, and against ISO/TR 24971:2020. The FDA material is Computer Software Assurance for Production and Quality Management System Software, issued 3 February 2026 and expressly nonbinding, and 21 CFR Part 11 as current in the eCFR for the 31 August 2026 issue date.