IEC 62304Medical device software — Software life cycle processes

IEC 62304 is the international standard that defines the lifecycle processes for medical device software — the planning, requirements, architectural design, detailed design, implementation, integration, system testing, release, maintenance, risk management, configuration management and problem-resolution activities that produce safe, effective and inspectable software in a medical device. It applies to software that is itself a medical device (Software as a Medical Device, SaMD) and to software that is a component or accessory of a medical device. It does not apply to non-medical software used in production (that is CSV / GAMP 5 territory).

The standard was first issued in 2006 and amended in 2015 (Amendment 1, IEC 62304:2006/A1:2015) to clarify Software Of Unknown Provenance (SOUP), legacy software handling, and the application of the safety classification across software items. It is recognised by the FDA as a consensus standard; harmonised under EU MDR/IVDR via Annex I §17; embedded in MDSAP audit scripts; and referenced as the substantive lifecycle by the IMDRF SaMD framework. A device software submission that does not reference 62304 (or a justified equivalent process) is uncommon and generally faces additional scrutiny.

62304 applies to software when that software is itself a medical device under the applicable regulation, or when it is a component or accessory of a medical device. The qualification question — is this software a medical device at all — is answered by the regulatory framework, not by 62304 itself. MDCG 2019-11 is the EU reference; FDA's 'Policy for Device Software Functions and Mobile Medical Applications' (2022) and 'Clinical Decision Support Software' (2022) are the US references; IMDRF/SaMD/N12 frames the cross-regulator perspective.

Typical in-scope examples: embedded firmware in an infusion pump; the control software of a surgical robot; the algorithm in a continuous glucose monitor; a mobile app that analyses ECG strips and offers an arrhythmia diagnosis (SaMD); a desktop application that reads patient imaging and outputs a treatment plan; the software inside a haematology analyser. Typical out-of-scope examples: the MES that operates the production line for the device (that is CSV); the ERP that handles purchasing of components (CSV); the spreadsheet that records environmental monitoring (CSV / Annex 11 / Part 11). The boundary matters — applying 62304 to non-device software wastes effort; failing to apply it to device software is a major non-conformity.

§4.3 of 62304 requires the manufacturer to assign a software safety class to the software system based on the severity of injury that could result from a hazard to which the software contributes — assuming no risk-control measures external to the software are in place (the pre-mitigation severity). The three classes:

The classification is per software system, but Amendment 1 (2015) allows decomposition: a system may be a single class, or different software items within the system can carry different classes if the architecture demonstrates segregation of safety-critical items from non-safety-critical items. Segregation is more than a folder boundary — it requires architectural evidence that a failure of the lower-class item cannot cause a hazard from the higher-class item. The classification rationale and the segregation evidence are inspectable; 'we picked Class B because everyone picks Class B' is not a rationale.

62304 organises the work into five interlocking processes:

1. Software development process (§5) — planning, requirements, architectural design, detailed design, implementation, integration & integration testing, system testing, release. Scales by class.
2. Software maintenance process (§6) — maintenance plan, problem and modification analysis, modification implementation. Applies whenever a release is updated post-launch.
3. Software risk management process (§7) — analysis of contributing software to hazardous situations, risk control measures in software, verification of risk control measures, risk management of software changes. Runs in parallel with ISO 14971.
4. Software configuration management process (§8) — configuration identification, change control, configuration status accounting. Applies across all classes.
5. Software problem resolution process (§9) — preparing problem reports, investigating, advising involved parties, using the change-control process, maintaining records, analysing problems for trends, verifying solutions.

§5.1 (planning) is the keystone — every other phase's evidence is judged against the plan. The plan must reference: the safety classification per software system / item; the integration with ISO 14971; the SOUP handling approach; the configuration-management approach; the problem-resolution approach; the regression-test strategy; the standards and methods used; the deliverables list; the verification approach for each phase; the integration with the design-control process. Plans copied from a template with no project-specific content fail audit.

§3.29 defines SOUP as 'software item that is already developed and generally available and that has not been developed for the purpose of being incorporated into the medical device (also known as off-the-shelf software) or software item previously developed for which adequate records of the development processes are not available.' Translation: any third-party library, OS component, communication stack, database engine, machine-learning framework, container base image, package manager dependency, npm/pip/Maven package or vendor SDK that ends up in the device's runtime is SOUP.

§5.3.3 (architecture phase) requires that the architecture identifies the SOUP items. §5.3.4 requires functional and performance requirements for each SOUP item. §5.3.5 requires the hardware and software requirements necessary to support the SOUP. §7.1.3 requires evaluation of published anomalies for each SOUP item and whether any of them could affect safety. §8 requires SOUP versions to be under configuration management. A practical SOUP register captures, per item: name, version, source, license, functional and performance requirements consumed, integration evidence, known-anomaly review (date, source, dispositions), and the safety-evaluation conclusion.

§7 does not replace ISO 14971; it specialises it for software. The expected handshake: ISO 14971 §4 risk-management process identifies the device's hazards and hazardous situations; for those involving software, 62304 §7.1 (analysis of software contributing to hazardous situations) traces the software items that could contribute; §7.2 defines risk-control measures implemented in software; §7.3 verifies the implementation; §7.4 manages risk for software changes (re-analysis when a change could affect a risk-control measure).

The evidence chain that inspectors trace: hazard in the risk file → contributing software item identified in §7.1 → risk control in the software identified in §7.2 → architectural / detailed design output that implements the control → verification activity that confirms the implementation → integration / system test that exercises the control → release approval that includes the control's verification status → post-release problem-report / change-control integration. A break anywhere in the chain is a finding.

§8 (configuration management) is required for all classes. It covers: configuration identification (every released item carries a unique version), change control (changes go through the documented process), and configuration status accounting (auditable history of what was at what version when). Modern source-control + tagging + immutable artefact storage covers most of the technical requirements, but the procedure that wraps the tooling — when a change is approved, who approves, how regression is judged sufficient, how the release artefact is sealed — is the inspectable part.

§9 (problem resolution) covers post-discovery handling: preparing problem reports (anomalies), investigating to determine if the anomaly is a problem (i.e. has safety / regulatory / functional implications), using the change-control process to implement corrections, maintaining records of problems and resolutions, analysing problems for trends, and verifying that solutions actually resolve the problem and do not introduce regressions. The problem-resolution process must integrate with the §820.198 / ISO 13485 §8.2.2 complaint process and the §820.100 / §8.5.2 CAPA process — the same anomaly may exist in all three databases, and the cross-reference must be inspectable.

62304 is process-prescriptive but not phase-rigid — it does not mandate waterfall. AAMI TIR45:2012(R)2018 (a recognised consensus standard in the US) maps agile practices to 62304 expectations: incremental development satisfies §5 if each increment carries the documented requirements / architecture / verification expected for the safety class; continuous integration satisfies §8 if the build chain produces traceable, identified artefacts; user stories satisfy §5.2 requirements analysis if they are written with acceptance criteria and traceability; sprint reviews and demos contribute to but do not replace §5.7 system testing; release reviews still apply at the release boundary. Common pitfalls: requirements that exist only as JIRA tickets without a frozen SRS at release; risk-control measures introduced mid-sprint without a §7 re-analysis; regression strategy that does not scale with the change set.

62304 itself does not deeply specify cybersecurity, but the 2023 FDA cybersecurity guidance and MDCG 2019-16 Rev.1 expect cybersecurity activities to be woven into the 62304 lifecycle. The expectations: a secure-product-development framework (SPDF) that includes threat modelling at the requirements/architecture phase; cybersecurity risk management complementing ISO 14971 (often per AAMI TIR57); secure design and implementation practices; verification of security controls; cybersecurity in the SBOM (typically SPDX or CycloneDX format) referencing each SOUP item and its known vulnerabilities (CVEs); a vulnerability management programme that integrates with 62304 §9 problem resolution and feeds into post-market security updates.

From an audit perspective, this means the 62304 evidence package now routinely includes: threat model document; cybersecurity requirements appendix to the SRS; SBOM in machine-readable form; vulnerability monitoring procedure with cadence; security-control verification record; security release-note appendix listing residual security risks. A submission missing these is now flagged as deficient by the FDA regardless of the rest of the 62304 package.

§5.8 requires that the release evaluate residual anomalies and that each unresolved anomaly be assessed for whether it could contribute to a hazardous situation. Unresolved anomalies with safety implications either trigger correction before release or, where the residual risk is acceptable and justified, are documented in the release record (and, where appropriate, disclosed to users via release notes / IFU). The single most-cited release finding: an anomaly that an audit later judges to have safety implications is found in the problem-resolution database, but is not referenced in the release approval record. The reverse is also a finding: the release approval claims 'no known safety-related anomalies' but the anomaly log shows open items that were not evaluated against §5.8.

§6 requires a software maintenance plan and a problem-and-modification analysis process. The maintenance plan must address: how feedback is gathered (complaints, service, support, security advisories), how problems are evaluated for whether they are problems, how modifications are categorised (corrective / adaptive / perfective / preventive), and how the modification re-enters the §5 development process at the appropriate phase. A common operational pattern: corrective modifications re-enter at the change-impact-analysis gate (which feeds back into §7 risk re-analysis if the change touches a safety item), and perfective / adaptive modifications follow the full development cycle.

• Software safety classification rationale missing or generic ('we chose Class B' with no reasoning).
• Segregation between safety classes claimed in the architecture but not architecturally enforceable.
• SOUP register missing, incomplete, or with stale anomaly reviews.
• SBOM not produced or not in machine-readable form.
• Requirements (SRS) not frozen at release, with traceability gaps to verification.
• Architectural design absent for Class B/C systems.
• Detailed design and unit testing absent for Class C software items.
• Integration testing performed but not planned (§5.6.1 missing) — protocols written after results.
• System tests not traceable to requirements; missing-coverage rows in the trace matrix.
• Risk-control measures in software not verified individually.
• Software change to a risk-control measure not re-analysed under §7.4.
• Configuration management procedure exists but release artefacts not tagged with traceable identifiers.
• Anomaly log not analysed for trends (§9.7).
• Anomaly disposition at release inconsistent with §5.8 requirements (missing residual-risk evaluation per item).
• Cybersecurity activities present but not integrated into the SDF — threat model not referenced from requirements or risk file.
• Agile teams operating without an explicit AAMI TIR45 mapping in the plan — auditor cannot find the §5 deliverables in the JIRA / Git / Confluence sprawl.

• Requirements traceability completeness (% of requirements with verification + system test linkage).
• Safety-class segregation evidence completeness for mixed-class systems.
• SOUP register currency (max age of anomaly review per item; target <90 days).
• Open anomalies at release (count, by severity, with disposition).
• Defect escape rate (anomalies found post-release / total anomalies in period).
• Mean time from anomaly receipt to investigation closure.
• Risk-control measure verification rate (% verified with evidence at release).
• Change-impact-analysis coverage (% of changes with documented §7.4 re-analysis where applicable).
• Cybersecurity activity coverage against SPDF (threat model coverage, SBOM completeness, monitored CVE feeds).
• Release approval cycle time and rework rate.

V5 Ultimate hosts a Software Development File (SDF) workspace inside the discrete-industry QMS that mirrors the 62304 §5 deliverables as a controlled, signed document set. Each software system is recorded with its safety classification, the rationale, and the architectural segregation evidence where applicable. The SOUP register is first-class: each entry carries name, version, source, license, functional + performance requirements consumed, integration evidence, the published-anomaly review record with date, and the safety-evaluation conclusion.

Requirements, architecture, detailed design, implementation evidence, integration tests, system tests, anomalies and release approvals are version-controlled with two-person e-sig at release. The traceability matrix is live: every requirement row shows its verification activity, system test, risk-control mapping (back to the ISO 14971 hazard) and release status. A gap in the matrix is visible immediately, not at audit.

Anomalies are tracked in a single problem-resolution log that cross-links to the complaint module (§820.198 / §8.2.2) and the CAPA module (§820.100 / §8.5.2). Each anomaly carries an evaluation against §5.8 release criteria; release approvals cannot be signed while open anomalies lack a residual-risk evaluation. Changes raise a change-impact-analysis task that auto-routes to ISO 14971 §10 review if the change touches a software item carrying a verified risk-control measure.

Cybersecurity activity is woven into the same SDF: threat model, security requirements appendix, SBOM in SPDX/CycloneDX, monitored CVE feeds, vulnerability disposition log and security release notes. The SDF index is referenced from the DHF — the design-control evidence package that an inspector opens first — so the 62304 chain is part of, not separate from, the broader design-control story.