Why IEC 62304 matters — and what happens when you get it wrong
IEC 62304 is the international standard for medical device software lifecycle processes. It is harmonised under EU MDR, referenced in Singapore HSA guidance, and expected by the FDA. When a Notified Body reviews your SaMD technical file, they look at your IEC 62304 compliance evidence before almost anything else. It is the structural foundation of your entire software documentation.
Getting the software safety classification wrong — or claiming IEC 62304 compliance without the documentation evidence to back it up — is one of the most common and costly mistakes SaMD companies make. It generates major non-conformities that stop NB review and add months to your certification timeline.
Software safety classification: Class A, B, C explained
The first and most important step is classifying your software under IEC 62304's three-tier system. This classification drives the level of rigour required across your entire development lifecycle.
Class A — no injury or negligible injury
Class A software is software whose failure cannot contribute to a hazardous situation, or whose failure can contribute to a hazardous situation from which no injury or negligible injury results. Examples: administrative functions, data display software where the raw data is independently verified by the clinician before clinical decisions are made.
Class A has the lightest requirements under IEC 62304 — but it is also the most commonly misclassified. Many SaMD teams classify their software as Class A to reduce documentation burden, then discover during NB review that the intended use actually requires Class B or C.
Class B — non-serious injury
Class B software is software whose failure can contribute to a hazardous situation resulting in non-serious injury. Most clinical decision support software, monitoring applications, and diagnostic aids that influence clinical decisions but do not drive them autonomously fall into Class B.
Class B requires more rigorous testing, architecture documentation, and traceability than Class A — but less than Class C. It represents the majority of SaMD products in the market.
Class C — death or serious injury
Class C software is software whose failure can contribute to a hazardous situation resulting in death or serious injury. Autonomous diagnostic AI, treatment planning software, software controlling active devices, and software with direct patient dosing implications typically classify as Class C.
Class C requires the full weight of IEC 62304: detailed architecture documentation, unit-level testing with specific rigour requirements, complete bidirectional traceability from requirements through to test evidence, and formal software problem resolution processes.
Key IEC 62304 processes and what they require
Software development planning (Clause 5.1)
Before any development begins, IEC 62304 requires a Software Development Plan that defines: the software safety class and the rationale for the classification, the standards and processes to be followed, the deliverables at each development stage, the risk management approach specific to software, and the configuration management plan. This plan is not a formality — NBs read it and use it to evaluate whether your subsequent documentation is consistent with your stated processes.
Software requirements analysis (Clause 5.2)
Every intended use and functional requirement must be documented in a Software Requirements Specification. Requirements must be uniquely identified (numbered) and traceable — because IEC 62304 requires you to demonstrate that every requirement has been tested and verified. Requirements that are vague, duplicated, or unidentified cannot be traced, and your traceability matrix will have gaps that NB reviewers will flag.
Software architecture (Clause 5.3)
The software architecture document identifies the major software items (modules, components, subsystems), their interactions and interfaces, and the rationale for the architectural decisions. For Class B and C software, the architecture must address how hazardous software failures are mitigated at the design level. This is where cybersecurity design decisions (relevant since the 2015 amendment) should also be documented.
Unit implementation and testing (Clauses 5.5 and 5.6)
All software units must be tested at the unit level before integration. Testing must be documented — test plans, test cases, test results, and pass/fail criteria. For Class C software, unit testing must be sufficiently rigorous that failures would be detected. The standard does not mandate specific coverage metrics, but NBs reviewing Class C software will ask about your approach.
Software system testing (Clause 5.7)
System testing verifies that the integrated software meets its requirements. Test protocols must map test cases to requirements (the traceability matrix), document the test environment, record results, and document the disposition of any anomalies discovered during testing.
SOUP management (Clause 7)
SOUP — Software of Unknown Provenance — refers to third-party libraries, frameworks, and open-source components incorporated into your software. IEC 62304 requires you to document all SOUP items, assess their impact on software safety classification, and monitor them for known anomalies and security vulnerabilities. This is an area where many SaMD teams have significant gaps — particularly teams using multiple open-source libraries without a formal SOUP management process.
Implementing IEC 62304 in an Agile environment
The most common question we hear from SaMD development teams is: "We use Scrum — does IEC 62304 require us to switch to waterfall?" The answer is no. IEC 62304 specifies the what — the deliverables and processes — not the how. Here is how Agile teams can meet the standard without abandoning their workflow:
- Design inputs and outputs at the user story level: Treat acceptance criteria as design inputs; define outputs as the specific implementation that satisfies them. Design reviews can happen in sprint review ceremonies.
- Traceability in your existing tools: Jira, GitHub Issues, and Azure DevOps can all maintain the requirement-to-test traceability IEC 62304 requires. The key is consistent ID schemes and linking practices — not a separate spreadsheet.
- Change control at the release level: Software change control can operate at release or sprint boundary level. Every release is a documented, authorised change with test evidence attached — this is compatible with CI/CD pipelines.
- SOUP inventory as a living document: Maintain your SOUP list in your repository (a machine-readable SBOM is becoming best practice for this) and update it automatically on every dependency change.
