Maps to
QMSR / ISO 13485: §820.30(f)
ISO 13485: §7.3.6
IEC 62304: §5.7
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.
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.
Atomic constraints
- •Required for all software safety classes (A, B, and C)
- •A software system test plan must exist and be approved before system testing begins.
- •Test cases must trace to software requirements, ensuring all requirements have at least one test.
- •Risk control measures implemented in software must be explicitly tested.
- •Test results must be recorded in a test protocol or report.
- •Anomalies discovered during testing must be resolved or documented as known residual anomalies.
- •Software changes after testing must trigger regression testing of affected areas.
Common gaps
Incomplete system test coverage for non-code requirements
majorNot 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
moderateSoftware 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
moderateFor 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.
Evidence signals
- •
FILE_EXISTS
System.*Test.*Plan|Software.*Test.*Plan|Test.*Protocol|Test.*Report|V.*V.*Plan
- •
CONTENT_MATCH
Does this document define software system test cases with traceability to software requirements, include test execution results, and cover testing of software-implemented risk control measures?
Audit defense
The Software System Test Plan and Protocol for [your product] (Doc ID: [your document ID]) document all test cases with traceability to software requirements and risk control measures. Test execution results are recorded in the Test Protocol, and regression tests run automatically via CI/CD on every code change.