IEC 62304 Software Safety Classification: Class A, B and C Explained (2026 Guide)

IEC 62304 software safety classification is the decision the rest of the standard hangs on. Clause 1.4 defines compliance as performing the processes, activities and tasks required for the software safety class — so before anyone writes a plan, a requirement or a test, the class has to be decided, recorded and defended. Get it right and a Class A team knows exactly which 57 requirements it owes; get it wrong and an assessor can unwind every document that followed.

This guide explains how the classification works under IEC 62304:2006+AMD1:2015 (Edition 1.1, the edition in force), what Amendment 1 changed, how decomposition and segregation let items carry a different class from the system, and what each class actually requires.

What this guide covers

• IEC 62304 software safety classification: the three classes
• How the IEC 62304 software safety classification decision is made
• The Class C default in IEC 62304 software safety classification
• IEC 62304 software safety classification after decomposition: inheritance and segregation
• IEC 62304 software safety classification of items that implement risk controls
• What each IEC 62304 software safety classification requires — the parts people miss
• Recording the IEC 62304 software safety classification
• Common errors in IEC 62304 software safety classification
• Frequently asked questions

IEC 62304 software safety classification: the three classes

Under IEC 62304 software safety classification, the standard assigns each software system one of three classes on the basis of the worst-case hazardous situation it could contribute to — after the risk control measures that sit outside the software are taken into account.

The counts come from the standard’s own Table A.1, counting one requirement per numbered sub-clause of clauses 4 to 9. They matter because the IEC 62304 software safety classification is not a label — it is the selection of which process obligations bind you. Class C is everything; Class B drops six requirements; Class A drops 41.

How the IEC 62304 software safety classification decision is made

Clause 4.3 a) sets out the IEC 62304 software safety classification rule. The manufacturer assigns a class to each software system according to the risk of harm to the patient, operator or other people from a hazardous situation the software could contribute to, in a worst-case scenario. Three features of that sentence do most of the work.

Worst case, not typical case

The class is decided by the most severe hazardous situation the software could contribute to, not the most likely one. A dose-calculation function that is right 99.99% of the time is classified on what happens the other 0.01%.

After external risk controls

Amendment 1 made this explicit. If a hardware interlock, an independent software system or a clinical procedure reduces the risk of the hazardous situation to an acceptable level, the software system may be classified lower than its raw contribution would suggest. A manufacturer may even add such measures — including changing the device architecture around the software — and then assign a new, lower class. The reasoning has to be documented, and the external measure has to be verified under the device’s ISO 14971 risk management process.

Probability of software failure is one

Annex B.4.3 of the standard is candid about why the scheme looks the way it does: there is no agreed method for estimating the probability that software will fail. So when software sits in a sequence of events leading to harm, its failure probability is set to 1 and the risk is judged on the severity of the harm — and, where they can be estimated, on the probabilities of the non-software events in the sequence. Clinical knowledge of whether a clinician would detect the failure before harm is a legitimate input.

The Class C default in IEC 62304 software safety classification

Clause 4.3 g) is one sentence and it is easy to miss: until a software safety class is assigned, Class C requirements apply. An unclassified system is not an unregulated one. For compliance purposes it is a Class C system, owing detailed design, unit-level verification, integration testing and the full clause 7 risk process.

The practical consequence is that IEC 62304 software safety classification should happen at system definition, as a preliminary decision that shapes the development plan — and then be confirmed at the end of architectural design, which Annex B.4.3 identifies as the earliest point at which every software item is known and the hazard analysis can say which items matter to safety.

IEC 62304 software safety classification after decomposition: inheritance and segregation

A software system is rarely one uniform block. It is decomposed into software items, and items into further items or units. IEC 62304 software safety classification follows the decomposition with three rules from clause 4.3 d) to f):

• Inheritance is the default. An item created by decomposing a system or another item inherits the parent’s class. No rationale is needed for that.
• A different class needs a segregation rationale. An item may be classified differently from its parent only where the manufacturer documents how the items are segregated so that they can be classified separately. The rationale has to explain the mechanism and how its effectiveness is assured.
• Groups take the highest class. When the standard is applied to a group of items, the processes required by the highest-classified member apply to the group, unless a rationale for a lower class is recorded in the risk management file.

Segregation is broader than “separate processors”. The standard’s note gives that as one example whose effectiveness is easy to show — no shared resources — but Annex B.4.3 says any mechanism that prevents one item from adversely affecting another qualifies, provided the rationale is documented. Memory protection, separate processes with mediated communication and message-passing interfaces with integrity checks are all used in practice; each carries an assumption that has to be verified.

The standard’s own IEC 62304 software safety classification example makes the point. A Class C system is partitioned into items X, W and Z. Every contribution that could lead to death or serious injury is segregated into Z (Class C); every non-serious contribution into W (Class B). Item X contributes to nothing and, because its segregation from the others is demonstrated, is Class A. Any item that cannot be segregated from Z stays Class C — and so does the system.

IEC 62304 software safety classification of items that implement risk controls

Clause 7.2.2 adds a rule that surprises teams doing IEC 62304 software safety classification for the first time. A software item that implements a risk control measure — a rate limit, a plausibility check, a watchdog — is classified on the risk that the measure controls, not on the harm the item could cause by itself. A small monitoring function guarding against a fatal over-infusion is Class C, however trivial its own code.

What each IEC 62304 software safety classification requires — the parts people miss

The full deliverable list by class is in our guide to IEC 62304 documentation requirements; the risk activities are covered in IEC 62304 risk management. Two rows of this IEC 62304 software safety classification table deserve emphasis. Class A owes all of system testing — a test for every software requirement, with the seven record items of 5.7.5. And Class A owes all of maintenance, configuration management and problem resolution, including identifying every SOUP item by title, manufacturer and unique designator. “We are Class A so it does not apply” is true of architecture and detailed design; it is false of almost everything after release.

Recording the IEC 62304 software safety classification

Clause 4.3 c) requires the class of each software system to be documented in the risk management file. Where an item’s class differs from its parent’s, that is documented too (4.3 e)), and any rationale for treating a group at a lower class goes in the file as well (4.3 f)). An assessor reading the file expects to find the hazardous situations considered, the external controls credited, the worst-case harm, the class, the decomposition and the segregation rationale — with a name and a date.

The classification is then re-examined whenever the architecture changes, whenever the device risk analysis changes, whenever a change request could affect a hazardous situation the software contributes to, and at every release. Clause 8.2.2 folds it into change control: implementing a change includes re-examining the class of the system and its items.

Common errors in IEC 62304 software safety classification

• Classifying on probability of failure. The standard takes it as one. Arguing that “the bug is unlikely” does not lower the class.
• Confusing the class with regulatory classes. The IEC 62304 class is not the EU MDR risk class under Rule 11, and it is not FDA’s Documentation Level, which is decided before any mitigation. A Class B system can sit in an MDR class IIb device and need Enhanced FDA documentation. Record all three separately.
• Crediting an external control that was never verified. A hardware interlock lowers the class only if the device risk process has verified it.
• Claiming segregation without a mechanism. “Different modules” is not segregation. A partition, a processor boundary or a mediated interface is — with evidence that it works.
• Leaving a preliminary class as the final one. Annex B.4.3 says early classification is useful for focusing attention but should not be used to justify omitting processes. Confirm it once the architecture is settled.
• Waiting for Edition 2. The classes are not expected to change, and Edition 1.1 remains the edition in force — see our IEC 62304 Edition 2 status update.

The IEC 62304 Toolkit carries the classification procedure, the record that goes in the risk management file, and a decision workbook that walks each hazardous situation to a class outcome and then filters all 98 requirements to the class you assign — 57, 92 or 98 rows — so the plan that follows is built on the right list. The standard itself is licensed by the IEC; the classification rules above are paraphrased from it, and the shall-statements are in the text.

Frequently asked questions

Is IEC 62304 software safety classification decided once?

No. It is assigned provisionally at system definition, confirmed at the end of architectural design, and re-examined at every architecture change, risk analysis change, change request and release. A problem report can also reveal a wrong class, and the problem resolution process may propose changing it.

Can a Class C system contain Class A items?

Yes, if the Class A items are segregated from the higher-class items by a documented mechanism whose effectiveness is shown. The system as a whole keeps the class of its highest-classified item.

Does Class A software need a maintenance plan?

Yes. Every requirement of clause 6 applies to every class, including the maintenance plan, feedback evaluation, change request approval and communication to users and regulators. Class A is exempt from design and integration activities, not from post-release obligations.

Is the IEC 62304 class the same as the FDA Documentation Level?

No. FDA’s June 2023 software guidance decides Basic or Enhanced documentation on whether a failure could present a probable risk of death or serious injury before any mitigation; the IEC 62304 class is decided after external risk controls. They often align but are separate determinations and should be recorded separately — see our guide to IEC 62304 and FDA’s software guidance for the US side and to harmonised standards under the MDR for the European side of the same distinction.