IEC 62304 is the international standard that defines the software life cycle processes for medical device software. It specifies the planning, development, maintenance, risk management, configuration management, and problem resolution activities a manufacturer must follow, scaling the required rigor to the safety risk the software presents to patients and users.
What is IEC 62304?
IEC 62304, titled “Medical device software, software life cycle processes,” is the consensus standard from the International Electrotechnical Commission (IEC) governing how medical device software is built and maintained. It covers software that is itself a medical device, known as Software as a Medical Device (SaMD), as well as software embedded in or running on a physical device.
The standard does not prescribe a development methodology. It defines the processes, activities, and records that must exist, then lets the team map those onto waterfall, agile, or a hybrid. The current version is IEC 62304:2006 with Amendment 1 (2015). A second edition is in development, expected to widen the scope and address cybersecurity and machine learning.
Why IEC 62304 matters in medical device development
Software defects in a medical device can injure or kill, often surfacing long after release. IEC 62304 exists to make those risks visible and controllable through documented processes and traceability rather than ad hoc testing.
Regulators treat it as the baseline. The U.S. FDA recognizes IEC 62304 as a consensus standard, and the EU harmonizes it as EN 62304 under the Medical Device Regulation (EU MDR 2017/745). A submission built on a clean IEC 62304 record moves faster because reviewers can follow requirements through to verification evidence. A weak record invites questions, audit findings, and delays.
How IEC 62304 works
The process starts with safety classification. The manufacturer assigns each software item a class based on the worst credible injury a failure could cause, assuming no external mitigation:
- 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.
The class sets how much process and documentation a given item needs. A Class C therapy controller carries far heavier requirements than a Class A logging utility. The standard also lets you partition a system so lower-risk items keep a lower class where segregation can be demonstrated, and that segregation can be logical, not only physical hardware separation.
With classes assigned, the development process runs through these activities:
- Software development planning.
- Requirements analysis.
- Architectural design.
- Detailed design.
- Unit implementation and verification.
- Integration and integration testing.
- Software system testing.
- Software release.
Four supporting processes run alongside development: maintenance, risk management, configuration management, and problem resolution. Risk management is directly tied to ISO 14971, so software hazards are captured in the same risk file as the rest of the product.
One concept does a lot of work in practice: SOUP, or Software of Unknown Provenance. This is any software not developed under IEC 62304, such as an off-the-shelf library or operating system. You must identify each SOUP item, document its requirements, and evaluate its known issues against your risk analysis.
IEC 62304 assumes an ISO 13485 quality management system, links to ISO 14971 for risk, and pairs with IEC 62366-1 for usability and IEC 81001-5-1 for software security.
Common challenges and best practices
The most common mistake is downgrading the safety class to dodge work, for example, calling an item Class A because an external control catches the failure, then skipping architecture and unit verification. Auditors push back hard, and the coming edition narrows that path, so classify honestly and partition only where you can defend it.
Traceability is the second pitfall. Requirements, design, and tests drift apart when kept in separate, hand-updated documents. Linking them in a managed tool, each requirement tied to its verification, removes most of the audit-time pain.
SOUP handling tends to get neglected until late. Build the inventory early, track upstream advisories, and revisit it at each release. Treat configuration management and problem resolution as live processes from day one.
How SJML helps with IEC 62304
Syrma Johari MedTech (SJML) supports the full IEC 62304 software life cycle as part of its design, engineering, and compliance services. Embedded systems and software engineering teams develop device software within a phase-gate process with change control, while the QARA practice provides Software as a Medical Device support, including IEC 62304 lifecycle work and IEC 81001-5-1 cybersecurity risk assessment. Software risk management is addressed in ISO 14971, and usability in IEC 62366, so software records align with the device risk file and the broader technical documentation.
Talk to SJML’s engineering team →
Frequently asked questions
The correct designation is IEC 62304. The standard was developed and published by the International Electrotechnical Commission, not ISO, so “ISO 62304” is a common misnaming. In Europe, the harmonized version is published as EN 62304. You should cite it as IEC 62304.
IEC 62304 defines three safety classes based on the harm a software failure could cause. 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. The class determines how much design, verification, and documentation each software item requires.
IEC 62304 is a voluntary standard, but conformance is the practical route to market. The FDA recognizes it as a consensus standard, and the EU lists EN 62304 as harmonized under the Medical Device Regulation. Meeting it gives a presumption of conformity, so most manufacturers treat it as mandatory for any device with software.
SOUP stands for Software of Unknown Provenance. It refers to software components you did not develop under IEC 62304, such as third-party libraries, an operating system, or legacy code. The standard requires you to inventory each SOUP item, define its requirements, and assess its known anomalies against your software risk analysis before use.
Related terms
IEC 62366-1 | ISO 14971 | Software as a Medical Device (SaMD) | IEC 81001-5-1 | Design Verification
