Who assigns the software safety class, and how?

You do, through your risk management process, and you document the rationale. The classification follows the standard's decision logic: if a failure of the software can contribute to a hazardous situation, the class depends on the severity of the possible harm after external risk controls are considered — Class A when no injury is possible, B when non-serious injury is possible, C when death or serious injury is possible. Different software items in one system can carry different classes if they are properly segregated.

Can we develop with agile methods under IEC 62304?

Yes. The standard defines what must exist and be controlled — plans, requirements, architecture, verification, records — not the order or rhythm you produce them in. AAMI TIR45 documents how agile practices satisfy 62304. The trap is treating sprint artifacts as the controlled records; they feed the records, they don't replace them.

What counts as SOUP? Are our open-source libraries SOUP?

SOUP — software of unknown provenance — is any software you incorporate but didn't develop under 62304: open-source libraries, vendor SDKs, runtimes, the operating system. Each SOUP item must be identified with its version, its functional and performance requirements documented, its failure modes considered in risk analysis, and its known anomalies reviewed for relevance.

Does IEC 62304 cover software validation?

No — that surprises many teams. 62304 is a lifecycle and verification standard; it deliberately leaves validation (does the software meet user needs and intended use?) to other processes — usability engineering under IEC 62366-1, product-level validation, and for the EU the clinical evaluation. Your verification evidence under 62304 feeds those activities; it doesn't substitute for them.

IEC 62304 in Plain English: Software Safety Classes and the Lifecycle

Q: Is IEC 62304 legally mandatory?

Strictly, no — neither the EU MDR nor the FDA names it as compulsory. Practically, yes: FDA recognises it as a consensus standard, and in the EU it is how software teams demonstrate the state of the art that GSPR 17.2 demands. Choosing not to follow it means building an equivalent argument from scratch, in front of a reviewer who knows 62304 by heart.

What 62304 is (and isn't)

A lifecycle standard, not a coding standard.

IEC 62304 — formally IEC 62304:2006 with its 2015 amendment — defines the lifecycle processes for medical device software: what must be planned, documented, verified and maintained from first requirement to final retirement. It applies whether the software is embedded in a device or is the device itself (SaMD).

Just as important is what it leaves out. It doesn't tell you what language, architecture or methodology to use. It doesn't cover validation — proving the software meets user needs belongs to usability engineering (IEC 62366-1) and product-level validation. And it doesn't stand alone: the standard explicitly assumes it operates inside an ISO 13485-style quality system and an ISO 14971 risk management process. 62304 is the software-shaped hole in that larger machine.

62304 doesn't ask you to write software a particular way. It asks you to be able to show how you wrote it — and to have controlled every step you claim you took.

Safety classes

Three classes. One question: what's the worst credible harm?

Every software system gets a safety class, assigned through your risk management process and documented with its rationale. The logic of the 2015 amendment: if a failure of the software can contribute to a hazardous situation, classify by the severity of the harm that could result — after taking external risk controls (hardware interlocks, independent monitoring) into account.

CLASS A

No injury possible

Software failure can't lead to injury. The lightest documentation set: requirements, basic verification, configuration management, problem resolution.

CLASS B

Non-serious injury possible

Failure could injure, but not seriously. Adds architecture documentation, integration testing and deeper verification on top of Class A.

CLASS C

Death or serious injury possible

The full programme: detailed design documentation, unit verification, and the most rigorous evidence trail across every activity.

Two practical notes. First, the class is a documentation and rigor dial, not a quality judgement — a Class A wellness feature and a Class C dosing algorithm can live in the same product. Second, that's exactly the point of segregation: a system can be partitioned into software items with different classes, as long as you can demonstrate the boundaries hold. Without demonstrated segregation, the highest class wins for everything it touches.

The five processes

What the standard actually requires you to run.

Process	What it demands
5 · Development	The core: a development plan (5.1), software requirements traced to system requirements (5.2), architecture (5.3), detailed design (5.4), unit implementation and verification (5.5), integration testing (5.6), system testing (5.7) and a controlled release (5.8). Which of these apply, and how deeply, depends on the safety class.
6 · Maintenance	A maintenance plan and a controlled process for post-release changes — bug fixes and updates go through analysis, implementation and verification, not straight to production.
7 · Software risk management	The software-specific arm of your ISO 14971 process: identifying software contributions to hazardous situations, implementing software risk controls, and verifying them.
8 · Configuration management	Every software item, every version, every SOUP component identified and controlled. You must be able to reconstruct exactly what any released version contained.
9 · Problem resolution	A documented path from bug report to analysis, to risk relevance, to fix, to verification — with records that survive the people who handled the ticket.

If that table looks like "competent software engineering, written down" — that's the right reading. Teams with healthy practices (version control, code review, CI, issue tracking) usually have 70% of the behaviour already. What they're missing is the controlled record: the plans, the traced requirements, and evidence at named versions.

SOUP

Software of unknown provenance: your dependency tree, regulated.

Any software you ship but didn't develop under 62304 is SOUP — open-source libraries, vendor SDKs, the runtime, the operating system. The standard doesn't forbid it; modern software is mostly other people's code, and the committee knew it. It requires you to manage it:

Identify every SOUP item — name, manufacturer, exact version — in your configuration records.
Specify what you rely on it for: the functional and performance requirements the SOUP must meet, plus the hardware/software it needs to run correctly.
Take it into risk analysis: what happens to patients if the library fails, returns garbage, or behaves differently after an upgrade?
Review its known anomalies — published bug lists and CVEs — for relevance to your device, at adoption and at every version bump.

The practical consequence for a startup: pin your dependency versions, keep the inventory automatically generated if you can, and treat dependency upgrades as controlled changes with a risk look — not as a Friday-afternoon npm update.

Regulatory standing

Not legally required. Practically unavoidable.

No regulation names IEC 62304 as mandatory. Its force comes from how the regulators read it:

In the US, FDA recognises IEC 62304 as a consensus standard — declaring conformity to it is the established way to cover the software lifecycle expectations in premarket submissions, and your lifecycle records back the design controls that the QMSR inspects.
In the EU, GSPR 17.2 of the MDR requires software to be developed according to the state of the art, naming the development lifecycle, risk management and verification explicitly. IEC 62304 is the state of the art for that clause — it's typically the standard cited in the GSPR matrix, even though the MDR's harmonised-standards list doesn't yet include it (so it carries no formal presumption of conformity). Your 62304 evidence also feeds the software V&V section of the technical file.

In other words: you could, in theory, argue an equivalent lifecycle of your own design. In practice, every reviewer you'll ever meet thinks in 62304's vocabulary, and the cheapest way through the conversation is to speak it.

FAQ

Common questions.

Is IEC 62304 legally mandatory?

Strictly no, practically yes. FDA recognises it as a consensus standard; in the EU it's how you demonstrate the state of the art that GSPR 17.2 demands. Not following it means building an equivalent argument from scratch — in front of a reviewer who knows 62304 by heart.

Who assigns the safety class, and how?

You do, via your risk management process, with a documented rationale. Classify by the worst credible harm a software failure could contribute to, after external risk controls: A — no injury, B — non-serious injury, C — death or serious injury. Segregated software items can carry different classes within one system.

Can we work agile under 62304?

Yes — the standard defines what must exist and be controlled, not your cadence. AAMI TIR45 maps agile practice onto 62304 explicitly. The trap is letting sprint artifacts be the controlled records; they feed the records, they don't replace them.

Are our open-source libraries SOUP?

Yes — along with your runtime, SDKs and operating system. Identify each with its exact version, document what you rely on it for, take its failure modes into risk analysis, and review its known anomalies at adoption and at every upgrade.

Does 62304 cover software validation?

No. It covers the lifecycle and verification. Validation — does the software meet user needs and the intended use — belongs to usability engineering (IEC 62366-1), product-level validation, and in the EU the clinical evaluation. Plan for both; one doesn't substitute for the other.

IEC 62304 in plain English: the software lifecycle, declassified.