IEC 62304 is the international standard that defines the lifecycle processes for medical device software. It does not tell you how to write code, and it does not certify a product. Instead it defines a framework of processes, activities, and tasks that demonstrate your software was developed and maintained under control. If your device is software, or contains software, IEC 62304 is the baseline expectation of FDA reviewers and EU Notified Bodies alike, and the fastest way to structure a defensible software design history file.
What IEC 62304 Is and Where It Applies
The full title is "Medical device software - Software life cycle processes." Its scope covers software that is itself a medical device (often called SaMD) and software that is embedded in or part of a medical device (SiMD). It applies to new development and to changes made to existing software. It deliberately assumes that software is developed within a quality management system (such as ISO 13485) and that risk is managed under ISO 14971, so it references those standards rather than duplicating them. IEC 62304 covers the software you develop; it does not by itself cover the hardware, the clinical validation, or the overall device design controls, which live in your broader QMS.
Software Safety Classification Drives the Rigor
The engine of the standard is its safety classification. Every software system, and each of its items, is assigned a class based on the severity of harm that could result from a failure, assuming the hazard actually occurs:
- Class A. No injury or damage to health is possible.
- Class B. Non-serious injury is possible.
- Class C. Death or serious injury is possible.
Classification is done after you account for risk control measures, and you may segregate software items so that a small, well-isolated Class C item does not force the entire system to the highest rigor. The class you assign determines how many of the standard's activities and documentation tasks are mandatory. Class A requires the least; Class C requires the full set, including detailed design and more granular verification. Getting the classification right, and justifying it, is one of the highest-leverage decisions in the whole project.
The Software Development Process
Clause 5 lays out the development activities in a logical, traceable flow. You do not have to use a waterfall model, but you do have to show that each of these was performed and that the outputs trace to one another:
- Development planning. Establish a software development plan that defines processes, deliverables, tools, and configuration and problem-resolution approaches.
- Requirements analysis. Define and document software requirements, including functional, performance, interface, and risk-control requirements, and verify them.
- Architectural design. Define the software architecture, decompose the system into items, and specify interfaces, including those to any SOUP.
- Detailed design. Refine items into units and document unit-level design (required for Class C).
- Implementation and unit verification. Write and verify the code against acceptance criteria.
- Integration and integration testing. Combine units and items and test their interactions.
- System testing. Verify the software against its requirements, and record and resolve anomalies.
Traceability from requirements through design, code, and test is the connective tissue that reviewers look for first.
Software Risk Management and the Link to ISO 14971
IEC 62304 does not define its own risk framework. It requires that software risk management be performed as part of the device risk management process defined by ISO 14971. In practice this means you identify software items that could contribute to a hazardous situation, trace those contributions to their causes (including failures and, where relevant, SOUP anomalies), define risk control measures, and verify that those measures are implemented and effective. Changes to software must be evaluated for their risk impact before release. This tight coupling is why a software project and its risk file cannot be built in isolation from each other.
Managing SOUP (Software of Unknown Provenance)
SOUP is software you did not develop under IEC 62304 and cannot fully characterize, such as an operating system, a third-party library, or off-the-shelf middleware. The standard does not forbid SOUP; it requires you to manage it deliberately. For each SOUP item you must document its functional and performance requirements, the hardware and software it needs to operate, and the specific version you are using. You must also review published anomaly lists (for example, known bugs and CVEs) to determine whether any could contribute to a hazardous situation, and account for that in your risk analysis. Maintaining a current SOUP inventory is also foundational to your cybersecurity software bill of materials.
Maintenance, Problem Resolution, and Post-Market
Release is not the end of the lifecycle. IEC 62304 requires a software maintenance process and a software problem resolution process that continue for the life of the product. You establish a maintenance plan, evaluate reported problems and feedback, analyze them for safety impact, and implement changes under the same controls (including configuration management and re-verification) that governed initial development. This closes the loop with post-market surveillance: field problems feed back into risk management, and safety-relevant changes are handled with the rigor their class demands.
Alignment with FDA and EU MDR Expectations
IEC 62304 is a recognized consensus standard at FDA and a harmonized reference under the EU regulatory framework, so building to it serves both markets. FDA's premarket software documentation guidance expects documentation whose depth scales with the software's Documentation Level (Basic or Enhanced), which maps closely to the risk-based logic of IEC 62304 classification. The artifacts the standard produces, requirements, architecture, design, verification, traceability, and a SOUP list, are precisely the evidence an FDA submission and a Notified Body technical file expect to see. Under EU MDR, conformity to IEC 62304 supports the general safety and performance requirements for software, and pairs with IEC 82304-1 for standalone health software. Building once to the standard, rather than reverse-engineering documentation later, is far cheaper and far more defensible.
How Sequence Group Can Help
Sequence Group helps medical device and digital health companies stand up an IEC 62304 compliant software lifecycle that reviewers trust. We help you justify your safety classification, build a right-sized software development plan, and establish the traceability, risk linkage to ISO 14971, and SOUP management that hold up under audit. Whether you are starting a new SaMD program, remediating a legacy codebase, or preparing an FDA submission or EU MDR technical file, we tailor the process to your device's risk without over-engineering it. Contact us to discuss how to make your software documentation a strength in your next submission.
Frequently Asked Questions
Is IEC 62304 mandatory for medical device software?
It is not a law by itself, but it is a recognized consensus standard at FDA and a harmonized reference in the EU. In practice, conforming to IEC 62304 is the expected way to demonstrate that your software lifecycle is controlled, and departing from it means you must justify an equivalent approach to regulators.
How do I determine my software safety class?
You assign Class A, B, or C based on the worst-case severity of harm that could result from a software failure, evaluated after risk control measures are in place and assuming the hazard occurs. Class A means no injury is possible, Class B means non-serious injury is possible, and Class C means death or serious injury is possible. You can segregate software items so an isolated high-risk item does not force the whole system to Class C.
What is SOUP and how do I manage it?
SOUP is software of unknown provenance, meaning code you did not develop under IEC 62304 such as an operating system, third-party library, or off-the-shelf component. You must document its requirements, its operating environment, and its exact version, and review published anomaly and vulnerability lists to determine whether any known issue could contribute to a hazardous situation. A current SOUP inventory also supports your cybersecurity software bill of materials.
How does IEC 62304 relate to ISO 14971?
IEC 62304 does not define its own risk framework; it requires that software risk management be carried out within the ISO 14971 process. You identify software items that could contribute to a hazard, trace those contributions to their causes, implement and verify risk control measures, and re-evaluate risk whenever the software changes.
Does IEC 62304 satisfy FDA and EU MDR software expectations?
It aligns closely with both. FDA's premarket software documentation guidance scales documentation to a Basic or Enhanced level that maps to the risk-based logic of IEC 62304 classification, and the artifacts the standard produces are what an FDA submission expects. Under EU MDR, conformity to IEC 62304 supports the software-related general safety and performance requirements and pairs with IEC 82304-1 for standalone health software.