The ABCs of software safety classification: Part 2 — Bridging risk, rigour, and reality with ISO 14971 & IEC 62304

Misunderstanding the difference in risk concepts between IEC 62304 and ISO 14971 is one of the most common causes of friction and delays in the assessment of a software medical device. This blog post will explore the intent behind these two standards, the common pitfalls teams encounter when navigating them, and why architecture and a clear rationale are essential to device conformity.

Manufacturers often struggle with IEC 62304 and software classification due to a common misconception: that risks are considered similarly to their definitions in ISO 14971. These standards differ in their approach to risk and fundamental intent, which, if poorly understood, can result in SaMD manufacturers making critical decisions that lead to inconsistencies in documentation and delays in device certification.

In medical device software, we come across a commonly held perception when engaging with IEC 62304: “This module is Class C, so it must be inherently high risk.” But this is not necessarily true, as it conflates concepts introduced in IEC 62304 with those introduced in ISO 14971. This stems from how these two standards approach risk estimation differently.

A tale of two standards

Let’s look at the two standards in question:

• ISO 14971 requires a holistic identification, estimation, and evaluation of risks, considering both reasonable probability and severity. This evaluation then guides the creation of risk controls that reduce the risks, ensuring the overall medical device is safe for its intended use.
It is concerned with overall risk management and how this impacts users.
• IEC 62304 software safety classification, on the other hand, is anchored in the assumption of software failure. The software is then classified solely by the severity of harm to users such a failure could cause, considering only risk controls external to the software system. That classification dictates how rigorous the software development process and subsequent documentation must be for a given software system or component.


Common pitfalls in software safety classification

What the differences between these standards mean in practice is that reasonable decisions made in service of one standard may result in difficult regulatory scenarios with the other, particularly in the context of software safety classification. 

Even experienced teams can run into these traps:

• Using internal risk controls to lower safety classification

Under IEC 62304, a hazard mitigated with a risk control inside the same software system cannot be used to justify a lower classification.

• Treating the whole system as one software item

Without architectural segregation, a single safety-relevant function can make the entire system Class C, increasing the verification and documentation workload unnecessarily, as the entirety of the software system is now subject to the highest level of rigour under IEC 62304. It is important to note that any software-segregation approach does need to be adequately defined to demonstrate effectiveness at isolating safety-critical function.

• Vague or missing classification rationale

Software safety classification decisions without supporting rationale may raise concerns, particularly if classifications differ between software items. Supporting information should link hazards to software items, make it clear that the “probability of software failure = 1” rule was applied, explain why internal controls were excluded, and define severity referencing IEC 62304 Clause 3.25 for serious injury.

Why architecture and classification rationale matter

IEC 62304 classification is done at the level of a software item or system. How you define those software boundaries has a direct impact on classification. Segregating safety-critical modules can confine Class C rigour to where it is genuinely needed, allowing other modules to remain in Class A or B. This reduces the testing and documentation burden, while keeping non-safety modules more flexible during development.

Equally important is documenting the reasoning behind each classification decision. Auditors and reviewers should be able to trace exactly why an item has been given a certain classification. This means demonstrating how hazardous situations identified in risk management map to the software architecture, and clearly stating the clauses applied in decision-making, such as 4.3(a) and 3.25. 

Well-prepared classification rationale is one of the most effective ways to avoid prolonged assessment delays due to misalignment on this topic, and can help clearly demonstrate a manufacturer’s consideration of this standard.

Tying it back to ISO 14971

IEC 62304 classification may have its own rules, but it still fits within the broader ISO 14971 risk-management framework. Consistency is key — hazards, hazardous situations, and harm severity defined under ISO 14971-compliant risk-management processes should be consistent with documented contributions from software items. 

Conversely, where risk probabilities have been documented, make it clear which standard’s approach has been adopted. Due to the different approaches of these standards to risk probability, it is important to make this distinction — solely adopting ISO 14971’s approach will lead to misclassification for software safety, whilst solely adopting the IEC 62304 approach may yield higher risk probabilities than are realistic for a risk-management file.

When this connection is maintained, reviewers can more easily follow your decisions and verify that the classification of software items is consistent with the overall risk-management process.

Summary

ISO 14971 and IEC 62304 have fundamentally different aims. ISO 14971 evaluates overall safety in real-world use, while IEC 62304 defines development rigour for worst-case failure scenarios. Recognising this distinction helps prevent misinterpretations, especially around Class C software. Where these standards find common ground is how they both benefit from clear architecture and transparent justification, which form the bridge between the two standards and support both safe product design and efficient assessments. 

In the final blog post of this series, we’ll do a deep dive into some specific real-world scenarios where these common pitfalls may materialise in technical-file submissions, along with practical approaches manufacturers can take to resolve them, or avoid them entirely.