When medtech teams begin working with IEC 62304, the international standard for medical device software lifecycle processes, one of the first things they encounter is the software safety classification system. Understanding this system, and understanding what it does and does not mean, is foundational to building a compliant software development program.

The safety class assigned to your software will shape your entire development process. It determines which IEC 62304 requirements apply to you, how much documentation you need, and how rigorously you must test and verify your software. Getting it right early saves you significant rework later.

BONUS RESOURCE: Click here to download your free Cybersecurity Gap Assessment Checklist!

The three IEC 62304 safety classes

IEC 62304 defines three software safety classes, each based on the severity of injury that a software failure could potentially cause:

• Class A: No injury or damage to health is possible as a result of a software failure.

• Class B: A software failure could cause injury, but not serious injury.

• Class C: A software failure could cause death or serious injury.

These three categories form the foundation of the standard's tiered approach to software development requirements. The higher the safety class, the more rigorous the development activities and documentation must be.

What safety class does and doesn’t mean

The first principle to keep in mind here is that software safety classification is not a determination of how safe your software is. It is a determination of the potential consequences of a failure, and on that basis, it sets the level of rigor required during development.

A Class C safety classification does not mean your software is dangerous or poorly designed. It means that if a failure were to occur, the consequences could be severe, and therefore your development process must be held to the highest standard to prevent that from happening. The classification is an input to your development rigor, not an output of it.

Similarly, your IEC 62304 safety class does not directly correspond to your regulatory risk class under FDA or EU MDR classification systems. A Class C safety classification often correlates with a high-risk device, but the two systems use different criteria and must be evaluated independently. You cannot use one as a substitute for the other. For a full comparison of how the classification systems relate to each other, see our post on SaMD classification.

How safety class affects development requirements

The practical impact of safety class shows up throughout the IEC 62304 standard. Each class carries a different set of requirements, and the standard explicitly identifies which activities are required for each.

• For Class A software, the requirements are the least prescriptive. You still need a development process, but many of the more detailed documentation and verification activities that apply to higher classes are not required.
  

• For Class B software, the requirements become more detailed. You are required to document software requirements, architectural design, and unit testing, among other activities. The level of formality and documentation increases substantially compared to Class A.
  

• For Class C software, the full set of IEC 62304 requirements applies. This includes detailed documentation of software requirements, architectural and detailed design, unit implementation and verification, integration testing, and system testing. Every step must be traceable, and every decision must be documented. The standard holds Class C software to this high bar because the stakes demand it.

One important consequence of this tiered approach is that your safety class determination affects not just your development activities, but also your risk management, configuration management, and problem resolution processes. All of these are interconnected under IEC 62304, and the safety class impacts all of them.

How to determine your software safety class

The safety class determination is the manufacturer's responsibility. IEC 62304 provides the criteria, but the manufacturer is responsible for applying them to their product.

The starting point is a risk analysis conducted in accordance with ISO 14971, the international standard for risk management in medical devices. The goal is to evaluate what would happen if your software failed. Could it cause death or serious injury? Non-serious injury? Or is there no plausible path to patient harm from a software failure?

It is worth noting that this analysis should be conducted before risk control measures are applied. You are assessing the potential severity of harm from a failure, not the residual risk after mitigations are in place. The safety class reflects the worst-case consequences of failure in the absence of controls, which is what drives the rigor of the development process itself.

You should also consider whether different components of your software warrant different safety classes. IEC 62304 allows for what it calls "software item" classification. This is the idea that different modules or components within a larger system can be assigned different safety classes based on their individual failure modes and consequences. It can be a practical way to avoid applying Class C rigor uniformly across an entire codebase when only a subset of it poses the highest level of risk. However, any software item that contributes to a higher-class safety concern must be developed to that higher standard.

Safety class and the broader development context

IEC 62304 does not exist in isolation. For SaMD manufacturers, it sits alongside ISO 14971 for risk management, ISO 13485 for quality management systems, and applicable regulatory requirements from the FDA, EU MDR, or other markets. The software safety classification is one input into a broader system of requirements that together define how your development process must operate.

One area where safety class has particular downstream significance is in software validation. FDA's Quality Management System Regulation requires that software used in production or in the quality system be validated for its intended use. The level of validation effort, as FDA's General Principles of Software Validation guidance states, should be proportional to the risk posed by the automated operation.

A note on agile development

Many SaMD development teams work in agile environments, which can create uncertainty about how to apply IEC 62304's requirements, especially at Class C, where the documentation burden is highest. The standard was written with a relatively linear development model in mind, but it is entirely possible to fulfill IEC 62304 requirements using agile methods.

AAMI TIR 45 provides guidance specifically on the use of agile practices in medical device software development and is a valuable resource if you are trying to reconcile your development methodology with the standard's requirements. The key is ensuring that the required documentation and verification activities are completed. The standard does not prescribe when or in what order those activities occur within an iterative cycle, only that they occur.

BONUS RESOURCE: Click here to download your free Cybersecurity Gap Assessment Checklist!

How Greenlight Guru helps you manage IEC 62304 compliance

Meeting IEC 62304 requirements, especially at Class B or Class C, means maintaining traceability across every stage of your software development lifecycle, from requirements through testing, risk management, and postmarket problem resolution. Doing that in spreadsheets or disconnected tools is technically possible, but it creates real risk: outdated records, missing links between design inputs and outputs, and gaps that surface at the worst possible moment during an audit.

Greenlight Guru is built to eliminate that risk. The platform's product development software connects requirements management, risk management, and software release management in a single system, so your IEC 62304 documentation is traceable by default and not assembled after the fact. For SaMD and SiMD teams specifically, Greenlight Guru acts as the bridge between your development work and your quality system, helping you move faster without sacrificing compliance.

To see how Greenlight Guru supports SaMD and SiMD development teams get your free demo today!