By AptSkill MedTech | IEC 62304 Compliance | Reading time: 9 min
Of all the decisions in a SOUP assessment, the safety class determination is the one that carries the most downstream weight. Get it wrong — in either direction — and the consequences follow you through the entire development lifecycle.
Assign too high a class and you create unnecessary documentation burden, slower development cycles, and a compliance workload that consumes engineering time without improving patient safety. Assign too low a class and you under-document a genuine risk, open the door to audit findings, and potentially ship a device with insufficiently tested software.
This guide explains exactly how IEC 62304 defines the three SOUP safety classes, walks through the decision logic step by step, and addresses the classification questions that medical device teams argue about most.
Why Safety Class Is the Most Consequential Decision in Your SOUP Assessment
The safety class of a SOUP item determines which IEC 62304 requirements apply to it. This is not a minor administrative choice — it directly governs:
- How much software architecture documentation you must produce
- Whether you must document detailed design
- How extensive your software verification must be
- What your software system testing must cover
- How thoroughly you must document anomalies and known bugs
IEC 62304 defines three software safety classes — A, B, and C — based on the potential risk to patients, with Class C having the highest requirements. Each software component must be classified — the highest class of a component determines the class of the entire software system.
Here is what that means in practice:
For software in safety class A, manufacturers only need to document the software requirements and software release. For Class B, the software architecture and software verification must also be documented. For Class C, detailed design must also be documented.
That is a significant difference in workload. The decision is worth getting right.
The Three Classes Defined
Class A — No Injury Possible
The software system is Class A if it cannot contribute to a hazardous situation, or if it can contribute to a hazardous situation which does not result in unacceptable risk after consideration of risk control measures external to the software system.
The critical phrase is “external to the software system.” Class A is not simply software that seems unlikely to cause harm — it is software where harm is prevented by something entirely outside the software itself. A hardware interlock, a trained clinician’s independent verification, a redundant physical system. If the only thing standing between a software failure and patient harm is the software itself, the software is not Class A.
Class B — Non-Serious Injury Possible
The software system is Class B if it can contribute to a hazardous situation which results in unacceptable risk after consideration of risk control measures external to the software system, and the resulting possible harm is non-serious injury.
Class B is the middle ground. The software can contribute to harm even after external safeguards are considered, but the worst-case injury would be non-serious. This classification applies to a broad range of diagnostic and monitoring software where errors are consequential but not life-threatening.
Class C — Serious Injury or Death Possible
The software system is Class C if it can contribute to a hazardous situation which results in unacceptable risk after consideration of risk control measures external to the software system, and the resulting possible harm is death or serious injury.
Class C software carries the full weight of IEC 62304’s requirements. Any SOUP item whose failure could — even indirectly — contribute to a chain of events ending in death or serious injury belongs here, unless segregation from that chain of events can be demonstrated and documented.
The Decision Logic: How to Actually Classify a SOUP Item
IEC 62304 provides a decision diagram in Clause 4.3. Worked through in plain language, the process goes like this:
Step 1: Assume the SOUP fails completely. Not degrades. Fails. Returns wrong values. Crashes silently. What happens to the device?
Step 2: Can that failure contribute to a hazardous situation? If the answer is definitively no — the software is so peripheral to device function that its failure has no pathway to patient harm — you are looking at Class A. Document that reasoning carefully.
Step 3: If yes, can risk control measures external to the software make that risk acceptable? A hardware safety cutoff, a mandatory clinical confirmation step, a separate independent monitoring system — these are external controls. If they reduce the residual risk to acceptable levels, Class A may still apply.
Step 4: If the residual risk remains unacceptable after external controls, what is the severity of possible harm? Non-serious injury points to Class B. Serious injury or death points to Class C.
One important principle: the software safety class is independent of probabilities. For each identified chain of events, the contribution of software to a hazard is assumed to be 100% probability. This catches many teams off guard. You cannot argue for a lower class on the basis that a failure is unlikely. The class is determined by the severity of what happens if the failure occurs, not by how often you expect it to occur.
IEC 62304 requires you to start with assigning a Class C safety class. The default position is the highest risk class. You then work downward by demonstrating — through documented risk analysis — that lower harm severity or effective external controls justify a reduced classification. The burden of proof is on the reduction, not the assignment.
Where Teams Get the Classification Wrong
Mistake 1: Confusing Device Regulatory Class with Software Safety Class
This is one of the most common misconceptions. There is no direct relationship between regulatory classes (I, II, III) and software safety classes (A, B, C). They are two different scales coming from two different sources. It is very likely that a Class I/II/III device contains Class A/B/C software — but this is just a rule of thumb.
A Class I medical device can contain Class C software. A Class III device can contain Class A software items. The software safety class depends on the failure mode analysis of that specific software item in that specific device context — not on the device’s regulatory classification. Teams that assume their Class I device automatically has Class A software will miss this distinction entirely.
Mistake 2: Classifying the System When You Should Classify the Item
IEC 62304 allows — and encourages — classification at the software item level, not just the system level. If your device software contains a Class C data processing module and a Class A logging module, you do not need to apply Class C documentation requirements to the logger. The architecture must demonstrate segregation, but the administrative burden scales to the actual risk.
Risk control measures external to the software can reduce safety classes, which reduces the documentation effort. Architectural segregation is itself a risk control measure. Documenting it rigorously is what makes the reduced classification defensible.
Mistake 3: Under-Classifying SOUP Relative to the System It Belongs To
SOUP items are software items. They sit within the software architecture and inherit the safety class of the software item or system they are part of. If a SOUP item is embedded in a Class C software module and its failure can affect that module’s output, the SOUP item is Class C — regardless of how innocuous the library might seem in isolation.
The classification question is never “what does this library do in general?” It is always “what does this library do in this device, and what happens if it fails?”
Mistake 4: Trying to Reduce Class Through Probability Arguments
As noted above, IEC 62304’s classification methodology assumes software failures happen with 100% probability. One of the most misunderstood statements in the medical device software field is that the probability of occurrence of harm should be set to 100% just because you are working with software. The probability of occurrence of harm can be split up into two components — P1 (the probability of the hazardous situation occurring) and P2 (the likelihood that the hazardous situation will lead to harm). However, the classification step — as opposed to the risk acceptability assessment — treats software contribution as certain. You classify based on severity; you manage residual risk using the full probability framework.
Teams who write “low probability of failure, therefore Class A” in their rationale will attract audit questions they cannot easily answer.
Mistake 5: Setting the Class Once and Never Revisiting It
Classification is not a one-time activity. Changes to SOUP items — upgrades, bug fixes, patches, and obsolescence — may trigger a need to re-evaluate the safety classification. If a new version of a SOUP library changes its behaviour in ways that affect the failure mode analysis, the classification may need to be revisited. If the device’s intended use changes, the same library may now sit in a different risk pathway. The assessment must be kept current.
How to Write a Defensible Classification Rationale
The classification decision is only as strong as the rationale that supports it. An auditor or notified body reviewer will go straight to this section. A bare “Class B” with no explanation is not sufficient. A robust rationale answers four questions:
What does this SOUP item do in the device? Not in general — specifically, in the context of your device and its intended use. What inputs does it process, what outputs does it produce, and what does the device do with those outputs?
What is the failure mode? What happens if the SOUP returns wrong values, returns nothing, crashes, or behaves unexpectedly? Be specific — “fails” is not a failure mode. “Returns a value outside the expected range without raising an exception” is a failure mode.
What is the chain of events from that failure to patient harm? Walk through the pathway. Each link in the chain matters. Where are the external safeguards? Where does the chain break?
What is the maximum credible harm? Given the failure mode and the chain of events, what is the worst-case outcome for the patient or user? The answer to this question determines the class.
An example rationale that auditors find acceptable: “This library performs FFT signal processing on cardiac waveform data. If the library returns incorrect frequency-domain values, the device may miscalculate heart rate variability metrics and display incorrect diagnostic information. The treating clinician reviews these metrics alongside direct ECG traces before making treatment decisions — this independent clinical review constitutes an external risk control. With this external control in place, residual risk is assessed as acceptable, and the resulting possible harm is limited to a delayed or sub-optimal treatment decision rather than direct physical harm. Classified as Class B.”
Compare that to: “Class B — some injury possible.” Both assign the same class. Only one is defensible.
Class A, B, C and What They Mean for Documentation Volume
To make the difference concrete, here is what each class requires of your SOUP assessment and broader development documentation:
Class A SOUP items require identification and a post-market surveillance plan. Requirements documentation is best practice but not mandated. The assessment is lighter — but the rationale for Class A must be strong, because auditors know teams are incentivised to under-classify.
Class B SOUP items require everything in Class A, plus: defined functional and performance requirements, a documented verification strategy with test cases traceable to those requirements, software architecture documentation showing where the SOUP sits in the system, and a complete anomaly and CVE review.
Class C SOUP items require everything in Class B, plus: detailed design documentation, more rigorous verification including unit-level testing traceability, and formal risk analysis linked to your ISO 14971 risk management file. The documentation load is substantial — which is why the temptation to under-classify is real, and why auditors look closely at Class B rationales on high-risk devices.
Reducing Safety Class Through Architecture: The Segregation Strategy
One legitimate approach to managing documentation burden is architectural segregation. If a SOUP item can be isolated — genuinely isolated, not just labelled as isolated — such that its failure cannot propagate into the safety-critical parts of the device, a lower class may be justified.
Manufacturers that assign a class to each segregated software item may reduce the administrative burden of IEC 62304 compliance. Software items with software safety Class A must fulfil only a limited set of requirements, whereas software items with Class C must comply with the entire standard.
The requirement is that segregation must be demonstrated, not asserted. Your software architecture document must show the boundary. Your test evidence must prove that failure on one side of the boundary cannot cross to the other. If you claim a SOUP item is segregated from your Class C processing pipeline, an auditor will look for the architecture diagram, the interface specification, and the test results that verify the boundary holds.
Putting It All Together in Your SOUP Assessment
The safety class section of your SOUP assessment needs to contain three things: the assigned class, the rationale that justifies it, and — if a reduced class is claimed — the segregation evidence that makes it defensible.
A structured SOUP assessment template ensures this section is never left vague. It prompts engineers to document the failure mode, the harm pathway, the external controls in place, and the resulting classification — creating the kind of evidence that holds up under audit scrutiny and, more importantly, ensures the risk has actually been thought through.
Start With the Right Template
Getting the safety classification right starts with having the right structure to work from. The AptSkill SOUP Assessment Form includes a dedicated Class A/B/C determination section with space for rationale, segregation evidence, and FDA/EU MDR framework alignment — so every SOUP item your team assesses is documented to the level auditors actually expect.
Download the SOUP Assessment Form Template →
One-time purchase, full team licence, instant .docx download.
AptSkill MedTech publishes practical compliance guides for medical device engineers and regulatory affairs professionals working with IEC 62304, EU MDR, and FDA software requirements.