IEC 62304 for software as a medical device—what engineers need to know

IEC 62304 is the international standard that defines software lifecycle process requirements for medical device software. It applies to software that is itself a medical device—Software as a Medical Device, or SaMD—and to software embedded in or used to control a hardware medical device. If your product involves software in either of those categories, IEC 62304 is not optional. FDA recognizes it as a consensus standard and expects compliance documentation in submissions. The EU MDR and IVDR both require it for CE marking. Virtually every major regulatory jurisdiction has adopted or recognized it.

What makes IEC 62304 substantively important—rather than just another documentation framework—is its classification-based approach to rigor. The standard acknowledges that not all software failures carry the same consequence. A bug in a scheduling interface has different patient safety implications than a bug in a closed-loop insulin dosing algorithm. IEC 62304 structures its requirements around that reality, demanding more of software where failure matters most.

Understanding software safety classes A, B, and C

The three safety classes in IEC 62304 are determined by the severity of harm that could result from a software failure. Classification happens in the context of your ISO 14971 risk analysis—you cannot determine your software safety class without first understanding the hazardous situations your software could contribute to and the severity of potential harm.

Class A covers software where a failure cannot contribute to a hazardous situation, or where any hazardous situation would result in no injury or negligible injury. Class A software carries the lightest documentation requirements—you must have a development plan and a configuration management system, but the full battery of software lifecycle documentation required by higher classes is not mandated.

Class B applies when software failure could contribute to a hazardous situation resulting in non-serious injury. Class B triggers the full software development lifecycle requirements: software requirements specification, software architectural design, detailed design, unit implementation and verification, integration and integration testing, and system testing. The documentation depth required for Class B is substantial—software requirements must be traceable through architecture, detailed design, and verification—but the requirements stop short of demanding formal methods or the most rigorous unit testing approaches.

Class C is required when software failure could contribute to a hazardous situation resulting in serious injury or death. Class C adds to the Class B requirements with more rigorous unit verification—typically requiring formal code coverage metrics—and additional documentation of design decisions at the unit level. For AI/ML-enabled SaMD, most machine learning components driving clinical outputs will be Class C, and the documentation expectations under IEC 62304 intersect with FDA's evolving guidance on AI/ML-based SaMD.

One important nuance: software safety class is assigned at the software item level, not just the system level. A device may contain software items of different classes. A Class C medical device may contain a Class A scheduling module alongside a Class C closed-loop control algorithm. Each software item must be classified individually, and the lifecycle documentation requirements apply per item.

The software development lifecycle under IEC 62304

IEC 62304 defines the lifecycle in terms of processes, not a specific development methodology. Waterfall, iterative, and agile approaches are all compatible with IEC 62304, provided the required documentation is maintained. The standard does not prescribe how you develop software—it prescribes what you must be able to demonstrate about the development.

The software development planning process requires documenting the lifecycle model, development standards, deliverables, and reviews. The plan must address how software items will be classified, how SOUP will be managed, and how configuration management will be maintained.

Software requirements must be specified at a level of detail sufficient to allow verification. They must address functionality, performance, security, usability, and—critically—all hazard-related requirements identified in the risk analysis. Requirements traceability connects each requirement to the design element that addresses it and the test that confirms it—this traceability matrix is a core IEC 62304 artifact and a central element of submission documentation.

Software architectural design must decompose the system into software items, define their interfaces, and identify which items are safety-relevant. The architecture document is where you establish the boundaries that determine SOUP identification—every component that is not fully developed under your quality system is potentially SOUP.

System testing must verify that the integrated software system meets its requirements. Test cases must be traceable to requirements, test results must be recorded, and anomalies discovered during testing must be resolved and documented.

SOUP management—the challenge most teams underestimate

Software of Unknown Provenance—SOUP—is any software item that was not developed under your quality system or for which the development records are unavailable. This includes open-source libraries, commercial off-the-shelf components, operating systems, and third-party frameworks. Nearly every modern software product is built substantially from SOUP.

IEC 62304 requires that you identify all SOUP items, document their functional and performance requirements, document any known anomalies, and evaluate the risk contribution of each SOUP item. For Class B and C software, you must also document the testing performed to verify SOUP suitability for its intended use in your system.

SOUP management is where many SaMD programs generate their most significant IEC 62304 documentation debt. Development teams add dependencies continuously—a new library here, a framework upgrade there—without maintaining the SOUP registry and associated risk evaluation that the standard requires. By the time a submission is being prepared, the SOUP inventory may be substantially incomplete, and reconstructing it from dependency manifests is both time-consuming and imprecise.

The problem compounds when SOUP items are updated. A library version change is a SOUP change event under IEC 62304—it requires re-evaluation of the SOUP item's risk contribution and potentially additional verification of system behavior. In an agile development environment where dependencies update frequently, maintaining this record manually is a significant operational challenge.

V&V documentation—where the IEC 62304 cascade lives

Verification and validation documentation under IEC 62304 forms a cascade: requirements flow to design, design flows to implementation, implementation is verified by unit and integration testing, and the integrated system is validated against its requirements in a use context. Every step in that cascade must be documented, and the documentation must be traceable—meaning each test result must reference the requirement it confirms and the design element it exercises.

MANKAIND's engineering intelligence platform handles the IEC 62304 documentation cascade by treating traceability as a structural property of the development record—not a documentation task performed after testing. When a software requirement is created in the platform, it is immediately linked to its source in the risk analysis and user needs. When a test case is written, it references the requirement it addresses. When test results are recorded, the traceability chain from requirement through design to verified result is complete and current.

The consequence is that when you need to produce the IEC 62304 traceability matrix for a submission, it is not assembled by querying separate systems and matching records by requirement ID. It generates from the live development record—because every decision in the platform was made in the context of the standard's requirements from the first day of development. For SaMD teams working under tight timelines, that difference is not incremental. It determines whether submission preparation takes weeks or months.