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: §820.30(f) Design verification.
Requirement text
The manufacturer must establish and perform a set of tests, expressed as input stimuli, expected outcomes, pass/fail criteria and procedures, for conducting software system testing, such that all software requirements are covered. The manufacturer must verify that all software requirements have been tested or otherwise verified, that the traceability between software requirements and tests or other verification is recorded, and that test results meet the required pass/fail criteria. When changes are made during software system testing, the manufacturer must repeat tests, perform modified tests or perform additional tests, as appropriate, to verify the effectiveness of the change in correcting the problem, conduct testing appropriate to demonstrate that unintended side effects have not been introduced, and perform relevant risk management activities as defined in 7.4.
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) introduced a new compliance path for legacy software (Clause 4.4), allowing previously released software to meet requirements through post-market data and risk management rather than full retrospective documentation.
In Clause 4.3, Amendment 1 struck the 2006 sentence "The software safety classes shall initially be assigned based on severity as follows" and its three severity-based class definitions, and inserted class definitions that depend on whether the software system can contribute to a hazardous situation which results in unacceptable risk after consideration of risk control measures external to the software system, with the resulting possible harm being non-serious injury (Class B) or death or serious injury (Class C). Figure 3 states that the probability of a software failure shall be assumed to be 1 and that only risk control measures not implemented within (external to) the software system shall be considered. The 2006 text already allowed a hardware risk control measure to reduce the class (from C to B, and from B to A); Amendment 1 inserted a NOTE 1 stating that external risk control measures can be hardware, an independent software system, health care procedures, or other means. Amendment 1 also inserted a NOTE to clause 5.3.5 (Identify segregation necessary for risk control) that ends: "Other means of segregation can be applied when effectiveness can be ensured by the software ARCHITECTURE design (see B.4.3)."
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 identification and avoidance of common software defects (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.