IEC 62304 Medical Device Software Lifecycle: Safety Classes, Processes and SOUP

IEC 62304 is the international standard for the software life cycle of medical devices. Regulators in the US, EU and elsewhere expect it, or an equivalent, for any software that is part of a device or is a device in its own right. It does not tell you how to write code. It tells you which activities and records you need so that software risk is controlled and your work can be audited. This guide explains the structure of the standard, how safety classes drive the effort, and how to apply it without drowning a small team in paperwork.

Scope and how it fits the other standards

The standard applies to medical device software and software within medical devices, including software that is a device in itself. It sits alongside other standards:

• ISO 14971 for risk management. See risk management for medical devices.
• ISO 13485 for the quality system the processes sit in.
• IEC 62366-1 for usability engineering. See usability engineering.
• IEC 82304-1 for the safety and security of health software products.
• FDA software guidance and the EU MDR general safety and performance requirements, which both expect lifecycle evidence. See 510(k) for software and medical device cybersecurity.

The standard is being revised, so check which edition your regulator and notified body expect when you start.

Safety classes

Class	Definition	Effect on effort
A	No injury or damage to health is possible from a software failure	Lowest: planning, requirements, system testing, release and maintenance processes
B	Non-serious injury is possible	Adds architectural design, integration, and detailed documentation of the design and verification
C	Death or serious injury is possible	Highest: detailed design of units, unit verification and the most rigorous acceptance criteria

The class is assigned to each software system, and software items inside it can be assigned a lower class if you can show segregation. Class depends on the risk after considering risk controls outside the software, so keep the classification rationale linked to your risk file. When in doubt, classify conservatively: reclassifying a system upward late in the project is expensive.

The processes

1. Software development planning: a plan that defines processes, deliverables, tools, traceability, configuration and the handling of SOUP.
2. Software requirements analysis: functional, performance, interface, security and risk control requirements, each testable.
3. Architectural design: items, interfaces, segregation and the identification of SOUP (Class B and C).
4. Detailed design: unit design (Class C, and partly B).
5. Unit implementation and verification: coding standards, reviews and tests, with acceptance criteria that match the class.
6. Integration and integration testing: verifying that the items work together as designed.
7. System testing: verifying that the software meets the requirements, with regression testing and traceability.
8. Release: a documented release with known residual anomalies evaluated for risk, archived and reproducible.

Alongside these run maintenance (including a plan for feedback and change), risk management, configuration management and problem resolution.

Risk management for software

Software does not wear out, so software hazards come from specification errors, design errors and unexpected use. IEC 62304 asks you to identify software items that can contribute to a hazardous situation, define risk control measures (often implemented in software), verify them and analyse the effect of changes. The traceability chain from hazard to risk control requirement to test to release should be unbroken, and it should be easy to show an auditor. Cybersecurity risks that can lead to harm belong in the same chain.

SOUP: third-party and open-source software

Any software item you did not develop under the standard is SOUP. You need to specify its functional and performance requirements, check that the system and hardware it runs on are suitable, track its anomaly lists and manage its versions. Read our guides on what counts as SOUP, SOUP and the safety classes and the SOUP assessment process.

Applying the standard in agile teams

IEC 62304 does not require a waterfall model. Agile and iterative teams can comply when each iteration produces the evidence the standard asks for. Practical points:

• Define the lifecycle in the plan, and describe how a sprint maps to requirements, design, verification and release.
• Keep requirements, risk controls and tests in a tool with traceability, so records are generated rather than written afterwards.
• Automate verification (unit and regression tests) and keep the evidence for each release.
• Control changes: a change after release needs an impact assessment, risk review and regression testing. See change control for 510(k) and MDR and FDA PCCP guidance for planned updates.

What regulators and auditors look for

• A software plan that matches what the team actually does.
• Requirements that are testable, with traceability to risk controls and tests.
• A safety class rationale linked to the risk file.
• SOUP lists with versions, anomaly assessment and justification.
• A clean release record, with known anomalies assessed.
• Evidence that problems found after release feed into the problem resolution and CAPA processes. See CAPA and complaint handling.

Common mistakes

• Writing the documents after the code, so they describe what was built rather than what was planned.
• Assigning Class A by assuming that hardware controls will always work, without evidence in the risk file.
• Ignoring open-source libraries, or listing them without versions or anomaly checks.
• Letting traceability break between requirements, risk controls and tests.
• Releasing without evaluating the residual anomalies.

Frequently asked questions

Is IEC 62304 mandatory?

It is a voluntary standard, but it is recognised by FDA and is a harmonised standard under the EU framework, so following it is the usual way to show conformity. If you use another approach you need to justify it.

Does it apply to SaMD?

Yes. Software that is itself a medical device is in scope. See SaMD training for the wider picture.

Can we use agile?

Yes, if each iteration generates the required records and your plan explains the mapping. Many teams use an iterative approach with a formal release step.

What if we update the software after release?

Treat each update as a change: assess risk and regulatory impact, run regression testing and release under the same process. Plan for maintenance from the start.

Standards are revised and regulatory recognition changes. Confirm the edition and the regulator’s expectations for your product with your notified body or regulatory advisers.

Related reading

• Software validation (CSV and CSA): validating the tools and quality system software around your product.
• SaMD training: the software as a medical device pathway.
• Medical device cybersecurity: security risk in the same lifecycle.
• SOUP assessment template: a practical record.
• Design controls: how software fits the design file.

Talk to the AptSkill team

Need training on IEC 62304, SaMD or software quality? Send us your role and goal.