IEC 62304: Verification Scales With Risk Class

Mostafa Dhouib·September 6, 2026·5 min read

IEC 62304: Verification Scales With Risk Class

The short answer. Three software safety classes set by what happens if the software fails: A, no injury possible; B, non-serious injury possible; C, death or serious injury possible. Verification rigor and traceability scale with the class, and the standard is process focused, requiring that verification be planned, performed and recorded.

If you are building a body-worn or closed-loop medical device, this is the standard that will govern the clinical bridge, and the first thing to understand about it is what sets the class.

The three classes

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.

Note what determines the class. Not how complex the software is. Not how much of it there is, or how novel, or how much of the product's value it represents. Consequence. What happens to a person if it fails.

That trips teams up in a specific and expensive way. A small piece of software controlling something physical can be Class C, while a large and sophisticated analytics platform can be Class A. The classification is about the harm, and it is set early, and it decides the obligations for everything that follows.

What scales with the class

Higher classes require progressively more rigorous unit, integration and system testing.

Documented test procedures, rather than testing that happened. This is a real distinction and it catches people: work you did but did not record does not exist for the purposes of the standard.

Traceability from software requirements through to tests, and to risk controls under ISO 14971.

The standard is process focused. Verification activities must be planned, performed and recorded, and anomalies must be tracked. That is the documented, auditable version of "prove your checks work and act on the red."

Confidence note: the class definitions are well established. The exact clause-by-clause test obligations here come from reputable standard summaries rather than the primary text, which is paywalled, so confirm specifics before building a submission around them.

Why traceability is the interesting requirement

Most people read traceability as a documentation burden, and it is one. It is also the requirement that answers a question this whole pillar keeps asking.

Which check covers this requirement, and has anybody watched it fail?

A traceability matrix answers the first half mechanically. Requirement to test, test to risk control. It makes the gaps visible: a requirement with no test, a risk control with nothing verifying it, a test attached to nothing.

It does not answer the second half. A traced test that has never been observed failing is still a decoration, and it is a decoration with an audit trail, which is worse in one specific way: the paperwork increases everybody's confidence in it. The standard requires you to record that verification was performed. It does not require you to have watched the check go red on a known-broken input, and nothing stops you doing both.

Anomaly tracking, and the case behind it

The requirement to track anomalies is the institutional version of not silently quarantining a red test.

The case that sits behind this whole part of the standard is the Therac-25, and its investigators located the cause in institutional response as much as in the software. Early incident reports were dismissed. Clinics reporting injuries were told the machine could not do what they were describing.

An anomaly tracking requirement exists because somebody worked out that a system producing warnings nobody acts on is functionally a system producing no warnings. Knight Capital's 97 ignored pre-open emails are the same failure with money instead of radiation.

What to do if you are building one of these

Classify first, and classify honestly. The class is set by consequence, and optimism here is expensive later, because the obligations for the class you should have chosen do not go away when you discover the mistake.

Budget for it. Roughly 15 to 35 percent more up front effort is the figure from the test-discipline studies, and top assurance level rigor is commonly estimated at 3 to 5 times, from industry estimates rather than controlled study. Both numbers belong in the plan rather than in the surprise.

Treat a serious hazard depending on a single sensor, or an unverified reused module, as a design defect to fix before certification rather than a test to add later. That is the MCAS and Ariane lesson in a regulatory frame, and it is the one that changes staffing and timeline rather than the test plan.

Build the traceability as you go. Retrofitting it is the single most common way these programmes lose a quarter, and it is entirely avoidable.

The related standards are in DO-178C and MC/DC and ISO 26262, and the general argument is in a test that has never failed is a decoration.

FAQ

What are the IEC 62304 software safety classes? Class A, where no injury or damage to health is possible; Class B, where non-serious injury is possible; and Class C, where death or serious injury is possible.

What determines the class? Consequence, not complexity. A small piece of software controlling something physical can be Class C while a large analytics platform is Class A.

How do verification requirements change by class? Higher classes require progressively more rigorous unit, integration and system testing, documented test procedures rather than undocumented testing, and traceability from requirements through tests to risk controls.

Does IEC 62304 require traceability? Yes, from software requirements through to tests and to risk controls under ISO 14971, with verification activities planned, performed and recorded and anomalies tracked.

How reliable are these clause details? The class definitions are well established. The clause-level test obligations here come from standard summaries rather than the paywalled primary text, so confirm specifics before building a submission around them.