IEC 62304 for software teams: safety classes, required deliverables and how to fit them into Git and CI

Direct answer

IEC 62304 is the life cycle standard for medical device software, including software that is a device on its own (SaMD). Each software system gets Class A, B or C based on the harm it could contribute to after external risk controls, and the class decides which activities and documents are mandatory. Configuration management, problem resolution, maintenance and system testing apply to every class; architecture, integration testing and most software risk analysis start at Class B; detailed unit design is Class C only. No waterfall is required: reviewed pull requests, CI test reports and tagged releases can be the records, as long as they are planned, controlled and traceable.

Which version applies in 2026

The current text is IEC 62304:2006+AMD1:2015, consolidated edition 1.1. A second edition has been in drafting for years. QuickBird Medical reported in September 2026 that the IEC now forecasts publication on 26 October 2028, after a large volume of comments on the 2025 committee draft. Drafts so far propose replacing the A/B/C classes with two process rigour levels and widening the scope to health software in general. Treat that as a direction: build to edition 1.1 today and keep process documents modular enough to remap later.

Where IEC 62304 sits next to other standards and regulations

IEC 62304 covers the software life cycle and nothing else. It assumes the surrounding system exists:

Two regulatory details matter for planning. In the EU, EN 62304 was harmonised under the old Medical Devices Directive, but it does not appear in the MDR harmonised standards lists published through mid-2026, so it gives no formal presumption of conformity under the MDR. Notified bodies still treat it as the state of the art, so in practice nobody skips it. Check the latest summary list before you write "harmonised" in a technical file. If you still need to decide whether your software is a device at all, start with the EU MDR guide for software teams and MDCG 2019-11 rev.1.

In the US, the June 2023 FDA guidance Content of Premarket Submissions for Device Software Functions replaced the old "level of concern" with a Basic or Enhanced documentation level. For the "software development, configuration management and maintenance practices" element, it accepts a declaration of conformity to the FDA-recognized version of IEC 62304. Since 2 February 2026, the Quality Management System Regulation incorporates ISO 13485:2016 by reference, so a single ISO 13485 QMS with IEC 62304 processes inside it can serve both markets.

Software safety classification with risk controls

Amendment 1 changed how classification works. The 2015 text assigns a class to each software system based on the hazardous situations it can contribute to, after considering risk control measures external to the software:

• Class A: the software cannot contribute to a hazardous situation, or the hazardous situation does not result in unacceptable risk once external risk controls are considered.
• Class B: unacceptable risk remains after external risk controls, and the possible harm is non-serious injury.
• Class C: unacceptable risk remains after external risk controls, and the possible harm is death or serious injury.

"External" means outside the software system being classified: a hardware interlock, an independent software system, a clinical procedure. A check inside the same codebase does not lower the class of that codebase. Three rules catch teams out:

1. Until a class is assigned, Class C requirements apply (clause 4.3 g).
2. Software items inherit the class of the system they come from. A lower class for one item needs a documented rationale explaining how it is segregated (4.3 d). For Class C, clause 5.3.5 requires you to identify that segregation and show it is effective.
3. The class goes into the risk management file (4.3 c). It is a risk decision, owned jointly with whoever runs the ISO 14971 process.

Example: a SaMD that suggests an insulin bolus. If a wrong value could reach the patient unchecked, it is Class C. If the clinical workflow requires a clinician to verify inputs and result against a displayed calculation before administration, and the risk file shows that control brings the risk to acceptable, the risk team may justify Class B. That argument has to survive usability evaluation under IEC 62366-1; a confirmation dialog users click through is not an effective control.

One trap when you file in both markets: the FDA documentation level is assessed before risk control measures are applied. A system you justified as Class B under IEC 62304 can still need Enhanced documentation for the FDA.

Required deliverables by class

This summary follows the class markers in the normative text of IEC 62304:2006+A1:2015 (Annex A, Table A.1 gives the same picture).

Class A is lighter, not empty. Since Amendment 1, Class A software needs requirements, system testing against them, release records, configuration management and problem resolution.

SOUP: what the standard asks for

SOUP (software of unknown provenance) covers any already-developed software not built for your device: open-source libraries, the language runtime, the OS, a commercial SDK, or older in-house code without development records. The obligations stack up by class:

• All classes (8.1.2): for each SOUP configuration item, document the title, the manufacturer and a unique designator such as a version or patch number. Standard libraries count.
• Class B and C (5.3.3, 5.3.4): specify the functional and performance requirements the SOUP item must meet for your intended use, and the hardware and software it needs to run.
• Class B and C (7.1.3): if a SOUP failure could contribute to a hazardous situation, evaluate at least the supplier's published anomaly list for the exact version you ship.

A lockfile identifies versions but does not record why a library is acceptable or which known bugs you reviewed. Generate an SBOM (CycloneDX or SPDX) on every release build, and keep a short SOUP register beside it with requirements, risk relevance and the date of the last anomaly review. For US cyber devices, section 524B of the FD&C Act already requires an SBOM in the premarket submission (see the FDA cybersecurity guidance), so the same artefact serves both purposes.

Mapping IEC 62304 to Git and CI

The standard asks for evidence that planned activities happened, by someone accountable, on a known configuration. A modern toolchain already produces most of that. Describe the mapping in the software development plan (5.1.1); otherwise an auditor sees tooling without a process.

A commit and PR convention that makes the traceability matrix generatable:

feat(dosing): clamp bolus suggestion to configured max

Implements: SRS-042
Risk-control: RCM-007 (HAZ-012 overdose suggestion)
Verified-by: test_bolus_clamped_to_max, SYS-TC-118
Ticket: CR-311

A minimal pipeline step that keeps the evidence with the build:

release-evidence:
  runs-on: ubuntu-24.04
  steps:
    - uses: actions/checkout@v4
    - run: npm ci
    - run: npm test -- --ci --reporters=default --reporters=jest-junit
    - run: npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json
    - run: node scripts/trace-matrix.mjs --requirements docs/srs.yaml --junit junit.xml --out trace-matrix.csv
    - uses: actions/upload-artifact@v4
      with:
        name: release-evidence-${{ github.ref_name }}
        path: |
          junit.xml
          sbom.cdx.json
          trace-matrix.csv

The trace-matrix.mjs script is your own: it reads requirement IDs from the SRS, scans test names and PR trailers, and fails the build when a requirement or risk control measure has no passing test. That failing check is worth more in an audit than a hand-maintained spreadsheet. CI artefact retention is usually short, so copy release evidence into controlled storage that matches the archive period from 5.8.7.

Two more rules keep this defensible. Tools that produce records (CI, the trace script, the issue tracker) need validation for their intended use under ISO 13485 clause 4.1.6, scaled to risk. And branch protection settings are part of your process, so changes to them go through change control.

Common audit findings

These come up repeatedly in practice, across company sizes:

• Classification without risk links: Class B or A claimed with no reference to hazards, external controls or the risk file entries that justify it.
• SOUP list without versions or anomaly review: "React, PostgreSQL, Python" with no designators, and no evidence anyone read the known-issues list for the shipped version.
• Traceability holes: risk control measures not written as software requirements (5.2.3), or written but never tested.
• Self-approved changes: the author merged their own PR, or an admin bypassed branch protection without a recorded reason.
• Release built on a laptop: no documented build environment, so the shipped binary cannot be reproduced (5.8.5).
• Residual anomalies listed but not evaluated: the open bug export exists, the risk assessment for each item does not (5.8.3).
• A stale plan: the development plan describes a process the team stopped using two years ago (5.1.2).
• No trend analysis on problem reports (9.6), which also weakens post-market surveillance.

Related reading and help

IEC 62304 overlaps with other obligations on the same codebase: AI components bring EU AI Act requirements, hospital deployments pull in NIS2 security duties, and the wider EU compliance landscape shows how these fit together. If you need a development team that builds medical device software with this evidence trail from the first sprint, see HealthTech development.

This article is engineering guidance, not regulatory or legal advice. Confirm classification and conformity strategy with your regulatory lead and notified body.