IEC 62304 software testing is the part of the standard that proves your medical device software does what its requirements say, at the level of rigour its safety class demands. The standard defines the software lifecycle for medical device software, and how much planning, design and verification you must document depends on the harm the software could contribute to.
For HealthTech teams, the practical question is not “what does the standard say?” but “what evidence will an auditor expect to see, and where do we get it?”
What IEC 62304 is, and what it isn’t?
IEC 62304 sets out lifecycle processes for developing and maintaining medical device software. It covers development planning, requirements, architecture, implementation, verification, release, maintenance, risk management, configuration management and problem resolution.
Three things are worth being clear about:
- It is a process standard. It tells you which activities and records you need. It does not prescribe tools, languages or a specific test technique.
- It works alongside other standards. It sits with your quality management system (typically ISO 13485) and risk management (ISO 14971). Software risk is managed within that wider system.
- It is not the whole of compliance. Regulatory approval, clinical evaluation, cybersecurity and usability sit in other requirements. For UK, EU and US market access, check which edition and which designated or recognised standards list your regulator currently applies.
The version in force today is IEC 62304:2006 with Amendment 1:2015, often called Edition 1.1.
The safety classes: the decision that drives everything.
Every software item is assigned a safety class. Under Amendment 1, the classes are based on the severity of harm the software could contribute to, after risk controls outside the software are taken into account:
- Class A: the software cannot contribute to a hazardous situation, or the risk is acceptable through controls outside the software. No injury is expected.
- Class B: the software can contribute to a hazardous situation, but the resulting harm is not serious.
- Class C: the software can contribute to a hazardous situation where death or serious injury is possible.
Two points catch teams out:
- Classification is by severity, not probability. You cannot move from Class C to Class B by arguing that failure is unlikely.
- The highest class applies unless you justify otherwise. The whole system takes the highest class among its components, unless you can show components are independent, for example through weak coupling in the architecture. If you don’t classify at all, the standard treats the software as Class C.
Get the classification and its rationale documented early. Everything downstream, including your test plan, follows from it.
What each class means for your process?
As a working summary of the amended standard:
- Class A requires the core activities: development planning, requirements analysis, system testing, release, maintenance, configuration management and problem resolution.
- Class B adds architectural design and integration testing, with verification of the software documented.
- Class C adds detailed design and unit-level implementation and verification.
System testing is required for every class since Amendment 1. Always read the current text of the standard for the exact clause requirements, as this summary is a guide, not a substitute.
IEC 62304 software testing: what to prepare.
Testing evidence is where audits are often won or lost. Plan for these areas.
Requirements-based system testing. Each software requirement needs at least one test, and each test needs to trace back to a requirement. This traceability matrix is usually the first thing an assessor asks for. Tests should cover normal use, boundary values, error handling and the risk controls implemented in software.
Integration testing. For Class B and C, show that software items work together as designed, including interfaces and data exchange. Record the strategy, the cases, the results and any anomalies.
Unit verification (Class C, and as justified for B). Define acceptance criteria for units and show they were met. The standard does not set a coverage percentage, so agree and document your own criteria and the reasoning behind them.
Risk control verification. Every software-based risk control from your risk analysis needs a test showing it works. A control that exists in the risk file but was never tested is a finding waiting to happen.
Regression testing on change. The maintenance and problem-resolution processes mean every change needs an impact assessment and appropriate retesting. A regression suite you can rerun, with results tied to the release, is far easier to defend than manual re-checking.
SOUP. Software of unknown provenance, such as open-source libraries and third-party components, must be identified, with its requirements and known anomalies assessed. Testing should cover the way your product uses it, not just that it installs.
Our IoT testing work is relevant here for connected devices, where hardware, firmware and cloud software all affect the evidence.
Where HealthTech teams struggle?
- Classifying late, or too loosely. The class is set to be convenient rather than justified.
- Traceability built after the fact. Rebuilding requirement-to-test links before an audit is slow and error-prone.
- Untested risk controls. Mitigations are written down but never verified.
- Weak SOUP records. Libraries are listed without anomaly assessment.
- Treating releases as one-offs. Evidence is not versioned against each release, so it goes stale.
What is changing: Edition 2
The standard is being revised. As of the latest information we found, Edition 2 is still in draft and publication is not expected before 2028, so IEC 62304:2015 remains the version to work to. Drafts under discussion would broaden the scope towards “health software”, add security requirements and revisit the A, B and C classes. The draft content may change, so follow your national standards body for the current position before changing your process.
The practical starting point
If you are preparing for a regulatory submission or audit, begin with a gap review. List every software item, confirm its safety class and rationale, and check whether each requirement, each risk control and each integration point has current test evidence. Fix traceability and risk-control gaps first, then integration and unit evidence, then SOUP records.
Finding those gaps in your own review costs a fraction of finding them in a notified body audit. Explore the wider solutions we provide for HealthTech and other regulated teams.
Preparing medical device software for audit? We help HealthTech teams build the test evidence the standard expects. Get in touch.