Computer Software Assurance for Production and Quality Systems

With the Quality Management System Regulation (QMSR) in effect, the Food and Drug Administration’s (FDA) computer software assurance guidance has been issued. Together they close a transition that began with a 2022 draft, moving industry practice away from documentation-heavy habits. The guidance is titled Computer Software Assurance for Production and Quality Management System Software. That title names the scope, which is the tools teams run manufacturing and quality processes with, not the software that ships inside a device.

Quality engineers still face validation Standard Operating Procedures (SOPs) written for legacy computer system validation (CSV). Those procedures often require scripted protocols and screenshot evidence for every system, regardless of risk. A team validating an electronic quality management system (eQMS) with the same rigor as a sterilization controller spends effort the FDA’s risk-based framework does not require. This guide covers what the guidance recommends, how the risk framework decides testing method, and where teams get stuck putting it into practice.

What Is Computer Software Assurance (CSA)?

Computer Software Assurance (CSA) is a risk-based approach for establishing and maintaining confidence that software is fit for its intended use. The FDA finalized the guidance September 24, 2025, then updated it February 3, 2026, to align terminology with the QMSR. That February 2026 version is the current, issued guidance, and assurance effort depends on the risk to device safety or quality if the software fails to perform as intended.

CSA applies to computers and automated data processing systems used in medical device production or the quality management system, including eQMS platforms, manufacturing execution systems (MES), laboratory information management systems (LIMS), manufacturing automation, and cloud services supporting those activities.

Software as a Medical Device (SaMD) and software in a medical device (SiMD) sit outside the guidance and follow International Electrotechnical Commission (IEC) 62304, Medical device software, Software life cycle processes, and design controls instead. For automated process equipment and quality system software, the final guidance supersedes the relevant section of the 2002 General Principles of Software Validation, reflecting the same critical-thinking, risk-based emphasis found in Good Automated Manufacturing Practice (GAMP) 5 Second Edition.

Why Are Medical Device Manufacturers Moving From CSV to CSA?

CSV describes the industry’s accumulated practice for meeting the software validation requirement, and that practice grew heavier than the regulation demanded.

The Documentation Burden of Traditional CSV

Regulated industry often screenshots every test step, a practice that grew around the FDA’s 2002 validation guidance. Under that approach, roughly 80% of validation effort goes to documentation and testing, only 20% to critical thinking. CSA reverses that balance toward risk-based assurance.

FDA’s Risk-Based, Least-Burdensome Approach

The least-burdensome principle predates CSA, and the framework applies it to production and quality management system software. Assurance activity documentation need not include more evidence than necessary to show the software feature, function, or operation performs as intended for the identified risk. CSA aims to improve efficiency, but early projects may cost more while personnel learn the new approach.

How Does the CSA Risk Framework Work?

Teams apply the framework by identifying intended use, evaluating the risk if the software fails to perform as intended, determining assurance activities commensurate with that risk, and establishing the appropriate record.

Identifying the Software’s Intended Use

First, determine whether software participates in production or the quality management system at all. Scope determines whether validation is required before any risk-based assurance method is selected. Software that supports neither doesn’t need validation. In-scope software falls into two groups:

• Directly used software: Production processes, inspection and test systems, quality management system processes, and anything that collects, processes, or maintains quality records.
• Supporting software: Development tools that test or monitor other systems, and general record-keeping outside the quality record.

Intended use can be assessed by feature rather than only at the system level, with different assurance activities applied to individual features inside one system. A single LIMS might contain one feature that determines product acceptability and dozens that only format reports.

Determining Process Risk vs. Direct System Risk

The framework separates process risk, or potential compromise of production or the quality management system, from medical device risk, or potential harm to a patient or user. Process risk is high or not high, and intermediate levels use the “not high” provisions. High process risk applies when failure may cause a quality problem that foreseeably compromises safety, such as software maintaining process parameters like temperature, pressure, or humidity affecting device safety, or software that measures, inspects, or determines product acceptability with limited or no human review.

Quality system software functions land on the other side when human review or downstream controls prevent foreseeable safety compromise. Complaint management, change control, and document management are generally not high process risk, so those functions can qualify for lighter assurance methods.

Matching Assurance Activities to the Risk Level

For high process risk features, assurance should be commensurate with the medical device risk, with scripted, limited scripted, or fully scripted testing scaled as appropriate. For everything else, assurance matches process risk, and unscripted methods such as scenario testing, exploratory testing, ad hoc testing, and error guessing are acceptable. The pairings aren’t exclusive. Unscripted testing may suit some high-risk features, scripted testing may fit some low-risk ones, and vendor evidence such as development lifecycle documentation, test records, System and Organization Controls (SOC) 2 reports, and International Organization for Standardization (ISO) certifications can reduce manufacturer-run testing.

What Testing and Documentation Does CSA Recommend?

The guidance describes scripted and unscripted testing methods that manufacturers may select based on risk and provides recommendations for documenting the assurance activities performed.

Unscripted vs. Scripted Testing Approaches

For lower-risk assurance work, testers can use dynamic unscripted testing without prescribed written instructions. Exploratory testing is one option, and ad hoc testing and error guessing are also permitted. Exploratory testing calls for high-level test plan objectives with pass/fail criteria, plus documentation of any software failures or deviations found. Ad hoc testing and error guessing do not require detailed prescripted test cases, but the overall assurance record should still document the intended use, risk-based analysis, assurance activities performed, issues identified, acceptability conclusion, tester and date, and review or approval when appropriate.

Scripted testing prescribes the tester’s actions in a written test case, and the recommended record is heavier. The most detailed method calls for a test plan with objectives, detailed step-by-step test cases, expected results, and independent review and approval when appropriate, plus a result record for each test case and details of any deviations. Legacy CSV applied that protocol everywhere, while CSA reserves it for features whose failure could reach a patient.

Building the Assurance Record

Whatever the method, the record should capture sufficient objective evidence that the software was assessed and performs as intended. The form can vary by risk, test method, and evidence source. The guidance recommends a record that covers:

• Intended use: The software feature, function, or operation being assured.
• Risk analysis result: The outcome of the analysis that determined the assurance approach.
• Assurance activities: A description of the testing conducted and any issues found.
• Acceptability conclusion: A declaration that the software is acceptable, with resolution or risk justification for issues found.
• Tester and date: Who performed the testing and when, with approval signatures when appropriate.

Electronic records such as system logs and audit trails fit CSA better than paper documentation and screenshots. Teams that assemble that evidence by hand end up rebuilding it for every audit.

Where Do Teams Get Stuck Adopting CSA?

For regulated teams, adopting the guidance requires organizational change more than technical change. CSA replaces long-standing validation habits and asks quality and engineering staff to exercise new judgment on every feature they classify.

Uneven internal understanding is the clearest adoption barrier. Only 14% of participants claimed a strong understanding of CSA, 31% had no prior knowledge of it, and the remaining 55% were unclear on how it differs from CSV, according to a March 2024 GAMP South Asia webinar of 71 respondents. Those numbers reflect inspection anxiety and inherited habits as much as any lack of clarity in the guidance itself.

Fear of a Form 483 finding can keep manufacturers running blanket validation long after the FDA signaled otherwise, producing a package burdensome to prepare and review. Finalization did not do that calibration work. MedTech teams still have to decide how much assurance each feature needs, which makes organizational capability the remaining constraint, not regulatory clarity.

Getting Started With CSA

Getting started means rewriting the validation SOP so the risk outcome, not the system type, decides the testing method. The FDA’s QMSR compliance transition guide covers the broader regulatory shift this sits inside. A rollout usually works through this sequence:

• Inventory every system touching production or the quality management system.
• Classify intended use at the feature level, not the system level.
• Assess process risk for each feature, high or not high.
• Trace any high-risk feature to its device-safety impact.
• Select an assurance method commensurate with that risk.
• Identify the evidence source, whether manufacturer-run testing, vendor evidence, or both.
• Assign an owner and record approval status for each feature.
• Update the SOP so this outcome governs the method going forward.

A bounded pilot shows where risk-based validation saves effort before the approach spreads across the inventory. Early quality-function involvement keeps that pilot from generating rework.

How Jama Connect Supports Computer Software Assurance

Feature-level risk classification only holds up if the assurance record can prove which risk analysis, test method, and reviewer applied to a given feature, and that connection survives a design change made months later. Jama Connect® is a web-based requirements management platform with a pre-built medical device framework covering FDA design controls under the QMSR. That framework aligns to ISO 13485, Medical devices, Quality management systems, and to IEC 62304, with templates for design inputs and outputs and exports for Design History File and technical file documentation. Jama Connect manages electronic records and signatures in review workflows, keeping Part 11 obligations connected to the records under review. Live Traceability™ keeps requirements, risk records, design outputs, and test cases connected as designs change, so a single requirement edit flags every downstream record that needs review.

Validating the tool itself is its own assurance activity, and vendor evidence can reduce how much of that work a manufacturer runs directly. Jama Software® offers a Customer Validated Cloud environment for medical device customers needing a separately validated hosting environment. Jama Connect is SOC 2 Type 2 certified at both the server and application level and validated by TÜV SÜD for safety-related development. That is vendor evidence of exactly the kind the guidance lets manufacturers count toward their own package.

Putting Computer Software Assurance Into Practice

None of this works if risk decisions, evidence, and the impact of change live in separate places. A feature reclassified from not-high to high process risk should flag every test record and SOP reference tied to it immediately, not wait for the next audit. Assurance methods can flex by risk level, but the reasoning behind each classification needs to hold together for the product’s life, not just at the moment of testing.

If your team is ready to keep risk classifications, test evidence, and design changes linked instead of scattered across spreadsheets and shared drives, Jama Connect can help build that audit-ready record as your system changes. You can start your free Jama Connect trial to see how it works.

Frequently Asked Questions About Computer Software Assurance

What is the difference between CSV and CSA?

CSV describes two decades of industry practice built on the FDA’s 2002 General Principles of Software Validation, where scripted protocols became the default for every system. CSA supersedes only Section 6 of that guidance, the part covering production and quality system software, and makes the risk analysis decide the testing method. If your SOP still requires full scripted test cases and screenshots for every function, it likely needs revision. Jama Software’s practical guide to software validation walks through that rewrite, and a platform built for continuous evidence capture, including Jama Connect, makes it easier to prove during an audit.

Does CSA apply to all medical device software?

No. CSA applies to production and quality management system software, while device software, including SaMD and software that runs inside a medical device, follows IEC 62304 and design controls under FDA QMSR, with separate premarket submission requirements. The risk logic differs too, since IEC 62304 classifies device software by the direct severity of harm it could cause, while CSA asks whether a process failure foreseeably compromises device safety. Jama Software’s IEC 62304 software lifecycle guide covers those classification rules.

Is the FDA’s CSA guidance final or still a draft?

The FDA’s CSA guidance is final and currently issued, after a draft on September 13, 2022, and a first finalization September 24, 2025. An updated version aligning terminology with the QMSR published February 3, 2026, and teams should align SOPs and assurance records to that terminology. The FDA and ISO 13485 harmonization behind that change explains which terms moved.

This article was authored by Tom Rish and published on August 20, 2026.