System test plan, requirement-to-test traceability, recorded test results, and regression testing after changes — standard V&V structure.
Risk control measures in software require explicit test cases; residual anomalies must be safety-evaluated and documented before release.
Traceability matrix from requirements to test cases — and evidence that risk-control requirements have corresponding, executed test results.
Maps to
IEC 62304: §5.7 Software system testing
ISO 13485: §7.3.6 Design and development verification
Pre-QMSR Part 820 (legacy QSR): §820.30(f) Design verification.
Requirement text
The manufacturer shall test the integrated software system against software requirements using a documented test plan. Tests must cover all software requirements and risk control measures. Test results must be recorded, and changes must trigger regression testing.
Why this clause exists
System testing is the verification step where the claim that all software requirements have been implemented is tested as a whole rather than inferred from the sum of unit verifications. The two activities are not interchangeable: unit verification confirms that each software unit behaves correctly in isolation, but it cannot detect integration defects — data format mismatches between components, timing dependencies, resource contention, and the emergent behaviors that arise when software items interact in ways their individual designs do not reveal. IEC 62304:2006+A1:2015 clause 5.7 mandates that the test plan exist before testing begins and that it be complete enough to demonstrate coverage of all software requirements, because a test plan written retrospectively to match the tests that were actually executed cannot provide evidence that untested requirements exist — it can only confirm that the requirements someone chose to test were tested. The requirement to explicitly test risk control measures implemented in software is logically necessary: a control that is coded but untested may be disabled by a compiler optimization, overridden by a configuration flag, or silently broken by a subsequent code change without the defect surfacing in any routine test, leaving the risk management file claiming a control is in place while the shipped software does not implement it.
What changed
Amendment 1 (2015) expanded the scope to explicitly include health software and Software as a Medical Device (SaMD), not just software embedded in physical medical devices. A new compliance path for legacy software (Clause 4.4) was introduced, allowing previously released software to meet requirements through post-market data and risk management rather than full retrospective documentation.
The software safety classification criteria (Clause 4.3) shifted from severity-only to include probability of hazardous situations. External risk control measures (hardware or clinical procedures) can now reduce the software safety class, but internal software mitigations cannot. The standard clarified that logical segregation (not just physical) is acceptable for classification purposes.
The definition of SOUP was narrowed to apply only to software items — a complete medical device software system cannot be claimed as SOUP to bypass lifecycle requirements. New requirements were added for publishing known defects with risk assessments (5.1.12), IT security and networking considerations (5.2.2), and Class A software received additional testing, release, and monitoring requirements.
Common gaps (what we see in audits)
- Incomplete system test coverage for non-code requirements — Not all software requirements are covered by system tests. Requirements like firewall configuration, infrastructure setup, and environment-specific behaviors have no corresponding code changes and cannot be verified through CI pipelines alone — they need formal system-level test evidence such as screenshots or configuration audits.
- Confusion between software verification and validation — Software verification ('are we building the product right?') is within IEC 62304's scope, while software validation ('are we building the right product?') falls under IEC 82304-1 and FDA's broader expectations. Teams conflate these concepts, sometimes performing only validation activities and claiming IEC 62304 compliance, or vice versa.
- Unit test definition mismatch with regulatory expectations — For developers, unit tests test granular methods and classes. For regulators, 'software unit' tests must test the software units as defined in the architecture, which may represent larger functional components. This terminology mismatch leads to gaps where regulatory-level testing is assumed complete when engineering tests cover different granularity.