IEC 62304 is the international standard for medical device software lifecycle. The first thing teams new to it usually do is treat it like a compliance checklist. The first thing they discover is that 62304 isn't a checklist — it's a process. And the process has structural requirements that don't fit easily into a typical engineering workflow.
After running IEC 62304-aligned SDLCs on a dozen SaMD projects, here's what the standard actually requires, and the three things teams consistently underestimate.
What IEC 62304 isn't
It isn't a test coverage target. It doesn't say "80% line coverage."
It isn't a tooling spec. It doesn't say "use this framework."
It isn't a security standard. (That's IEC 81001-5-1 and FDA cybersecurity guidance — closely related but separate.)
What 62304 actually requires is a documented software lifecycle, with traceability between user needs, software requirements, software design, implementation, and verification. The standard cares about whether you can show the chain — not whether you used a particular tool or hit a particular metric.
Software safety classification (Class A / B / C)
Before writing a line of code, you classify your software.
- Class A — no injury or damage to health possible. Lowest documentation burden.
- Class B — non-serious injury possible. Moderate documentation; most SaMD lives here.
- Class C — death or serious injury possible. Highest burden; full unit-level testing and detailed design documentation required.
The classification flows from ISO 14971 risk analysis, not from the developer's intuition. We've seen teams classify themselves as Class A to dodge documentation overhead, then have to redo months of work after the risk analysis flagged a hazard. Do the risk analysis first.
The traceability chain
This is the single most important concept in 62304. Every test must trace to a requirement. Every requirement must trace to a user need. Every implementation decision must trace to a requirement.
In practice, this means maintaining a traceability matrix that connects:
- User needs (e.g., "the device shall measure blood pressure within ±3 mmHg")
- Software requirements (e.g., "BP measurement subsystem produces readings with ±2 mmHg measurement accuracy")
- Software architecture (e.g., "BP subsystem implemented in module bp.cpp")
- Tests (e.g., "test_bp_accuracy.cpp validates ±2 mmHg requirement")
- Verification results (e.g., "test passed on build 1.4.2-rc3")
Auditors will pick a random test and trace it back to user needs. Then pick a random user need and trace it forward to tests. If the chain is broken anywhere, it's a finding.
Where 62304 differs from typical SDLCs
Most engineering teams already have something resembling tests and requirements. 62304 differs in three specific structural ways:
First: change control is mandatory. Every change to released software requires a documented change request, impact analysis on the traceability matrix, and verification that the change didn't break unrelated requirements. "Just push the fix" is a 62304 violation.
Second: problem resolution is process-driven. Bugs found in fielded software flow through a defined problem resolution process: report → assessment → severity classification → impact analysis → resolution → verification → release notes. Not Jira tickets and a hope.
Third: SOUP (Software of Unknown Provenance) handling. Every third-party library is SOUP unless you can show it was developed under 62304. You have to document each dependency, its version, its known anomalies, and your strategy for monitoring it. This means an SBOM is mandatory — not optional.
The three things most teams underestimate
First: documentation can't be back-filled. We've watched teams attempt this — ship the code, then write the requirements and traceability matrix from the code. The problem is that engineering teams have already made hundreds of implicit decisions that aren't requirements. Re-documenting them after the fact misses the actual decisions and gets caught by auditors.
Second: the unit testing requirement for Class B is more rigorous than people think. "Unit tests" in 62304 means tests that cover requirements at the unit level — not tests that cover code paths. A test that hits 100% of branches but doesn't trace to a requirement doesn't count. We've seen teams with extensive test suites fail audits because the tests weren't requirement-driven.
Third: configuration management is part of 62304, not separate. Your version control, build system, and release management practices have to be documented and auditable. "We use git" isn't enough — you need branch policies, release tagging, and build reproducibility documented.
The standard doesn't tell you to write good software. It tells you to write the trail that shows you wrote it on purpose.
What auditors actually check
In our last six audits, the artifacts auditors actually pulled were consistent:
- Traceability matrix (always, first thing)
- Random test → requirement → user need walk-back (always)
- Random user need → requirement → test → result walk-forward (always)
- SOUP inventory and known anomalies list (always)
- Last 3 change requests with impact analysis (typical)
- Last 3 problem reports with resolution path (typical)
- Build reproducibility — can they get the same binary from the same commit? (typical)
Notice what's not on the list: code style, test coverage percentage, framework choices. Auditors aren't testing engineering quality. They're testing whether the process is real and operational.
Starting from scratch vs. patching an existing codebase
If you're starting a new SaMD project, build 62304 in from day one. The cost is moderate when integrated; brutal when retrofitted. Most of the work is structural — once the traceability matrix exists and the change control process runs, the per-feature overhead is maybe 20-30%.
If you're retrofitting an existing codebase, the question is whether the architecture supports requirement-level testing. If the code is structured around features that map to user needs, you can usually retrofit. If the code is structured around technical layers ("the database module," "the UI module"), retrofit is harder because the unit tests don't naturally map to requirements.
We've retrofitted Class B codebases in 8-12 weeks. We've also rebuilt codebases in 6-8 weeks because the retrofit cost exceeded the rebuild cost. There's no general answer — it depends on the code.
Closing
IEC 62304 isn't about engineering quality. It's about engineering legibility — the ability for a third party to walk through your software, ask why every piece is there, and get a documented answer that traces all the way back to a user need.
Once you internalize that, the rest of the standard makes sense. The change control isn't bureaucracy — it's keeping the legibility intact under turnover. The SOUP inventory isn't paperwork — it's the only way to know if a library you depend on has a known issue. The traceability matrix isn't a chore — it's the document an auditor will read in the first hour.
Build the trail on purpose. Don't try to back-fill it.