FDA Computer Software Assurance vs. Traditional Computer System Validation: Changed Expectations and Inspection Findings

FDA Computer Software Assurance vs. traditional computer system validation: what changed, and how inspections treat software validation failures

FDA's Computer Software Assurance (CSA) guidance does not remove the obligation to validate production and quality-system software for its intended use. It changes how manufacturers show that the software is fit for purpose. Under CSA, assurance effort follows process risk, unscripted and experience-based testing are accepted for lower-risk functions, existing vendor and system evidence can be reused, and the record only needs to be as large as the risk calls for. Enforcement has not followed that shift. Warning letters and Form 483 observations keep citing the same basic failures: software in use with no validation at all, no protocol or acceptance criteria, and no retrospective look at other systems or at product already released. This article explains the CSA framework, how it differs from the earlier General Principles of Software Validation (GPSV) approach, and what inspection records show about software validation failures in device and drug manufacturing.

Regulatory status and scope of the CSA guidance

FDA issued the draft guidance, Computer Software Assurance for Production and Quality System Software, on September 13, 2022. It was marked "Not for Implementation" ⁸¹⁵⁷. The final guidance, retitled Computer Software Assurance for Production and Quality Management System Software, was issued on February 3, 2026. Like all FDA guidance, it contains nonbinding recommendations ⁵⁶⁸⁰.

The legal anchor changed between the draft and the final version:

• The 2022 draft addressed validation under 21 CFR 820.70(i) ⁶⁴.
• The 2026 final guidance cites ISO 13485 subclauses 4.1.6, 7.5.6 and 7.6 for software used as part of production or the quality management system ⁷⁷. This follows the Quality Management System Regulation (QMSR), effective February 2, 2026. The QMSR revised Part 820, removed 820.70 and incorporated ISO 13485:2016 by reference ⁷⁸.

The final CSA guidance supplements GPSV. It replaces only GPSV's Section 6, "Validation of Automated Process Equipment and Quality System Software," not the whole document ⁷⁹.

What software is in scope. CSA covers computers and automated data-processing systems used in two ways ⁷⁵⁴⁶:

• Directly in production or the quality management system. This includes software that automates production, inspection, testing, processing of production data, quality-management processes or quality records.
• In support of those functions. This includes certain testing tools and general recordkeeping tools for production or quality management.

The framework can also apply to automation, analytics, AI/ML and cloud tools used for these purposes. Cloud computing used for device software functions is outside its scope ⁷⁵⁴⁶. General business applications and infrastructure that are not specific to production or the quality management system generally fall outside the software-validation requirements ⁷⁶.

Device-only scope. The final guidance's introduction defines its subject as software used in medical device production or the quality management system. The final-guidance passages reviewed for this article do not set up a separate applicability category for drugs, biologics or combination products ³⁵³. Drug CGMP computerized systems therefore remain under 21 CFR 211.68 and FDA's drug-side guidance, discussed below.

The baseline: traditional CSV under GPSV Section 6

GPSV defines software validation as "confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled" ¹³⁰¹³¹. Section 6 explained that 21 CFR 820.70(i) required manufacturers to validate production and quality-system software for its intended use under an established protocol. This applied to software developed in-house, developed under contract or bought off the shelf ¹²⁴¹²⁵.

GPSV already recognized risk. Validation effort was to be commensurate with the risk of the automated operation, the complexity of the software and how much the firm depended on it to produce a safe and effective device. For commercial quality-system software, functions the firm did not use generally did not need validation ¹²⁸¹²⁹.

In practice, the documentation package in Section 6 was large and protocol-driven. The manufacturer was expected to:

• document user requirements, the operating environment and objective acceptance criteria;
• execute a documented protocol;
• retain requirements, protocol, acceptance criteria, test cases and results, and a validation summary.

The manufacturer stayed responsible even when a vendor or consultant did the work ¹²⁶¹²⁷. This document set is what industry usually means by "traditional CSV."

What CSA changes

A four-part, feature-level risk framework

CSA sets out a structured sequence. It starts with the individual software feature, function or operation, not the whole system.

1. Identify the intended use. Decide, and document, whether each feature, function or operation is or will be used as part of production or the quality management system. Features with different intended uses are assessed separately. If the software has only one intended use, an overall assessment may be enough ²⁹⁵²⁹⁶.
2. Determine the risk-based approach. Identify reasonably foreseeable failures, not only likely ones, and the risks that follow from each. Consider configuration, security, data integrity, storage, transfer and operating error ²⁹⁷²⁹⁸.
3. Classify process risk as "high" or "not high." A feature is high process risk if its failure could cause a quality problem that foreseeably compromises safety. Otherwise it is not high process risk. Risk is a spectrum, but the guidance uses only these two categories. "Intermediate" risk falls under not high ^{299300301302303}.
4. Select assurance activities and establish the appropriate record. Both scale with the risk classification (see below).

The guidance gives examples for each category ^304305306307:

For high-process-risk features, assurance is matched to the risk of the related medical device. For not-high features, it is matched to the process risk ³⁰¹³⁰².

Testing methods: from scripted-by-default to risk-selected

CSA does not assign a fixed test method to each risk category ³¹¹:

• High-process-risk features may warrant more rigorous scripted testing, or a scaled hybrid of scripted and unscripted testing.
• For not-high features, unscripted methods may be considered.
• These are examples, not rules. Unscripted testing can suit a high-risk feature, and automated scripted testing can be the efficient choice for a low-risk one.

The guidance describes the following methods:

• Robust scripted testing: step-by-step test cases, expected results and results recorded for each case ³¹²³¹³.
• Limited scripted testing: some step-by-step cases combined with unscripted testing ³¹²³¹³.
• Scenario testing (also called ad-hoc testing): exercises sequences of interactions between the software, other systems and users ³¹⁴.
• Error guessing: test cases derived from past failures or known failure modes, including attempts to get around workflows or access controls ³¹⁵³¹⁶.
• Exploratory testing: high-level objectives and pass/fail criteria with no step-by-step procedure. The guidance gives an example of rapid exploratory testing of a spreadsheet judged not to be high process risk ^317318319.

Leveraging existing assurance

A major practical change is that manufacturers are told to build on assurance that already exists rather than repeat it:

• Under established purchasing controls, developers' practices, validation work and electronic information can be the starting point for deciding what extra work is needed ³²⁰³²¹.
• For some lower-risk supporting software, vendor evaluation plus validation, installation or configuration records may give enough assurance without further scripted or unscripted testing ³²⁰³²¹.
• Other evidence can also reduce the additional assurance effort ^322323324:
  • downstream production controls, inspection and testing;
  • software data collected periodically or continuously that detects anomalies after implementation;
  • development and life-cycle tools;
  • test results accumulated over the software life cycle.

The manufacturer remains responsible for choosing activities that keep the software in a validated state ³⁵⁴.

Right-sizing the record

The section on establishing the appropriate record recommends that the record include ¹¹¹:

• the intended use;
• the result of the risk-based analysis;
• the assurance activities and testing performed;
• issues found and how they were resolved;
• a conclusion that the software is acceptable for its intended use;
• who did the testing or assessment, and when.

Review and approval should be established "when appropriate." A signature and date are given as examples for cases where an authorized signature is needed, not as a requirement for every record ¹¹¹. FDA says evidence need not go beyond what the identified risk requires. It recommends using existing digital records such as system logs and audit trails rather than paper, screenshots, or copies of results the software already keeps ²¹⁴²¹⁷. This does not remove documentation. The guidance's table of example records still shows detailed test-case records for robust scripted testing, while exploratory testing is documented as a summary of objectives and testing performed ²¹⁵²¹⁶.

Part 11 is not an escape hatch

The final guidance includes a section on electronic records requirements. It says electronic documents required under Part 820 generally fall under Part 11, and that whether Part 11 applies to a particular record depends partly on whether the record is needed as validation evidence. FDA's stated enforcement discretion for certain Part 11 computerized-system validation requirements does not remove the ISO 13485 validation requirements for production and quality-management-system software ³⁵¹³⁵².

FDA's rationale

FDA presents CSA as a way to focus quality-assurance effort while still meeting validation requirements. It also intends CSA to support technologies that reduce errors, make better use of resources, reduce patient risk and keep pace with fast-changing software ⁷³³⁴⁹.

Side-by-side summary

The drug CGMP counterpart: 211.68 and workflow validation

CSA is written for devices. On the drug side, FDA's CGMP data-integrity guidance answers the question "Does each CGMP workflow on a computer system need to be validated?" with yes. Each CGMP workflow is an intended use. Qualifying the platform alone does not show that a particular workflow runs correctly. FDA's example is a manufacturing execution system that meets its specifications while the electronic master production and control record it generates still contains incorrect steps or calculations ³⁷⁵.

That guidance also says validation studies should be commensurate with the risk of the automated system, and that any effect of non-CGMP functions on CGMP operations should be assessed and mitigated ³⁷⁵. Drug guidance therefore shares CSA's intended-use, risk-proportionate logic. In drug inspections, however, the focus is on data integrity controls, as the warning letters below show.

How FDA inspections have treated software validation failures

The examples below come from warning letters and Form 483s retrieved for this article. They illustrate recurring patterns and are not a complete census.

Device warning letters under 21 CFR 820.70(i)

The most common device finding is simple: software in use with no validation at all, usually quality-system software rather than production-control software.

• Complaint, CAPA and quality-record systems. Examples:
  • Complaint-handling and data-analysis programs at F.P. Rubinstein (2016) ¹⁵⁴.
  • Firm-developed service and complaint software at Fisioline (2013). FDA found no protocol, test data or final report ¹⁵⁵.
  • Software for complaints, CAPA and quality logs at Phoenix Bio-Tech (2009) ¹⁶⁹.
  • Software for design changes, complaints, CAPA and nonconformances at Savaria Concord Lifts (2016) ¹⁷⁸.
• ERP and production-planning systems. Oertel Medical's Majesty ERP, used for production planning and quality records, had no qualification or validation procedures or records, and version changes were not controlled ¹⁶⁷. Herniamesh had two unvalidated systems, one for quality records and one for purchasing, logistics and production ¹⁵⁸.
• Spreadsheets. Ropack used an uncontrolled spreadsheet to track equipment-requalification due dates ¹⁶¹.
• Production and test software. Examples:
  • A computer-controlled COB machine at Dongguan Jianwei was used in production with no validation protocol ¹⁶⁶.
  • A milling-machine program at Advanced Surgical Design & Manufacture had not been validated under an established protocol ¹⁸².
  • Amplivox validated its audiometer calibration system without a protocol established in advance ¹⁷⁴.
• Data-integrity defects found through validation gaps. At Dexcowin (2018), unvalidated device history record software let a technician mark the same test as both pass and fail with no error ¹⁸⁰.

What FDA expects in the response. The response expectations are the most useful part of these letters. FDA repeatedly rejected responses limited to validating the one cited system:

• Herniamesh: a promised retrospective validation was not enough. FDA also expected a review of other production and quality-system software ¹⁵⁹.
• Guilin Zizhu Latex: FDA expected a retrospective search for other production software needing validation, and an assessment of whether condoms made earlier might be nonconforming ¹⁷¹.
• Dexcowin and Woo Young Medical: proposed validation and training were not enough without a retrospective review of other automated processes or software ¹⁸¹¹⁷⁶.
• Savaria: FDA asked for retrospective-review results, corrective actions and effectiveness checks, including errors and risks from unvalidated systems ¹⁷⁹.
• Olympus Terumo Biomaterials: dropping electronic CAPA recordkeeping did not resolve the finding without evidence of an adequate replacement system ¹⁷³.

Recent device letters, including the first QMSR-era citation

Letters issued after the CSA draft follow the same pattern:

• Fischer Analysen Instrumente (Feb. 3, 2023): unvalidated Excel spreadsheets for complaint and CAPA records, with no adequate record of changes or deletions. FDA wanted a systematic retrospective comparison against physical records and a completed evaluation of other quality-system spreadsheets ²⁷⁴²⁷⁵.
• Vitang Technology (June 12, 2023): a Ruby on Rails web application used to maintain complaint files had not been validated for its intended use ²⁷⁶.
• Rolence Ent. (Oct. 18, 2024): an unvalidated X-ray quality-control application was used for final device testing. The response had no supporting documentation, no retrospective review of production and no training plan ²⁸⁴²⁸⁵.

The Linemaster Switch letter of May 27, 2026 is the first retrieved letter to cite software validation under the QMSR, using ISO 13485:2016 Clause 7.6 ³⁸¹³²⁷.

• Deficiencies. Validation of the Monitor Program software, used to calibrate and test foot pedals, lacked:

  • raw test data and pass/fail criteria or results;
  • a statistical or sample-size rationale;
  • verification that the software measured outputs accurately and detected nonconforming devices.

  FDA also noted routine COM-port errors that were never investigated, and units that passed Linemaster's calibration but failed the customer's ³²⁸.

• FDA's request. FDA asked when revalidation would be complete and whether a review of past product-disposition and calibration decisions would require further action ²⁸⁷.

None of the post-2022 validation passages reviewed expressly mentions a "risk-based approach" or "computer software assurance" ²⁸⁸. In these letters, the cited problems were missing or unsupported validation, not over-documentation or the wrong testing style.

Form 483 observations

Form 483 observations show the same themes. They also show where investigators look past a nominally "validated" system to how well the validation was done:

• Validation without challenge testing. Zimmer Biomet (2017) used software to determine the scope of a quality hold. Its validation lacked documented verification of output against a known value and adequate robustness or stress testing, including large-range queries that could produce errors ³¹³²³³. Daewoong Pharmaceutical (2017) validated WinKQCL endotoxin software without challenging user-access and data-security functions ²⁹³⁰.
• Spreadsheets and desktop tools. Utah Medical Products (2004) used unvalidated complaint software and CAPA and nonconformance spreadsheets ²³. Terumo Cardiovascular (2008) tracked audit discrepancies in Microsoft Access ²⁵²⁶. Theranos (2015) kept manufacturing raw data in an unvalidated Excel spreadsheet with no attribution or QA review ²⁷²⁸.
• Upgrades and revalidation. Biocon Biologics (2022) did not revalidate SIMATIC WinCC after a SCADA hardware upgrade ³⁷³⁸. Lupin (2019) had no revalidation protocol for microbial-identification software after reinstallation ³⁴. Suzhou Suncadia (2025) did not verify particle-monitoring software settings after upgrades ⁴².
• Legacy systems. Shilpa Medicare (2019) had used a stability-chamber monitoring system since 2009 without validation, outside change control, and its Validation Master Plan did not address computerized systems ³⁵³⁶.
• Software outside production control. XL Precision Technologies (2025) used unvalidated equipment-maintenance software to identify out-of-specification measurements, and had no procedure for validating software not used to control device production ⁴³⁴⁴.

Drug CGMP warning letters under 21 CFR 211.68

Drug-side letters frame computerized-system failures mainly as data-integrity problems:

• Common findings:

  • laboratory systems with audit trails disabled;
  • shared or administrator-level credentials;
  • the ability to delete or overwrite raw data;
  • inadequate backups.

  Examples include Teva (2016), Enprani (2019), Vi-Jon (2022) and Nortec Quimica (2022) ^248257254247.

• Explicit validation findings. Wockhardt (2016) had 12 unvalidated QC computerized systems, including stability-chamber and spectrophotometer systems ²⁴². At Sun Pharmaceutical (2015), a data acquisition unit monitoring incubation-room temperature had never been qualified or validated ²¹⁸.

FDA consistently rejected narrow fixes:

• Teva: turning on audit trails and restricting users was not enough. FDA asked for the scope and rationale of a retrospective data review ²⁴⁸.
• Enprani and Swabplus: buying or upgrading software, or explaining the equipment away as "legacy," did not resolve the findings without a comprehensive assessment and retrospective review of all CGMP computerized laboratory systems ²⁵⁷²⁵⁹.
• Vi-Jon and Nortec Quimica: FDA asked for independent or third-party security-and-integrity assessments, with CAPA plans covering vulnerabilities, configurations and privileges ^254255247.
• Westwood Laboratories (2024): the firm stayed responsible for HPLC system validation even though its vendor had performed it, and the validation documentation could not be found during inspection ²⁸²²⁸³.

Reconciling CSA with the enforcement record

Read together, the guidance and the inspection record point to a few practical conclusions. These are this article's interpretation, not FDA statements:

1. CSA lowers the evidence burden for low-risk software but not the duty to validate. Most cited failures involve quality-system tools such as complaint, CAPA and ERP software, and spreadsheets. CSA would often classify these as not high process risk ³⁰⁶. The violations were not about using unscripted testing. They were about having no documented intended use, no risk determination and no record at all ^155158276. A short CSA record covering intended use, risk result, activities, issues, conclusion and who and when ¹¹¹ would have answered many of these findings.
2. High-process-risk functions still need rigorous, objective evidence. The Linemaster and Zimmer Biomet findings concern software that decides whether product is acceptable or sets the scope of a quality hold ³²⁸³¹. CSA places this kind of function in the high-process-risk category ³⁰⁴. Missing acceptance criteria, missing raw data and no stress testing remain citable.
3. Vendor reliance is a starting point, not a defense. CSA lets firms use supplier evidence under purchasing controls ³²⁰³²¹. Enforcement shows the user firm must still be able to produce that evidence and own the result ²⁸³¹²⁷.
4. Remediation expectations reach across the whole portfolio. In both device and drug letters, FDA expects a retrospective review of other software or systems and an assessment of the impact on product or data already released ^159171257. A CSA-based inventory of intended uses and risk classifications gives a firm a defensible basis for that kind of review.
5. Change control and revalidation are recurring gaps. Inspection findings on upgrades and reinstallation ³⁷³⁴⁴² fit CSA's expectation that firms maintain a validated state ³⁵⁴. The final-guidance passages reviewed do not set a general revalidation trigger, so firms need to define one in their own procedures.