The international standard for medical device software — what it actually requires, what it doesn't, and how to achieve compliance efficiently.
IEC 62304 is the international standard governing software lifecycle processes for medical devices. If you're building a software-based medical device for the US, EU, or most regulated markets, you'll need to comply with it. Here's what it actually means in practice.
Published by the International Electrotechnical Commission, IEC 62304:2006 (amended 2015) defines the lifecycle requirements for medical device software — from planning and requirements through architecture, implementation, verification, maintenance, and problem resolution.
The FDA formally recognises IEC 62304 in its 510(k) guidance, and the EU MDR/IVDR regulations reference it under harmonised standards. In practice: if you're submitting a 510(k) or a CE-marked device, IEC 62304 compliance is expected.
IEC 62304 doesn't tell you how to write software. It tells you what processes, documents, and records must exist. It's a process standard, not a technical standard. Agile, waterfall, or hybrid — all are compatible with 62304 compliance.
Everything in IEC 62304 depends on the software safety class of your device. The class is determined by what happens if the software fails:
| Class | Worst-case failure consequence | Typical devices |
|---|---|---|
| Class A | No injury or damage to health possible | Fitness trackers, wellness apps, administrative software |
| Class B | Non-serious injury possible | Diagnostic imaging, monitoring software, drug calculators (with override) |
| Class C | Death or serious injury possible | Infusion pump controllers, radiation therapy software, ventilator software, surgical robotics |
Most startup medical devices fall into Class B or C. If your software makes clinical decisions, controls treatment delivery, or interprets safety-critical sensor data — assume Class C until your hazard analysis says otherwise.
Common mistake: Classifying your software as Class A to reduce documentation burden, without actually performing the hazard analysis. Regulators look at this carefully. Classification without a supporting hazard analysis is a red flag.
IEC 62304 defines these mandatory processes:
Before you write code, document how you will develop software. This is your Software Development Plan. It doesn't have to be a 50-page document — a clear description of your lifecycle model, tools, team roles, and how you'll handle deviations is enough.
Define what the software shall do. Every requirement must be testable. Safety requirements must be marked as such. This produces your Software Requirements Specification (SRS).
For Class C, requirements must also trace to risk controls in your risk management file.
Class B and C require a documented software architecture — how the system is decomposed into modules. For Class C, each module must be assigned a safety class individually (a Class C system can contain Class A modules).
Class C only — detailed design for each software unit. Think interface definitions, algorithm descriptions, data structures. Not necessarily a line-by-line spec, but enough that the design is auditable.
Writing and testing individual units. For Class C, each unit must be verified (unit testing). Code reviews count — the standard doesn't mandate automated unit tests, though they're strongly advisable.
Integrating units and testing the integrated system. Must be documented. Your SSTC (System/Software Test Cases) document is the evidence.
Testing the complete system against all software requirements. Every requirement must be tested. This is your formal V&V (Verification and Validation) evidence.
Formally releasing a version includes: confirming all activities are complete, all anomalies resolved or risk-accepted, all documentation updated, and a version label applied to the exact build being released.
After release, any software changes — bug fixes, feature additions — must go through change control. Each change gets classified, assessed for impact, and re-verified proportionally. A typo fix in error message text isn't the same as changing a dosing algorithm.
Your anomaly (bug) tracking process. Problems must be reported, evaluated, and resolved (or risk-accepted). This feeds your Anomaly List — a required output of the 62304 process.
Mapping the required records to common document types:
| Document | Class A | Class B | Class C |
|---|---|---|---|
| Software Development Plan | ✓ | ✓ | ✓ |
| Software Requirements Spec (SRS) | ✓ | ✓ | ✓ |
| Software Architecture | – | ✓ | ✓ |
| Detailed Design | – | – | ✓ |
| Unit Test Records | – | – | ✓ |
| Integration Test Records (SSTC) | – | ✓ | ✓ |
| System Test Records (SSTP) | ✓ | ✓ | ✓ |
| Traceability Matrix | – | ✓ | ✓ |
| Anomaly List | ✓ | ✓ | ✓ |
| Version History | ✓ | ✓ | ✓ |
IEC 62304 doesn't stand alone — it explicitly references ISO 14971, the risk management standard for medical devices. Software risk controls defined in your ISO 14971 risk management file must trace to specific software requirements in your SRS, which in turn trace to test cases.
This is the full chain regulators look for: Hazard → Risk Control → SRS Requirement → Test Case → Test Evidence. A gap anywhere in this chain is a finding.
For a startup with existing software that wasn't developed under IEC 62304: typically 3–6 months to close the gaps, depending on team size and how much documentation already exists. The most common gaps are:
"IEC 62304 compliance is mostly a documentation discipline problem, not an engineering problem. Most medical device startups are already doing the right things technically — they just haven't written it down in the right format." — Regulatory consultant perspective
SRS, SSTC, and traceability matrix built around the 62304 lifecycle — not adapted from generic project management tools.
Book a 30-minute demo