IEC 62304 for startup founders

Strip away the clause numbers and IEC 62304 is asking for five things most competent engineering teams already do in some form: a documented plan for how the software will be built, requirements that trace to what was actually implemented, an architecture with a stated rationale — including how safety-relevant parts are separated from everything else — testing proportionate to what could go wrong, and a process for handling defects and changes after release rather than treating release as the finish line. The gap between "we do this informally" and "we can show a reviewer we do this" is almost always where the real work sits, not in the engineering itself.

This is also why retrofitting IEC 62304 onto an existing, undocumented codebase is the single most expensive path through this standard. Traceability from requirement to implementation to test, built by tooling as the team works, costs very little. The same traceability reconstructed a year later from git history and memory costs weeks, and a reviewer can usually tell the difference from the dates alone.

Classification is per software item, and it is judged on the worst credible harm that item could contribute to after any external risk controls are accounted for: 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. Founders are frequently tempted toward Class A because it carries the lightest documentation burden, but very little software that produces a clinical output — a score, a flag, a recommendation — actually clears the bar once you reason honestly about what happens downstream of a wrong answer. An optimistic Class A declaration is the first thing a reviewer stress-tests, and it rarely survives.

The classification is also not a one-time global label for the product. A logging module, a UI rendering layer, and the algorithm computing a clinical score can legitimately carry different classes, provided the architecture genuinely segregates them and the segregation itself is justified and verified — which is the real content of the next section.

Software of unknown provenance — SOUP — is any component your team did not develop under the standard, which in practice means essentially every third-party library, every open-source dependency, and often code your own team wrote before the QMS existed. A package.json or a lockfile is not a SOUP list. What the standard wants for each one is a stated purpose, the functional and performance requirements it has to satisfy, the environment it depends on, and — the part teams skip — an ongoing process for reviewing published anomalies against how you actually use the component, not just whether a scanner flags a known CVE.

For a small team this is manageable if it starts early and is treated as a living artifact rather than a document produced once. Left until a submission is imminent, cataloguing every dependency a growing codebase has accumulated over eighteen months is a genuinely large undertaking, and it is one of the more common reasons a first submission slips.

Since Amendment 1, IEC 62304 classification considers external risk control measures — meaning a hardware interlock or an independent monitoring channel outside the software item in question can legitimately bring its classification down, from C to B, for instance. That has real commercial consequence: the difference in documentation and testing burden between B and C is substantial. Teams that deliberately isolate the safety-relevant logic into a small, well-bounded item — rather than letting it diffuse through a monolith — are making an architectural choice with a direct regulatory payoff, provided the isolation is genuine and the rationale is written down and verified rather than asserted.

IEC 62304 classification is downstream of the qualification and risk-classification decisions covered in our guide to SaMD risk classification, and it feeds directly into the QMS and design-control architecture that is the substance of our SaMD regulatory strategy advisory — getting the software safety classification right, and the architecture that follows from it, while those decisions are still reversible.