FDA CSA Guidance: Computer Software Assurance, GPSV, and OTS Software in Medical Devices

The FDA Computer Software Assurance (CSA) guidance—formally titled Computer Software Assurance for Production and Quality System Software—is the U.S. Food and Drug Administration’s risk-based regulatory framework governing how medical device manufacturers validate non-product software used in manufacturing operations and quality management systems (QMS). However, regulatory affairs teams and biomedical engineers frequently encounter three distinct FDA software guidance documents that govern different parts of the medical device ecosystem: the CSA guidance (for production and QMS software), the 2002 General Principles of Software Validation (GPSV) (for foundational software lifecycle validation), and the August 2023 Off-The-Shelf (OTS) Software Use in Medical Devices guidance (for third-party software components embedded inside a medical device itself).

Confusing these three frameworks leads to two common compliance failures: applying heavyweight product-level premarket verification to low-risk enterprise QMS ticketing tools, or conversely attempting to use informal CSA unscripted testing for embedded medical device firmware. This guide clarifies the regulatory scope, risk classification rules, and documentation deliverables for all three FDA software validation frameworks.

Regulatory Boundary: CSA vs. GPSV vs. OTS Software Guidance

Before selecting a validation methodology, quality and regulatory teams must determine whether the software under evaluation is product software (Software in a Medical Device [SiMD] or Software as a Medical Device [SaMD]) or non-product software used to automate production or quality system workflows under 21 CFR § 820.70(i) and the FDA Quality Management System Regulation (QMSR, which incorporates ISO 13485:2016 Clauses 4.1.6 and 7.5.6).

FDA Guidance Document	Target Software Scope	Regulatory Hook & Lifecycle Standard	Primary Assurance / Submission Mechanism
Computer Software Assurance (CSA) for Production and Quality System Software	Non-product software used in device manufacturing or the QMS (e.g., eQMS, MES, LIMS, ERP, automated test fixtures, bug trackers).	21 CFR § 820.70(i) / QMSR (ISO 13485 Clauses 4.1.6 & 7.5.6); supersedes Section 6 of GPSV; aligns with GAMP 5 (Second Edition).	Feature-level process risk assessment, vendor assurance leveraging, unscripted vs. scripted testing, streamlined audit records (inspected during FDA QMS audits).
General Principles of Software Validation (GPSV, Jan 2002)	Foundational lifecycle validation principles for medical device software (SiMD/SaMD); Section 6 superseded by CSA.	21 CFR § 820.30 (Design Controls) / QMSR (ISO 13485 Clause 7.3) and IEC 62304.	Requirements-to-test traceability matrix, structural/unit/integration/system verification, configuration management, and defect resolution.
Off-The-Shelf (OTS) Software Use in Medical Devices (Aug 2023)	Third-party software components incorporated into a medical device (e.g., embedded OS, SQLite/RDBMS, TLS libraries, third-party GUI frameworks; IEC 62304 SOUP).	Premarket submissions (510(k), De Novo, PMA) aligned with the 2023 FDA Content of Premarket Submissions for Device Software Functions guidance.	Basic vs. Enhanced Documentation Level deliverables: OTS version identification, hazard mitigation, black-box V&V testing, and cybersecurity/obsolescence plans.

The FDA Computer Software Assurance (CSA) Four-Step Framework

Historically, many medical device companies interpreted Section 6 of the 2002 GPSV guidance through rigid Computer System Validation (CSV) practices that generated thousands of pages of step-by-step screenshot test scripts for commercial off-the-shelf enterprise software (such as document control portals or training trackers). The FDA CSA guidance replaces Section 6 of GPSV with a four-step critical-thinking workflow designed to focus testing effort on features that directly impact patient safety or product quality:

Step 1: Identify the Intended Use at the Feature Level

Rather than treating an entire software platform (such as an enterprise ERP or Laboratory Information Management System) as a single monolithic high-risk system, CSA instructs manufacturers to decompose the software into individual features, functions, or operations. First, the team determines whether the software is used as part of production or the quality system at all (for example, general office email or accounting spreadsheets that do not control quality records are out of scope). Second, within an in-scope system, each functional workflow is evaluated separately according to its specific role in manufacturing or quality compliance.

Step 2: Determine the Risk-Based Approach (High Process Risk vs. Not High Process Risk)

Under CSA, the manufacturer evaluates process risk—whether a failure of the software feature to perform as intended poses a foreseeable medical device hazard (compromising patient or user safety) that is not detected or controlled by downstream inspection or independent verification prior to device release:

• High Process Risk (Direct Patient/Quality Impact): A software function whose failure could foreseeably compromise safety—for example, CNC toolpath control software that machines an implantable orthopedic component without subsequent 100% dimensional inspection, automated laser-welding parameter control, or an automated release rule in an MES that approves sterilization lots for distribution.
• Not High Process Risk (Indirect or Mitigated Quality Impact): A software function that either fails to compromise safety because downstream human review or physical testing catches errors, or that purely manages administrative QMS processes—such as CAPA workflow routing, training record notifications, calibration scheduling alerts (distinct from physical equipment qualification vs. validation vs. calibration), or automated document numbering.

Step 3: Determine the Appropriate Assurance Activities (Scripted vs. Unscripted Testing)

CSA matches the testing methodology to the process risk identified in Step 2, explicitly encouraging manufacturers to leverage vendor quality assessments (such as ISO 9001 or SOC 2 certifications), automated continuous integration telemetry, and unscripted testing:

• Scripted Testing (for High Process Risk): Uses predetermined step-by-step test procedures and expected results. CSA distinguishes between Robust Scripted Testing (including repeatability, negative/boundary testing, and independent review for highest-risk functions) and Limited Scripted Testing (step-by-step verification of high-risk steps combined with unscripted exploration of surrounding steps).
• Unscripted Testing (for Not High Process Risk): Uses test objectives without rigid step-by-step scripts, relying on tester domain expertise to actively probe the software. Unscripted methods include Error-Guessing (targeting likely failure modes or edge-case inputs), Exploratory Testing (simultaneous learning, test design, and execution guided by a test charter), and Ad-Hoc Testing (confirming basic intended functionality).

Step 4: Establish the Appropriate Assurance Record

For unscripted and lower-risk testing, FDA CSA explicitly states that step-by-step screenshot evidence is unnecessary and adds no quality value. Instead, a compliant CSA assurance record need only capture:

1. The intended use of the software feature, function, or operation;
2. The risk determination (high process risk vs. not high process risk);
3. Documentation of the assurance activities performed: the test objective, a brief description of how testing was conducted, the high-level test results (Pass/Fail), any issues or defects found and their disposition, the testing date, and the identity/signature of the tester;
4. Formal review and approval signatures when required by the manufacturer’s QMS procedures.

Off-The-Shelf (OTS) Software Use in Medical Devices (August 2023 Guidance)

When third-party software is packaged inside a regulated medical device (for example, an embedded Linux kernel on an infusion pump, a commercial Bluetooth stack in a wearable ECG patch, or an open-source deep learning inference library in a diagnostic SaMD), the CSA guidance does not apply. Instead, manufacturers must follow the August 2023 final guidance Off-The-Shelf Software Use in Medical Devices (which maps to IEC 62304 requirements for SOUP — Software of Unknown Provenance).

Because the medical device manufacturer does not possess the complete internal source code or design history file of the OTS vendor, the August 2023 guidance harmonizes premarket OTS documentation with the FDA’s two-tier risk framework (Basic Documentation Level vs. Enhanced Documentation Level, where Enhanced applies if a software failure could result in death or serious injury prior to risk control mitigations):

• Basic OTS Documentation (Required for Both Basic and Enhanced Levels): Exact identification of the OTS component (title, vendor, version, release date, and patch configuration); what the OTS software does within the device architecture; hardware/system specifications; a documented hazard analysis of potential OTS failure modes and corresponding risk controls; and verification/validation test summaries demonstrating that the OTS component functions safely within the integrated medical device.
• Additional Deliverables for Enhanced Documentation Level: When a device falls into the Enhanced tier, the premarket submission must also explain how the manufacturer assures the quality of the OTS vendor’s development methodology (or justifies alternative design controls) and describe how known OTS software anomalies, errata, and cybersecurity vulnerabilities are tracked and mitigated.

Frequently Asked Questions

How does FDA Computer Software Assurance (CSA) differ from traditional Computer System Validation (CSV)?

Traditional Computer System Validation (CSV) often applied heavyweight, step-by-step scripted testing and screenshot evidence uniformly across all non-product software. The FDA Computer Software Assurance (CSA) guidance replaces Section 6 of the 2002 GPSV with a risk-based framework for production and quality system software: it evaluates risk at the individual feature level, reserves scripted testing for high-process-risk functions that directly affect patient safety or device quality, and encourages unscripted testing (exploratory, error-guessing, or ad-hoc testing) and vendor-leveraged evidence for lower-risk functions.

What does the FDA General Principles of Software Validation guidance require for medical device vs QMS software?

Issued in January 2002, the FDA General Principles of Software Validation (GPSV) guidance established lifecycle validation principles (Sections 1–5) for medical device software (SiMD and SaMD), including requirements definition, design traceability, structural and functional testing, and defect management. However, Section 6 of GPSV—which governed automated process equipment and quality system software—has been superseded by the FDA Computer Software Assurance (CSA) guidance.

How do you document Off-The-Shelf (OTS) software in medical device submissions?

Under the FDA August 2023 final guidance Off-The-Shelf Software Use in Medical Devices, manufacturers incorporating third-party OTS components (such as operating systems, databases, or communications libraries) into a medical device must provide premarket documentation scaled to the device’s Basic or Enhanced Documentation Level. Every submission requires an OTS description (title, manufacturer, version/patch level), a hazard and risk analysis of OTS failures, verification and validation testing of the integrated OTS functions, and a plan for continued maintenance, cybersecurity patching, and obsolescence.