IEC 62304 Software Lifecycle: What a real software file looks like

IEC 62304 is the process standard for medical device software lifecycle. It does not specify what your software must do — that is the job of your design controls and risk management. It specifies how you must develop, maintain, and control software in order to demonstrate that the device is safe and effective. The 2015 amendment (Amd 1:2015) expanded coverage to Software as a Medical Device (SaMD) and health software, not just software embedded in physical devices.

This guide exists because no publicly available source correctly states the single rule that determines most classification decisions — software probability of failure is treated as 1 — and no source shows the complete picture of SOUP discipline beyond maintaining a component list. What follows covers both, alongside the full development lifecycle, risk management integration, and the seam between IEC 62304 and IEC 81001-5-1 for cyber devices.

Does IEC 62304 apply to your software?

IEC 62304 applies to any software that is part of a medical device or is itself a medical device (SaMD). The 2015 amendment clarified that “health software” — software intended to benefit individual patients by processing health-related data — is within scope even when it does not meet every jurisdiction’s statutory definition of a medical device.

What about in vitro diagnostic (IVD) software?

Software that is part of or constitutes an IVD instrument or assay is in scope. For EU IVD manufacturers, the IVDR (Regulation 2017/746) applies in addition to IEC 62304. IVD software safety classification follows the same IEC 62304 Class A/B/C framework; the severity analysis references clinical consequences of incorrect test results. A diagnostic reporting algorithm whose failure produces a false negative for a serious condition is likely Class C regardless of whether the hardware device is Class I.

What about mobile apps and cloud-connected SaMD?

Mobile medical apps and cloud-connected SaMD are fully within IEC 62304 scope. The standard was written in 2006 for embedded software and updated in 2015 to explicitly cover this category. For cloud SaMD, your software system includes the mobile client, the server backend, and any managed services that process patient data or produce outputs the device relies on. The SOUP list and configuration management requirements apply to cloud dependencies (managed databases, ML inference services, container base images) that update outside your direct control — this is one of the most common gaps in SaMD software files.

The software safety classification decision

The software safety class you assign determines which IEC 62304 process requirements are mandatory. Getting this wrong — in either direction — is a major audit finding. Most misclassifications go in the same direction: too low, justified by arguments the standard explicitly prohibits.

What does each class mean?

Classification under IEC 62304 Clause 4.3 is based on the severity of harm that could result from software failure, after applying only risk controls that are external to the software:

Class A: A failure of the software item cannot contribute to a hazardous situation, or it can contribute to a hazardous situation that does not result in unacceptable risk after applying external risk controls.

Class B: A failure of the software item can contribute to a hazardous situation that results in non-serious injury after applying external risk controls.

Class C: A failure of the software item can contribute to a hazardous situation that results in death or serious injury after applying external risk controls.

Why internal software controls cannot lower your class

The standard contains one rule that invalidates most class-reduction arguments, and almost no web resource states it plainly: IEC 62304 explicitly states that only risk control measures external to the software system may be used for classification — software probability of failure is assumed to be 1.

In practice, this means: if your software unit could, upon failure, contribute to serious patient harm — and the only thing preventing that outcome is another piece of your software (range checks, watchdog timers, validation logic) — you cannot use that internal control to lower the class. The standard assumes your software safeguards can also fail. Only hardware interlocks, clinical procedures performed by a trained user, or other controls external to the software system count for classification purposes.

The rationale is sound engineering. An argument of the form “our code has error checking, so a failure won’t be dangerous” proves nothing, because the error-checking code is itself software subject to failure. External controls — a physician who verifies a dosage before acting on a displayed value, a hardware fuse that disconnects power if voltage exceeds a threshold — exist outside the failure domain of the software. Those can reduce the class. Your code cannot reduce your class.

The classification is top-down from your risk analysis

Classification starts with ISO 14971, not with software. Identify the hazardous situations your device can contribute to, determine the severity of harm in each scenario, and map the software items involved. The software safety class follows from that mapping. Start from the worst-case clinical consequence and work backward to the software items. Do not start from the software and argue upward to clinical consequences — that is bottom-up reasoning that auditors and notified bodies will challenge.

What is the practical advice for small teams?

Experienced consultants — including those at Johner Institute — note that class-reduction arguments often cost more than they save. Proving that a software item is genuinely isolated from safety-critical functions requires architectural evidence (documented segregation, test data demonstrating independence) that can take more time to produce and defend than simply building to Class C standards. For most small SaMD teams, the practical approach is: determine your class correctly using the top-down flow from ISO 14971, build to that class, and document it cleanly. Avoid class-reduction theater.

The software development process

IEC 62304 Clauses 5.1 through 5.8 define the software development lifecycle: planning, requirements analysis, architectural design, detailed design (Class C only), unit implementation and verification, integration, system testing, and release. Each clause generates a required output — document, record, or artifact — and each output is what an auditor expects to see in your software file.

Clause 5.1 — What does the Software Development Plan actually contain?

The Software Development and Maintenance Plan (SDMP) is the master planning document. It must define: the software safety class and rationale, development phases and deliverables, traceability approach (how requirements trace to design, implementation, and tests), configuration management strategy, risk management activities planned for the development lifecycle, and verification approach for each phase. FDA’s software guidance additionally expects an Architecture Design Chart and a process for generating a summary of Unresolved Anomalies — both should be in your SDMP.

The SDMP can reference existing SOPs (Software Development SOP, Change Management SOP, Problem Resolution SOP) rather than restating procedures in full. This keeps the plan concise while satisfying the completeness requirement. What cannot be deferred to an SOP: the product-specific parameters — safety class, technology stack, team, and development schedule.

Clause 5.2 — What makes software requirements auditable?

Every software requirement must have a unique identifier (e.g., SR-001) that enables bidirectional traceability: from the system-level requirement or risk control that generated it, through to the test case that verifies it. Risk control measures identified in your ISO 14971 process that are implemented in software must appear as explicit software requirements — this is the traceability chain that auditors use to verify your risk controls are actually implemented and tested. A requirements list without unique IDs, or with requirements not linked to test cases, is a major finding.

Clause 5.3 — What must the software architecture include for SOUP?

For Class B and Class C software, the architecture must identify every SOUP item with its exact version number, supplier, functional requirements (what you rely on it to do), and system hardware and software dependencies. “Latest stable,” branch names, or floating version ranges do not satisfy this requirement — exact version numbers are required because CVE database lookups depend on them. The architecture must also address security-relevant interfaces per the 2015 amendment, and for Class C software must identify segregation between software items implementing risk controls and other software items that could adversely affect them.

Clause 5.5 — How does pull-request-based development satisfy unit verification?

For Class B and Class C software, unit verification requires defined acceptance criteria, a verification process applied to each software unit, and documented results. Pull requests satisfy this if: (1) your SDMP defines the acceptance criteria for PR approval (requirements coverage, passing automated tests, code review by a non-author), (2) the review is actually performed and documented, and (3) PR approval records are retained as the verification records. This is a practical and auditor-accepted implementation — the key is that it must be defined in advance and consistently applied, not reconstructed after the fact.

Clauses 5.7 and 5.8 — System testing and release controls

System testing (Clause 5.7) is required for all software safety classes. Your test plan must include a traceability matrix linking each test case to the software requirement it verifies — requirements without test coverage cannot be claimed as verified. Risk control measures implemented in software must be explicitly tested; a CI/CD pipeline that runs only functional tests misses this requirement if security or safety-related controls are not in the test suite.

Release (Clause 5.8) requires: confirmation that all verification activities are complete, a documented evaluation of known residual anomalies (open bugs) for safety impact, unique version identification (a semantic version tag in git satisfies this), and archival of the software configuration.

Integrating software risk with ISO 14971

IEC 62304 Clause 7 defines software risk management activities for Class B and Class C software. It operates within the ISO 14971 risk management process — not in parallel to it. Software-specific risk analysis must feed into and be traceable within the Risk Management File.

What is the software risk management traceability chain?

The required traceability runs from hazardous situation through to verified risk control: (1) a hazardous situation identified in the ISO 14971 risk analysis involves a specific software item; (2) a risk control measure is implemented as a software requirement (Clause 5.2); (3) the software requirement is implemented in a specific software unit; (4) the risk control is verified by a specific test case; (5) the test is executed with a recorded result. This chain — hazard → software item → requirement → test → result — is the IEC 62304 Clause 7 traceability record. If any link is missing, the risk control is not demonstrably implemented.

How does SOUP fit into the risk analysis?

For Class B and Class C software, IEC 62304 Clause 7 requires analysis of potential causes of software contribution to hazardous situations, including anomalies in SOUP items. This means your risk analysis must include failure mode rows for each safety-relevant SOUP item: what happens to clinical outputs if this library fails, returns incorrect results, or has a security vulnerability that compromises data integrity? This is the link between your SOUP list (Clause 5.3) and your risk management file (ISO 14971) — and it is routinely absent in software files that treat SOUP as a documentation-only exercise.

SOUP — handling third-party software

SOUP — Software of Unknown Provenance — is any pre-existing software item that is used in your medical device software and was not developed specifically for that device. Open-source libraries, commercial components, operating systems, cloud SDKs, and ML inference runtimes are all SOUP. Managing SOUP correctly requires two connected activities: specification at the architecture stage and monitoring throughout the maintenance lifecycle. Most organizations stop at the first.

What does Clause 5.3 actually require for SOUP specification?

For Class B and Class C software, the software architecture must document each SOUP item with: the exact version number (not a range or “latest stable”), the supplier, the functional and performance requirements you depend on it to satisfy, and the hardware and software environment it requires to operate. A dependency list in a package.json or requirements.txt file is not a SOUP list — it does not document functional requirements or hardware dependencies and will not satisfy a notified body review. As Ketryx summarizes the requirement: “A simple list of libraries is not a SOUP management process. You must document why you chose each version and how you monitor its bugs.”

SOUP Evaluation Record structure (minimum viable):For each SOUP item, document: (1) Name and exact version — e.g., “NumPy 1.26.4”; (2) Supplier — e.g., “NumPy Developers (BSD-licensed, open source)”; (3) Functional requirements — what specific capabilities this item provides that the device software relies on; (4) Performance requirements — response time, memory constraints if relevant; (5) System dependencies — OS version, runtime version, hardware dependencies; (6) Known anomalies reviewed — CVE search date, NVD query used, results; (7) Safety impact determination — whether any known anomalies affect safety-related functions. This record satisfies both Clause 5.3.3 (architecture specification) and provides the baseline for Clause 8 monitoring.

What does Clause 8 require for ongoing SOUP monitoring?

Configuration management (Clause 8) requires that SOUP items be identified as configuration items and that changes to them be controlled. In practice, this means: your SOUP list must be reviewed on a defined schedule and whenever SOUP vendor advisories are received; each review must document the search methodology, queries used, results, and a safety impact determination signed by a named reviewer. Blanket “no vulnerabilities found” statements without NVD search evidence are cited as insufficient. Greenlight Guru’s guidance — “List your SOUP items and their versions in your software file” — describes only the specification step. The monitoring step is where most gaps occur.

What about AI/ML model weights as SOUP?

ML model weights and training data should be treated as SOUP under IEC 62304. Document them per Clauses 5.3.3 and 5.3.4 (functional and performance requirements at architecture time) and monitor for anomalies per Clause 7.1.3 post-release. The non-deterministic behavior of ML inference — outputs that vary between runs or degrade with model updates — creates hazardous situations that differ from classical software failure modes. Apply the same hazard analysis: what patient outcome results from an ML inference error, and is there an external control that prevents serious harm? If not, the ML software item is Class C. Document the model version (a hash or named checkpoint), the training data provenance, and the conditions under which the model’s outputs are considered reliable. Decompose the AI pipeline into distinct software items (pre-processing, inference, post-processing) so that interfaces and safety guardrails for each stage can be specified in the architecture.

What about the IEC 81001-5-1 seam for SOUP and cyber devices?

For cyber devices under Section 524B of the FD&C Act, your IEC 62304 SOUP list and your IEC 81001-5-1 SBOM address the same components from two different angles — safety provenance and security vulnerability tracking. The two lists should be reconciled: every SOUP item in your IEC 62304 architecture should appear in your SBOM, and every component in your SBOM that is used in the device software should be evaluated for safety impact in your SOUP analysis. The Cybersecurity Guide covers SBOM generation and vulnerability management in detail; use that for the security layer and cross-reference between the two lists rather than maintaining them independently.

Software maintenance

IEC 62304 Clause 6 covers software maintenance: the activities required after a software version is released to address problem reports, implement modifications, and manage the software over its lifecycle. Maintenance is subject to the same rigor as initial development — it is not a lighter-weight process.

What does the maintenance plan need to contain?

The software maintenance plan must define: the scope of maintenance activities, who is responsible, and the criteria that trigger unplanned maintenance. Establishing a schedule for planned maintenance reviews is recommended practice for lifecycle management, though it is not enumerated in Clause 6.1’s normative list. It must also define how post-market feedback channels are monitored — complaint systems, field service reports, SOUP vendor advisories — and how that monitoring feeds into the change control process. The maintenance plan is typically incorporated as a section of the SDMP rather than a standalone document.

When does a maintenance change trigger full development lifecycle activities?

Every software modification, including bug fixes, security patches, and SOUP updates, must be evaluated for safety impact before implementation. If the modification affects a Class C software item, the Class C process requirements apply to that modification — detailed design, unit verification with Class C acceptance criteria, and system testing. A change that seems cosmetically minor can elevate to Class C activities if the modified code path is involved in a safety-critical function. Cybersecurity patches are maintenance activities subject to this evaluation; firms that apply security patches without conducting impact analyses have a major gap per Clause 6.

What happens when a change is made to a device no longer under active development?

The maintenance process must cover the entire product lifecycle through device retirement. For devices no longer actively developed, problem reports and safety-significant issues still require triage and resolution through the established change control process. When a device is retired, the decommissioning process must ensure patient safety — devices remaining in the field after end-of-support represent an ongoing risk that must be managed, not declared out of scope.

Configuration management and problem resolution

IEC 62304 Clauses 8 and 9 describe the system disciplines that make your software development history auditable and your defect management legally defensible. No web guide frames it this way, but these are the clauses that explain what your git history and issue tracker are actually for under IEC 62304. The tools are not compliance by themselves — they become compliance when used with intent and documented process.

What does Clause 8 configuration management actually require?

Clause 8 requires identification of all software configuration items (source code, build scripts, SOUP, test artifacts, documentation), controlled changes to those items, and the ability to determine and reproduce the complete configuration of any released software version. Git with semantic version tagging satisfies this if: your SDMP documents git as the configuration management system, every release is tagged (e.g., v1.2.3), the tag allows the exact release artifact to be rebuilt, and your SOUP list identifies all third-party dependencies by exact version. The common gap in cloud SaMD is “version drift”: cloud platform APIs, managed services, and container base images update outside your control and outside your version control system, creating SOUP that changes without a change control record.

What does Clause 9 problem resolution require?

Every problem — bug report, customer complaint, anomaly discovered in testing — must enter a documented problem resolution process that includes: recording the problem, evaluating it for safety impact before deciding on a response, communicating to affected parties when the safety assessment requires notification, resolving it through the change control process (no uncontrolled hotfixes), and tracking it to closure. Problem records must include the investigation, resolution, and verification of the fix. Problem data must be analyzed for trends to identify systemic issues.

The gap most organizations have is not in capturing problems — most engineering teams use issue trackers that do this — it is in the safety triage step and the integration with the CAPA system. A bug that surfaces in GitHub Issues must flow through a formal safety impact assessment before being closed or deferred. Problems that are safety-significant must be escalated to CAPA with root cause analysis; organizations that close all bugs as engineering tickets without this escalation criterion have a systematic Clause 9 gap.

Does Clause 9 require evaluating all deployed device versions?

Yes. When a problem is identified, the process must determine whether it affects all versions currently in the field, not only the version in which it was first observed. For devices with long deployment histories, this requires maintaining records of which software versions were installed on which devices. For cloud SaMD where all users are always on the current version, this simplifies significantly — but the assessment must still explicitly confirm that all deployed instances are affected.

IEC 62304 alongside ISO 13485 and ISO 14971

IEC 62304 does not stand alone. Every major clause maps to a corresponding design control requirement in ISO 13485 (and FDA QMSR) and, for software contributing to safety-critical functions, to a corresponding risk management activity in ISO 14971. The table below maps the operative clauses to their ISO 13485 and QMSR counterparts.

How does IEC 62304 relate to IEC 81001-5-1?

IEC 81001-5-1 was structured intentionally to follow IEC 62304’s clause architecture, making the two standards complementary rather than parallel. Clause 5 of IEC 81001-5-1 (security development activities) extends Clause 5 of IEC 62304 with security-specific requirements at each development phase — security requirements, security architecture, secure coding standards, and security testing. Clause 8 of IEC 81001-5-1 extends Clause 8 of IEC 62304 with SBOM and vulnerability tracking requirements. In practice, you build one integrated Software Development and Maintenance Plan that covers both, organized by lifecycle phase, with IEC 62304 activities and IEC 81001-5-1 security activities listed together at each phase. Do not maintain two separate SDMPs.

Common audit findings

A Kelsey Review finds three clusters of IEC 62304 gaps in most software files: classification errors driven by the misconceptions described above, SOUP management that stops at the specification step without ongoing monitoring, and software risk management that is not connected to the device Risk Management File. The following callouts describe the specific finding patterns that appear most frequently.

Frequently asked questions

Does Class A software require almost no documentation?

No — and this is one of the most dangerous misstatements circulating in guides from QMS platform vendors. Clause 7 (software risk management) does not apply to Class A software, and the detailed design requirements of Clauses 5.4.2–5.4.4 apply to Class C only (though Clause 5.4.1, subdivide software into units, applies to Class B and C). But the development planning requirements of Clause 5.1, requirements analysis (5.2), system testing (5.7), release controls (5.8), maintenance (6), configuration management (8), and problem resolution (9) all apply to Class A software. If a vendor tells you Class A software needs almost no documentation, ask them to point to the clause that says so.

How does IEC 62304 interact with IEC 81001-5-1 for cyber devices?

IEC 62304 governs the software development lifecycle for safety. IEC 81001-5-1 extends that lifecycle with security requirements. For a cyber device under Section 524B of the FD&C Act (21 U.S.C. §360n-2), both apply simultaneously. Importantly, security requirements under IEC 81001-5-1 apply even to Class A software — safety class does not determine your cybersecurity obligations. In practice: use IEC 62304 to structure your Software Development and Maintenance Plan, and add an IEC 81001-5-1 extensions section covering security activities at each lifecycle phase. The two standards were designed to be complementary; IEC 81001-5-1 follows the same clause structure as IEC 62304 intentionally. See the Cybersecurity Guide for the security layer.

When does a software change force a safety class upgrade?

A software change forces a class upgrade when it introduces software that can now contribute to a higher severity harm than the previous version permitted. Specifically: if your current Class B system is modified to include a function that, upon failure, could contribute to death or serious injury — and no external risk control prevents that outcome — the modified software item becomes Class C and the overall system follows the highest class of its components. You must re-evaluate the classification at each significant design change. This is documented in the Safety Classification Review portion of your change management process.

Does IEC 62304 require Clause 5.4 detailed design for all software?

Not in full. Clause 5.4.1 (subdivide software items into software units) applies to Class B and Class C software. Clauses 5.4.2 through 5.4.4 — which require detailed design documentation and unit-level verification of the detailed design — apply to Class C software only. This distinction matters: a Class B manufacturer must still decompose software items into units (5.4.1), even though the full detailed-design documentation layer is a Class C requirement. If you are implementing Class C software items, plan for detailed design documentation before unit implementation begins.

How do I handle AI/ML components under IEC 62304?

Treat ML model weights, training pipelines, and inference runtime as SOUP (Software of Unknown Provenance) items under IEC 62304. The relevant SOUP clauses are 5.3.3 and 5.3.4 (functional and performance requirements for SOUP items, documented at architecture time) and, post-release, Clause 7.1.3 (monitoring for anomalies in SOUP items). Non-deterministic behavior — outputs that vary given the same input due to model updates or stochastic inference — is a hazard trigger that must be evaluated in your software risk analysis. Decompose the AI pipeline (pre-processing, model inference, post-processing) into distinct software items in your architecture rather than treating the ML component as an opaque black box. Notified bodies expect to see interface specifications and safety guardrails for each stage. For the architecture, document the exact version of model weights treated as a configuration item. For safety classification, apply the same class-assignment logic: can an AI inference failure contribute to serious harm? If yes, and no external control prevents it, the AI software item is Class C.

What is a 'software file' and what goes in it?

IEC 62304 does not use the term 'software file' explicitly — but in practice this refers to the complete collection of software development outputs that an auditor would request. At minimum, this includes: (1) the Software Development and Maintenance Plan, (2) the software safety classification with rationale, (3) software requirements list with unique IDs, (4) software architecture description with SOUP list, (5) unit verification records, (6) system test plan and protocol, (7) release checklist and known anomaly evaluation, (8) configuration management records (release tags in version control), and (9) problem resolution records. Class C systems add detailed design records. The exact document structure is flexible; what matters is that each required activity has a traceable output.

What is the 'proportionality for small teams' principle?

IEC 62304 does not explicitly define proportionality, but the standard's activity requirements scale by safety class. For a small team, the practical guidance from regulatory consultants experienced in the standard — including Johner Institute — is straightforward: develop software to Class C standards by default, and document it accordingly, rather than investing resources in arguing for a lower class assignment. Class-reduction arguments require architectural evidence of segregation, which often costs more to produce and defend than simply implementing Class B or C requirements. A 3-person team building a Class C SaMD can satisfy all IEC 62304 requirements with lean documentation — the plan, requirements list, architecture doc, and test protocol do not need to be extensive. They need to be complete and traceable.

Can a Class I FDA device contain Class C IEC 62304 software?

Yes — and conflating these two classification systems is one of the most common audit findings. FDA Class I, II, and III refer to device risk levels and determine the regulatory pathway (exempt, 510(k), PMA). IEC 62304 Class A, B, and C refer to the severity of harm that could result from software failure. A Class I FDA device containing software that, upon failure, could contribute to serious injury contains Class C IEC 62304 software, regardless of the FDA device class. The two axes are independent. Assigning Class B software requirements because a device is FDA Class II — as published by at least one major QMS platform — is incorrect and constitutes a major audit finding.

Further reading

Standards

IEC 62304:2006+Amd 1:2015 — Medical device software — Software life cycle processes. Available from IEC (iec.ch) and national standards bodies; approximately $200–300 USD. The 2015 amendment is integral to the current standard; purchase the consolidated edition. IEC 81001-5-1:2021 — Health software and health IT systems security — Part 5-1: Security activities in the product life cycle. See the Cybersecurity Guide for the full security layer treatment.

Regulatory guidance

FDA Content of Premarket Submissions for Device Software Functions — FDA’s guidance on software documentation for premarket submissions, including the Architecture Design Chart and Unresolved Anomalies summary requirements. Check the FDA guidance index for the current edition.

EU MDR General Safety and Performance Requirements (Annex I) — Chapter I Section 17 covers software requirements for EU MDR submissions. IEC 62304 is a harmonized standard under EU MDR; conformity is typically demonstrated by reference in the Technical Documentation.

Reference and tooling

Johner Institute IEC 62304 resources — detailed clause-by-clause guidance, including the top-down classification methodology and class-reduction analysis. OpenRegulatory open-source IEC 62304 document templates — a set of starting-point documents (SDMP, software requirements list, SOUP list, release checklist) maintained in GitHub under MIT license, suitable as a baseline for small teams. TÜV SÜD — note on EU AI Act (2024/1689) linkage to IEC 62304 for AI/ML medical software: the EU AI Act classification of AI systems as high-risk corresponds to, but is not coextensive with, IEC 62304 safety classification; both analyses are required for AI-based SaMD marketed in the EU.