IEC 62304 for startups, what Class A actually requires (most guides get this wrong)

If your software is a medical device, IEC 62304 is the standard that governs how you build it. Not what your product does, but how your development process works: planning, requirements, testing, release, maintenance, and how you handle the third-party code you depend on.

Founders tend to meet IEC 62304 in one of two moods: panic, because it sounds like aerospace-grade process for a three-person team, or complacency, because someone said "you're only Class A, that's basically nothing." Both moods are wrong, and the second one is more dangerous, because it fails audits.

The three classes, in one paragraph

IEC 62304 assigns your software a safety class based on the worst thing that could happen if it fails. Class A: no injury possible. Class B: non-serious injury possible. Class C: death or serious injury possible. Severity decides the class; how likely failure is does not matter, the standard treats failure as something that will happen. One nuance worth knowing: if a risk control measure outside your software, like a clinician who reviews output before it reaches a patient, genuinely reduces the consequence of failure, a higher class can reduce, but that safety net has to be documented as a risk control and verified, not just asserted.

What Class A actually requires

Here is where most summaries are out of date. Since Amendment 1 (2015), Class A is not the "documentation optional" tier some older guides describe. For Class A software you need, at minimum:

A software development plan, showing you develop deliberately rather than accidentally. Software requirements, documented and testable. Unit implementation, meaning the code itself is written under your plan (clause 5.5.1 applies to Class A, a detail widely missed). Software system testing, and this is the one that surprises people: clause 5.7 applies to Class A, B, and C after Amendment 1. Tests covering your software requirements, with records. A guide that tells you Class A needs no testing evidence is describing the 2006 edition. Release records identifying exactly what version went out and the known anomalies in it. A SOUP register listing your third-party dependencies (Software Of Unknown Provenance): name, version, what you use it for. Configuration management and problem resolution, meaning version control plus a genuine bug process with records. And a maintenance plan for how changes come in after release.

What Class A spares you: architecture documentation, unit verification, and integration testing only become requirements at Class B, and detailed design documentation largely at Class C.

If you read that list and thought "that is roughly what a disciplined software team does anyway, plus writing it down", you have understood IEC 62304. The standard mostly formalises competence.

The parts startups actually get wrong

The SOUP register. Modern software is mostly dependencies, and your package.json is not a register. Each meaningful dependency needs its version, its role, and at higher classes an eye on its published anomalies. Auditors love this one because it is objective: either the register exists and matches your lockfile or it does not.

Traceability. Requirement to test to result. When a requirement changes, something shows which tests are now stale. A gap here is the most common finding in software audits, and it is also the most automatable problem in the whole standard.

Classifying by hope. Deciding you are Class A because Class A is cheaper is backwards. Classify from worst-case harm, honestly, and document the reasoning. Our classifier walks the logic in five minutes and shows you which conclusions come from the rules and which are judgement calls to confirm with a specialist.

Treating it as separate from ISO 13485. IEC 62304 assumes a quality system around it and a risk process (ISO 14971) feeding it. It is one leg of a tripod, and it is much easier to stand up as part of one system than as a standalone project. Our SaMD compliance guide shows how the three fit together.

The honest effort estimate

For a Class A product built by a team that already writes tests and uses version control, IEC 62304 compliance is weeks of structured effort, not months: a development plan SOP, requirements with acceptance criteria, a populated SOUP register, system test records tied to requirements, and release discipline. The evidence layer, not a new way of building software.

That is exactly the layer QualiHQ generates as you work, requirements, test runs, SOUP, releases, traced throughout. But whichever tooling you choose, start from the real requirements above, not from a summary written before the amendment changed them. Your future auditor has read the current edition. You should be building against it.