FDA Issues Final Computer Software Assurance Guidance

Introduction

On September 24, 2025, the U.S. Food and Drug Administration (FDA) issued its final guidance titled “Computer Software Assurance for Production and Quality System Software” (hereinafter, CSA Guidance). This guidance had been initially released as a draft on September 13, 2022, and after an extensive three-year comment period incorporating stakeholder feedback, it has now been finalized.

The CSA Guidance provides recommendations for computer software assurance for computers and automated data processing systems used as part of medical device production or the quality system. This represents a significant evolution in how the FDA approaches software validation in regulated environments.

The Evolution from CSV to CSA

Background of the Case for Quality Initiative

Since 2008, FDA’s Center for Devices and Radiological Health (CDRH) has been advancing the Case for Quality Program. As part of this initiative, CDRH has worked collaboratively with industry stakeholders and the International Society for Pharmaceutical Engineering (ISPE) Good Automated Manufacturing Practice (GAMP) community to develop the CSA framework.

Limitations of Traditional CSV

The traditional Computer System Validation (CSV) approach, which has been required by regulations, has long been recognized as having several significant limitations. The conventional CSV methodology requires extensive documentation, consuming considerable time, effort, and resources. Moreover, the documentation generated through CSV is often created primarily to satisfy regulatory inspection requirements rather than to genuinely support product quality assurance or ensure patient safety.

This situation has resulted in unnecessary compliance costs. In the medical device industry, CSV requirements have often represented the highest barrier to ensuring final product quality. The documentation-heavy approach has inadvertently shifted focus away from the true objective: ensuring that software systems perform as intended and support quality outcomes.

The CSA Approach

The CSA Guidance introduces a risk-based approach for evaluating computer software used in medical device production or quality systems. This methodology establishes confidence that automation is appropriate for production or quality systems, identifies where additional rigor may be warranted, and determines suitable assurance activities.

Furthermore, the CSA Guidance describes various methods and testing activities that can be applied to establish computer software assurance and provide objective evidence to fulfill regulatory requirements, including the computer software validation requirements specified in 21 CFR Part 820 (Quality System Regulation, or QSR).

Relationship Between GPSV Guidance and CSA Guidance

Background on GPSV Guidance

The finalized CSA Guidance supplements the FDA guidance “General Principles of Software Validation” (issued January 2002; hereinafter, GPSV Guidance). The GPSV Guidance outlines principles of software validation, including implementing change management as part of the software lifecycle.

However, the GPSV Guidance primarily focused on embedded software within medical devices (Software in Medical Devices: product software). It provided minimal coverage of CSV for non-product software used internally by medical device companies, such as automated systems, measurement devices, complaint management systems, and document management systems.

How CSA Supplements and Updates GPSV

The CSA Guidance is not intended to explain all principles of software validation comprehensively. Rather, it applies the risk-based approach to software validation described in the GPSV Guidance specifically to software used in medical device production or quality systems.

When the CSA Guidance was finalized in September 2025, it officially superseded Section 6 (“Validation of Automated Process Equipment and Quality System Software”) of the GPSV Guidance. This represents a formal recognition that the risk-based CSA approach is now the recommended framework for production and quality system software.

Important Scope Clarification

It is important to note that the CSA Guidance does not apply to software embedded in medical devices (Software in a Medical Device, SiMD) or software as a medical device (Software as a Medical Device, SaMD). These types of software are subject to design validation requirements under QSR §820.30, which remain unchanged and are covered by other FDA guidance documents.

Structure and Content of the CSA Guidance

The finalized CSA Guidance follows a comprehensive structure designed to guide manufacturers through implementing a risk-based approach to software assurance.

Main Sections

I. Introduction This section sets the context for the guidance and explains its purpose within the broader regulatory framework.

II. Background This section provides historical context, explaining the evolution from traditional validation approaches to the risk-based CSA methodology. It references the Case for Quality Program and FDA’s engagement with industry stakeholders.

III. Scope This section clearly delineates what types of software and systems fall within the guidance’s purview, explicitly stating that it applies to production and quality system software but not to SiMD or SaMD.

IV. Definitions This section provides precise definitions for key terms used throughout the guidance, including:

• Computer Software Assurance
• Cloud Computing (Cloud)
• High Process Risk
• Not High Process Risk
• Intended Use
• Scripted Testing
• Unscripted Testing

These definitions are critical for consistent interpretation and application across the industry.

V. Computer Software Assurance This section introduces the fundamental concepts of CSA, explaining how it differs from traditional validation approaches and why a risk-based methodology is more appropriate for modern software systems.

VI. Computer Software Assurance Risk Framework This is the core section of the guidance, providing detailed recommendations for implementing CSA. It includes four key components:

A. Identifying the Intended Use This subsection emphasizes the importance of clearly defining how software will be used within production or quality systems. Understanding the intended use is foundational to all subsequent risk assessment activities.

B. Determining the Risk-Based Approach This subsection introduces the classification of process risk into two categories: “high process risk” and “not high process risk.” It provides criteria and examples to help manufacturers categorize their software systems appropriately.

The guidance makes clear that risk determination should consider both the probability and severity of potential harm. Software that directly impacts critical quality attributes or patient safety typically warrants classification as high process risk.

C. Determining the Appropriate Assurance Activities Based on the risk classification determined in the previous step, this subsection describes different types of assurance activities that may be appropriate:

For high process risk software, the guidance recommends more rigorous assurance activities, typically including scripted testing with documented test protocols and results.

For software that is not high process risk, the guidance allows for more flexible approaches, which may include unscripted testing (exploratory testing with documentation of approach and results), leveraging vendor documentation and testing, or other appropriate assurance methods.

This represents a significant departure from the traditional “one-size-fits-all” validation approach, allowing manufacturers to allocate resources more effectively based on actual risk.

D. Establishing the Appropriate Record This subsection addresses documentation requirements. The CSA approach emphasizes that records should provide objective evidence that software has been assessed and performs as intended, but it does not prescribe a specific format or level of detail for all situations.

Records should be commensurate with the risk level and sufficient to demonstrate that:

• The intended use has been identified
• Risk has been appropriately assessed
• Appropriate assurance activities have been performed
• The software remains in a validated state throughout its lifecycle

VII. Appendix A: Examples The guidance includes three practical examples that illustrate how the CSA framework can be applied to different types of software systems:

Example 1: Nonconformance Management System This example demonstrates how to apply CSA to a commercial-off-the-shelf (COTS) system used for managing nonconformances electronically. It walks through the process of identifying intended use, assessing risk for different features and functions, and determining appropriate assurance activities.

Example 2: Learning Management System (LMS) This example shows the application of CSA to an LMS used for managing, recording, tracking, and reporting on training activities. It illustrates how different functions within the same system may warrant different levels of assurance based on their risk profile.

Example 3: Business Intelligence Applications This example addresses business intelligence software used for data mining, trending, and reporting to understand product and process performance over time. It demonstrates how analytical and reporting tools can be evaluated under the CSA framework.

These examples are particularly valuable for manufacturers beginning to implement CSA, as they provide concrete illustrations of how the framework applies to commonly used software systems.

CSA Guidance and Risk-Based Approach: Detailed Framework

The CSA Risk Framework in Practice

The CSA Guidance presents a comprehensive risk framework for computer software, built on the systematic evaluation of intended use, risk-based analysis of software that is part of production or quality systems, identification of appropriate assurance activities based on determined risk levels, and creation of records documenting that the system operates as intended.

Process Risk Classification

A critical innovation in the CSA Guidance is the introduction of a binary classification system for process risk. Software is categorized as either “high process risk” or “not high process risk,” with the guidance providing detailed examples for each category.

High Process Risk Characteristics: Software is typically considered high process risk when its failure could directly impact critical quality attributes, patient safety, or data integrity. Examples include:

• Electronic batch record systems that control manufacturing processes
• Automated equipment that performs critical process steps
• Systems that generate data directly used for release decisions
• Software that implements critical quality controls

Not High Process Risk Characteristics: Software is typically considered not high process risk when its failure would not directly impact critical quality attributes or patient safety, or when adequate compensating controls exist. Examples include:

• Training management systems (with appropriate manual oversight)
• General reporting and trending tools (when not used for release decisions)
• Administrative systems with limited GMP impact

The guidance emphasizes that this risk determination should be based on both the probability of failure and the severity of consequences, consistent with established quality risk management principles such as those described in ICH Q9.

Assurance Methods Aligned with Risk

Based on process risk classification, the CSA Guidance describes different assurance methods that may be appropriate:

For High Process Risk:

• Scripted testing with documented protocols and expected results
• Comprehensive traceability between requirements and tests
• Rigorous change control and regression testing
• Detailed documentation of testing and results

For Not High Process Risk:

• Unscripted testing (exploratory testing with documentation of approach and findings)
• Leveraging vendor testing and documentation
• Simplified testing approaches focused on intended use
• Less extensive documentation while maintaining evidence of assessment

This tiered approach allows manufacturers to focus intensive validation efforts where they matter most while streamlining activities for lower-risk systems.

Documentation and Records

The CSA Guidance emphasizes that objective evidence must be sufficient to demonstrate that software features, functions, or operations have been assessed and perform as intended. However, it explicitly states that “sufficient” does not necessarily mean “extensive.”

Records should typically include:

• Description of intended use
• Risk determination and rationale
• Summary of failure modes tested and testing performed
• Test results demonstrating the software operates as intended
• Change control documentation

The guidance makes clear that CSA focuses on being test-oriented rather than documentation-oriented. This represents a philosophical shift: the goal is confidence that software performs correctly, not creation of documentation for its own sake.

Important Considerations for Implementation

Authorship and Scope

The CSA Guidance was prepared by CDRH and the Center for Biologics Evaluation and Research (CBER) in consultation with the Center for Drug Evaluation and Research (CDER), the Office of Combination Products (OCP), and the Office of Inspections and Investigations (OII). This collaborative development process is significant.

While the guidance is primarily targeted at medical device manufacturers, the involvement of CDER during its development indicates its relevance and applicability to pharmaceutical companies as well. The software types addressed in the guidance—manufacturing execution systems, laboratory information management systems, document management systems, quality management systems—are common across both industries.

Applicability to Pharmaceutical Companies

Although the CSA Guidance uses terminology and regulatory references specific to medical device regulations (21 CFR Part 820), the underlying principles are directly applicable to pharmaceutical manufacturing. Pharmaceutical companies operating under current Good Manufacturing Practice (cGMP) regulations (21 CFR Parts 210 and 211) use many of the same types of production and quality system software.

In fact, it is critically important that pharmaceutical companies actively transition from CSV to CSA. The benefits of risk-based software assurance—reduced compliance burden, more effective resource allocation, better focus on quality outcomes—are equally valuable in pharmaceutical manufacturing. Companies should view CSA as representing best practices for software assurance regardless of which specific FDA regulations apply to their products.

Harmonization with International Standards

An important regulatory development relevant to CSA implementation is that on February 2, 2024, the FDA issued a final rule amending 21 CFR Part 820 (the device Quality System Regulation) to align more closely with international consensus standards, specifically ISO 13485:2016 (Medical devices – Quality management systems – Requirements for regulatory purposes).

This final rule will take effect on February 2, 2026. Once effective, the rule will withdraw the majority of current requirements in Part 820 and instead incorporate ISO 13485:2016 by reference. This harmonization further supports the risk-based computer software assurance approach and promotes international alignment.

The FDA has indicated that when this final rule takes effect, the CSA Guidance will be updated to ensure consistency with the new regulatory framework. However, the core principles and risk-based approach described in the current guidance will remain valid.

Relationship with GAMP 5

The CSA Guidance is entirely consistent with GAMP 5, and indeed, GAMP 5 does not require revision to align with CSA principles. In July 2022, ISPE published the GAMP 5 Guide, Second Edition, which explicitly incorporates CSA concepts and aligns closely with the FDA’s risk-based approach.

The GAMP 5 Second Edition represents a significant modernization of the original 2008 guidance. Key updates include:

Emphasis on Critical Thinking: The Second Edition strongly emphasizes the importance of applying critical thinking by knowledgeable subject matter experts (SMEs) rather than following rigid, prescriptive processes. This aligns perfectly with CSA’s focus on risk-based decision-making.

Support for Agile and Iterative Development: While GAMP 5 has always supported various lifecycle approaches, the Second Edition explicitly embraces agile, iterative, and incremental software development methodologies. It clarifies that the GAMP specification and verification approach is not inherently linear and fully supports modern development practices.

Increased Emphasis on Supplier Involvement: The Second Edition encourages regulated companies to maximize supplier involvement throughout the system lifecycle, leveraging suppliers’ knowledge, experience, and documentation. This aligns with CSA’s recommendation to leverage vendor testing and documentation where appropriate.

Explicit Discussion of CSA: The GAMP 5 Second Edition includes explicit discussion of the FDA’s CSA approach and demonstrates how GAMP principles support CSA implementation. It provides clear links between GAMP concepts and CSA requirements.

Modern Technologies: The Second Edition includes updated guidance on emerging technologies such as cloud computing, artificial intelligence and machine learning (AI/ML), blockchain, and open-source software. It provides practical advice on applying risk-based validation principles to these technologies.

Data Integrity Integration: Clear links to ISPE/GAMP guidance on data integrity have been incorporated, ensuring that data integrity considerations are woven throughout the system lifecycle.

The synergy between GAMP 5 Second Edition and CSA means that companies following GAMP best practices are well-positioned to implement CSA effectively. Both frameworks emphasize:

• Risk-based approaches over prescriptive checklists
• Critical thinking and quality risk management
• Focus on patient safety and product quality
• Lifecycle approach to system assurance
• Leveraging supplier capabilities
• Appropriate documentation commensurate with risk

Practical Implementation Considerations

Organizations implementing CSA should consider several key factors:

Cultural Shift: Moving from CSV to CSA requires a significant cultural change. Organizations must move away from checkbox compliance mentality toward critical thinking and risk-based decision-making. This requires training, leadership support, and patience as teams adjust to new ways of working.

Risk Assessment Capabilities: Effective CSA implementation depends on robust risk assessment capabilities. Organizations need personnel with appropriate technical knowledge and experience to accurately assess software risk and determine appropriate assurance activities.

Avoiding Over-Classification: A common pitfall is classifying too much software as “high process risk.” This defeats the purpose of the risk-based approach. Organizations should carefully consider the actual consequences of software failure and the effectiveness of compensating controls.

Leveraging Vendor Information: The CSA Guidance explicitly encourages leveraging vendor documentation and testing. Organizations should actively engage with software suppliers to understand what testing and documentation is available and determine how it can be used as part of assurance activities.

Documentation Philosophy: Organizations should focus on creating documentation that provides genuine value—evidence that software has been appropriately assessed and works as intended. Documentation should not be created merely to check compliance boxes.

Lifecycle Perspective: CSA is not a one-time activity but a lifecycle approach. Software must be maintained in a validated state throughout its operational life. This requires effective change control, periodic review, and ongoing monitoring.

Modernization Opportunity: The transition to CSA provides an opportunity to modernize validation practices. Organizations can implement automated testing, adopt digital validation platforms, and streamline processes to improve both efficiency and effectiveness.

Conclusion

The finalization of the FDA Computer Software Assurance Guidance in September 2025 represents a landmark development in regulatory expectations for software used in medical device production and quality systems. After three years of industry engagement and stakeholder input on the 2022 draft, the final guidance provides clear, practical recommendations for implementing a risk-based approach to software assurance.

The CSA framework addresses long-standing challenges with traditional CSV approaches, which have been characterized by excessive documentation requirements and resource consumption without commensurate benefits to product quality or patient safety. By introducing a risk-based methodology that focuses assurance activities where they matter most, CSA enables more effective and efficient software validation.

Several key points merit emphasis:

Broad Applicability: Although developed primarily for medical device manufacturers, the CSA Guidance principles apply equally to pharmaceutical and biological product manufacturers. Any organization using computerized systems as part of cGMP-compliant production or quality operations can and should adopt CSA principles.

Alignment with Industry Best Practices: The CSA Guidance aligns exceptionally well with the GAMP 5 Guide, Second Edition, published in July 2022. Organizations following GAMP best practices are well-prepared for CSA implementation. The consistency between these frameworks demonstrates a convergence of regulatory expectations and industry consensus on modern validation approaches.

International Harmonization: The upcoming harmonization of 21 CFR Part 820 with ISO 13485:2016, effective February 2, 2026, further supports the risk-based approach embodied in CSA and promotes international alignment of quality system requirements.

Paradigm Shift: CSA represents a fundamental shift from compliance-focused, documentation-heavy approaches to quality-focused, risk-based assurance. This shift requires organizations to develop and apply critical thinking, strengthen risk assessment capabilities, and focus on outcomes rather than process adherence.

Practical Benefits: Organizations that effectively implement CSA can expect significant benefits: reduced validation time and costs, more effective allocation of validation resources, faster adoption of new technologies and systems, improved focus on quality and patient safety, and better alignment with business objectives.

Implementation Imperative: The time to begin transitioning to CSA is now. While the guidance is not legally binding (as FDA guidances represent current thinking but not requirements), it clearly indicates the direction of regulatory expectations. Organizations that proactively adopt CSA principles will be better positioned for inspections, better able to justify their validation approaches, and more competitive in an increasingly technology-driven industry.

The CSA Guidance provides a clear path forward for modernizing software validation practices. By embracing risk-based thinking, leveraging available resources including supplier documentation, focusing on testing over excessive documentation, and maintaining a patient safety and product quality perspective, organizations can achieve more effective software assurance with less burden.

For professionals involved in computer system validation, quality assurance, or regulatory compliance in medical device or pharmaceutical manufacturing, understanding and implementing the CSA framework is essential. The guidance provides both the philosophical foundation and practical tools needed to validate software appropriately in today’s complex, rapidly evolving technological landscape.

Author’s Note

For those interested in learning more about the transition from CSV to CSA, detailed training materials and practical implementation guidance are available through various industry resources and professional development opportunities. The shift to CSA represents one of the most significant developments in validation practices in decades and merits careful study and thoughtful implementation.

Organizations should approach CSA adoption strategically, beginning with pilot programs for selected systems, developing internal guidance and training materials, building risk assessment competencies, and gradually expanding the approach across their software portfolio. With proper planning and execution, the transition to CSA can deliver substantial benefits while maintaining or enhancing software quality and regulatory compliance.