Written and maintained by CASRAI Editorial Board
Last updated
ISO 13485 software validation encompasses two distinct regulatory obligations within an ISO 13485:2016 medical device Quality Management System (QMS): first, the validation of non-product computer software used to operate the quality system itself (Clause 4.1.6) or to automate production, build, and service processes (Clause 7.5.6), guided internationally by ISO/TR 80002-2:2017; and second, the design verification and validation of product software that is itself a medical device (SaMD) or embedded in a medical device (SiMD) under Clause 7.3 (Design and Development) and IEC 62304. Because the U.S. Food and Drug Administration’s Quality Management System Regulation (QMSR, revising 21 CFR Part 820 effective February 2026) incorporates ISO 13485:2016 by reference, distinguishing these three clauses is essential for passing both Notified Body/MDSAP audits and FDA inspections.
What Does ISO 13485 Clause 4.1.6 (and ISO/TR 80002-2) Require for Validating QMS and Build-Pipeline Software?
Under ISO 13485:2016 Clause 4.1.6 (General requirements — Quality management system software) and Clause 7.5.6 (Validation of processes for production and service provision), an organization must document procedures for validating the application of computer software used in the QMS or in automated production/build pipelines prior to initial use and, as appropriate, after changes to such software or its application. Critically, both clauses establish that the specific approach and activities associated with software validation and revalidation shall be proportionate to the risk associated with the use of the software.
To prevent engineering teams from generating thousands of pages of screenshot-heavy Waterfall protocols for low-risk off-the-shelf tools, ISO/TR 80002-2:2017 (Medical device software — Part 2: Validation of software for medical device quality systems)—the international counterpart to the FDA Computer Software Assurance (CSA) guidance—provides a risk-based framework:
| ISO 13485:2016 Clause | Software Scope & Category | Primary Consensus Standard | Concrete Medical Software Toolchain Examples |
|---|---|---|---|
| Clause 4.1.6 (QMS Software) | Non-product software used to create, approve, store, or control QMS documents, CAPAs, complaints, training, and Design History File (DHF) records | ISO/TR 80002-2:2017 & FDA CSA Guidance (21 CFR § 820.70(i) / Part 11) | eQMS platforms (Greenlight Guru, MasterControl), ALM/requirements trackers (Jira, Jama, Polarion), and electronic signature portals (DocuSign Part 11) |
| Clause 7.5.6 (Production & Service Software) | Non-product software used in manufacturing, automated compilation, CI/CD packaging, automated test execution, and cloud deployment | ISO/TR 80002-2:2017 | Source control (Git / GitHub Enterprise / GitLab), CI/CD runners (GitHub Actions, Jenkins), compilers, Docker container builders, and pytest/JUnit harnesses |
| Clause 7.3 (Design & Development) | Product software (Software as a Medical Device [SaMD] or embedded firmware [SiMD]) intended for clinical use | IEC 62304:2006+A1:2015, IEC 82304-1, ISO 14971, and AAMI TIR45:2023 | Diagnostic AI inference engines, infusion pump firmware, patient monitoring mobile apps, and SOUP libraries linked into the binary |
How Do ISO 13485 Clause 7.3 Design Controls Integrate with IEC 62304 for SaMD Development?
While ISO 13485 Clause 7.3 defines the overarching medical device Design and Development lifecycle (Planning, Inputs, Outputs, Review, Verification, Validation, Transfer, and Change Control), it is written for all medical devices—from sterile catheters to MRI scanners. For a Software as a Medical Device (SaMD) manufacturer, IEC 62304 Clause 1.4 explicitly states that IEC 62304 relies on an underlying quality management system (such as ISO 13485) and maps directly into ISO 13485 Clause 7.3:
- Design and Development Planning (ISO 13485 § 7.3.2 ↔ IEC 62304 § 5.1): Fulfilled by the Software Development Plan (SDP), which defines the IEC 62304 Software Safety Classification (Class A, B, or C), lifecycle model, and configuration management plan.
- Design and Development Inputs (ISO 13485 § 7.3.3 ↔ IEC 62304 § 5.2): Fulfilled by the Software Requirements Specification (SRS), incorporating functional, performance, cybersecurity, usability (IEC 62366-1), and ISO 14971 risk-control requirements.
- Design and Development Outputs (ISO 13485 § 7.3.4 ↔ IEC 62304 §§ 5.3–5.5): Fulfilled by the Software Architecture Document, Detailed Design Specification (SDS), source code, and Software Bill of Materials (SBOM / SOUP list).
- Design Verification vs. Design Validation (ISO 13485 §§ 7.3.6–7.3.7 ↔ IEC 62304 §§ 5.6–5.8 & IEC 82304-1): IEC 62304 covers software verification (unit, integration, and system-level requirement testing proving “we built the software right”). However, IEC 62304 intentionally stops at software system testing; full Design Validation under ISO 13485 § 7.3.7 (proving “we built the right software” for clinical users under actual or simulated use conditions, aligned with IEC 82304-1 for standalone health software) remains a direct ISO 13485 Clause 7.3 deliverable.
How Do You Apply Risk-Based Critical Thinking to Validate CI/CD, Git, Jira, and Automated Testing Tools Under ISO/TR 80002-2?
Under ISO/TR 80002-2, validating modern DevSecOps toolchains (Git, Jira, and CI/CD pipelines) proceeds through a five-step Critical Thinking and Toolbox workflow rather than uniform heavyweight protocols:
- Define the Intended Use of the Tool in Your QMS: Document a concise Tool Intended Use Statement specifying exactly which QMS or build process the tool automates (e.g., “GitHub Enterprise is used under Clause 7.5.6 for source code version control, pull-request peer review enforcement, and immutable release tagging”).
- Perform a Process & Patient Risk Analysis (ISO/TR 80002-2 Clause 5): Evaluate two dimensions: (a) how severely a tool failure could impact medical device safety or QMS record integrity, and (b) whether downstream human review or automated hash checks would immediately detect the tool failure before release. For example, an IDE syntax highlighter has negligible risk because compiler and unit tests catch syntax errors downstream, whereas an automated unit-test runner that silently reports “PASS” on a failed safety test has high process risk.
- Select Validation Activities from the ISO/TR 80002-2 “Toolbox”: Match the risk level to proportionate activities from the standard’s toolbox—including vendor assessment (reviewing Atlassian or GitHub SOC 2 Type 2 / ISO 27001 reports), configuration verification, and targeted testing:
- Validating Git (Source Control): Verify and capture objective evidence that branch protection rules are active on
main/release/*, direct pushes without an approved Pull Request are blocked, commit history rewriting (force-push) is disabled, and role-based access control (RBAC) is enforced. - Validating Jira / ALM (Requirements & Traceability): Verify custom issue workflows (ensuring a Software Requirement or CAPA cannot transition to “Approved” without required QA sign-off fields), audit log permanence, and accuracy of the exported Traceability Matrix query.
- Validating CI/CD & Automated Test Runners: Execute a positive and negative “golden test” (intentionally injecting a failing unit test and a linting error into a test branch) to prove that the CI pipeline deterministically halts the build and blocks artifact promotion when a test fails.
- Validating Git (Source Control): Verify and capture objective evidence that branch protection rules are active on
- Maintain Configuration Baselines and Change Control: Store CI/CD pipeline definitions as version-controlled code (e.g.,
.github/workflows/orJenkinsfile) subject to the same pull-request review as product code, and review SaaS vendor release notes periodically to assess whether updates impact your validated configuration.
Frequently Asked Questions
What does ISO 13485 Clause 4.1.6 (and ISO/TR 80002-2) require for validating QMS and build-pipeline software?
ISO 13485 Clause 4.1.6 (for QMS software) and Clause 7.5.6 (for production and build software), supported by ISO/TR 80002-2, require medical device organizations to validate non-product software prior to initial use and after changes using a risk-based approach proportionate to the software’s impact on device safety and QMS record integrity.
How do ISO 13485 Clause 7.3 Design Controls integrate with IEC 62304 for SaMD development?
ISO 13485 Clause 7.3 establishes the overarching Design History File (DHF) framework (Planning, Inputs, Outputs, Verification, Validation, Transfer, and Changes), while IEC 62304 provides the software-specific engineering processes that fulfill Clause 7.3 through Design Verification, leaving clinical and usability Design Validation to ISO 13485 § 7.3.7 and IEC 82304-1.
How do you apply risk-based critical thinking to validate CI/CD, Git, Jira, and automated testing tools under ISO/TR 80002-2?
Under ISO/TR 80002-2, teams document each tool’s intended use, assess failure risk and downstream detectability, leverage vendor SOC 2/ISO 27001 certifications, verify security configurations (such as Git branch protections and Jira approval gates), and run targeted negative tests proving that CI/CD test runners deterministically fail when a defective build is introduced.
