On September 24, 2025, the U.S. Food and Drug Administration (FDA) released its final guidance document “Computer Software Assurance for Production and Quality System Software” (CSA Guidance, Docket No. FDA-2022-D-0795). This long-awaited publication offers manufacturers a modernized, risk-based framework for establishing confidence in software used in production and quality systems.
The new guidance supersedes Section 6 of the FDA’s earlier document, “General Principles of Software Validation,” and reflects the agency’s evolving vision: shifting away from a rigid, documentation-heavy approach to one that emphasizes intended use, process risk, and the impact on patient safety.
By introducing this framework, the FDA aims to reduce unnecessary validation burden, support adoption of emerging technologies, and help manufacturers ensure compliance with the Quality System Regulation (21 CFR Part 820), soon to be harmonized with ISO 13485:2016 in February 2026.
Summary on FDA’s CSA Guidance 2025
| Area | Key Points | Practical Takeaway |
|---|---|---|
| Purpose | Modernize software assurance for production & quality systems | Focus on risk, not paperwork |
| Scope | Applies to production/quality software, incl. cloud; excludes device software & business tools | Evaluate intended use before applying CSA |
| Framework | Six elements: Intended Use → Risk Approach → Changes → Assurance Activities → Considerations → Record | Scale effort to risk, document rationale |
| Testing | Scripted for high risk, exploratory/unscripted for low risk | Mix methods, justify choices |
| Part 11 | Applies to predicate rule records; enforcement discretion continues, but CSA still required | Avoid over-applying Part 11; focus on relevant records |
| Implications | Greater reliance on vendors, more agile testing, audits focus on rationale | Train teams to explain risk decisions |
| Best Practices | Map intended use, classify risk, align assurance, strengthen vendors, leverage digital evidence, train teams | Build CSA into QMS for 2026 ISO 13485 transition |
Background and Rationale
FDA’s move toward Computer Software Assurance (CSA) is rooted in the rapid evolution of digital technologies used in medical device manufacturing.
Over the past decade, manufacturers have increasingly relied on automation, robotics, cloud computing, and advanced analytics to reduce errors, optimize resources, and improve product consistency. While these tools create clear benefits, they also introduce new layers of complexity that traditional software validation methods were not designed to handle.
Historically, computer software validation was driven by heavy documentation and scripted testing at each stage of the development lifecycle. Although this approach helped establish compliance, it often resulted in excessive effort spent on low-risk systems while leaving limited flexibility to address high-risk features more effectively.
The CSA guidance reflects the FDA’s response to this feedback. By formalizing a risk-based approach to software assurance, the agency aims to:
- Focus validation efforts where failure could compromise product quality or patient safety
- Allow more flexibility for supporting systems and low-risk tools, reducing unnecessary validation burden
- Provide clarity on the use of cloud models (IaaS, PaaS, SaaS) and vendor-supplied assurance activities
- Encourage manufacturers to leverage unscripted testing, exploratory testing, and continuous monitoring alongside traditional scripted testing.
| Aspect | Traditional Validation (CSV) | CSA (Final 2025 Guidance) |
|---|---|---|
| Focus | Documentation-heavy, scripted testing | Risk-based, proportional assurance |
| Testing | Predominantly scripted, repeatable cases | Mix of scripted + unscripted (scenario, exploratory, error guessing) |
| Scope | Equal rigor applied across all systems | Rigor scaled to risk of intended use |
| Burden | High, often excessive for low-risk systems | Reduced, “least burdensome” evidence encouraged |
| Records | Paper-heavy, screenshots, duplicate logs | Digital evidence (audit trails, logs, vendor documentation) |
Scope
The CSA guidance applies to computers and automated data processing systems used in the production of medical devices or as part of the quality system. This includes both software that directly controls or monitors production processes and software that supports quality-related activities.
Key inclusions under the guidance:
- Direct use software: Systems that automate production processes, inspections, testing, or quality records. Examples include Manufacturing Execution Systems (MES), automated inspection tools, or software controlling critical process parameters.
- Supporting software: Tools used to facilitate testing, monitor performance, or manage records that are part of the quality system. Examples include debugging tools, reporting software, or spreadsheet applications configured for production data.
- Cloud-based solutions: IaaS, PaaS, and SaaS applications, when they are used for production or quality system purposes. The assurance effort should focus on the functions that impact record integrity and compliance with 21 CFR Part 11.
Key exclusions:
- Device software functions that themselves qualify as a regulated medical device under section 201(h) of the FD&C Act are outside the scope of this guidance.
- General business software (e.g., email clients, accounting tools, or HR platforms) and infrastructure applications (e.g., networking or backup systems) not tied to production or quality system records are also excluded.
The guidance does not replace FDA’s earlier General Principles of Software Validation, but rather extends and adapts its risk-based validation principles specifically to production and quality system software. The focus is on establishing a proportionate level of assurance throughout the software lifecycle while avoiding unnecessary duplication of effort.
Key Definitions
To support consistent application, the CSA guidance introduces and clarifies several important terms. These definitions set the foundation for how manufacturers should interpret and implement the risk-based framework.
Computer Software Assurance (CSA): A risk-based approach for establishing and maintaining confidence that software used in production or quality systems is fit for its intended use. CSA goes beyond testing alone, encouraging manufacturers to leverage methods such as unscripted testing, vendor evidence, and continuous monitoring while scaling rigor according to risk.
Process risk: The potential for software failure to compromise production or quality system performance.
Medical device risk: The potential for such a failure to compromise patient or user safety. The guidance emphasizes that not all process risks translate into medical device risks, but where they do, a higher level of assurance is expected.
Intended Use: The role of a software feature, function, or operation within production or the quality system. FDA distinguishes between:
- Direct use: e.g., automating inspection or controlling process parameters
- Supporting use: e.g., debugging tools, test automation scripts, or general recordkeeping that supports the system but is not itself a quality record
- Non-applicable use: general business or infrastructure software not tied to production/quality (e.g., email, HR systems)
Cloud Computing (NIST-aligned definition)
On-demand access to shared computing resources delivered as:
- Software as a Service (SaaS): Applications provided and managed by the vendor.
- Platform as a Service (PaaS): Environments for deploying custom applications.
- Infrastructure as a Service (IaaS): Provisioned storage, networking, or computing resources.
Deployment models (public, private, hybrid, community) fall under CSA when used for production or quality system functions.
These definitions ensure that assurance activities are tailored to the actual role and risk of the software, rather than applying the same validation burden across all systems.
The CSA Risk Framework
At the core of the FDA’s guidance is a risk-based framework for assuring that software used in production and quality systems is fit for its intended use and remains validated throughout its lifecycle.
The framework encourages manufacturers to scale assurance activities according to risk, avoiding unnecessary burden while maintaining robust controls where safety or quality could be compromised.
The framework consists of six interrelated elements:
Identifying the Intended Use
Manufacturers must first determine whether software is used as part of production or the quality system.
- Direct use software includes systems that automate processes, inspections, or quality records (e.g., MES, automated inspection tools).
- Supporting software includes tools that facilitate testing or monitoring but do not directly control quality outcomes (e.g., spreadsheets for data collection, debugging tools).
- Non-applicable software includes business or infrastructure systems not tied to production/quality (e.g., HR, email).
The level of assurance depends on the specific feature, function, or operation within the software. A single system may contain both high-risk and low-risk components, requiring differentiated approaches.
| Category | Description | Examples | Assurance Rigor |
|---|---|---|---|
| Direct Use | Software automating production processes or controlling quality records | MES, automated inspection systems | High → risk-based assurance, scripted tests |
| Supporting Use | Tools facilitating testing, monitoring, or recordkeeping | Debuggers, spreadsheets, reporting software | Moderate → exploratory testing, vendor reliance |
| Non-Applicable | General business or infrastructure systems not tied to production/quality | Email, HR, accounting software | None (outside CSA scope) |
Determining the Risk-Based Approach
Once intended use is established, manufacturers must perform a risk-based analysis.
- High process risk: A failure could create a quality problem that foreseeably compromises safety (e.g., software controlling sterilization cycles or process parameters).
- Not high process risk: A failure may cause disruption or quality issues but does not foreseeably compromise safety (e.g., a CAPA routing tool or training notification system).
The analysis should focus on reasonably foreseeable failures and their consequences, considering both process risk and medical device risk.
| Risk Level | Criteria | Example | Assurance Activities |
|---|---|---|---|
| High Process Risk | Failure could compromise safety or product quality | Software controlling sterilization cycle | Scripted + exploratory testing, vendor audits, full records |
| Not High Process Risk | Failure unlikely to impact safety; may disrupt workflow or data | LMS training notifications | Exploratory testing, supplier evaluation, minimal documentation |
Production or Quality System Software Changes
Changes to software must also be evaluated under this framework.
- For devices with approved PMAs or HDEs, changes that may impact safety/effectiveness require a 30-day notice to FDA.
- Lower-risk changes may be included in annual reports.
- Example: A Manufacturing Execution System (MES) update that only affects workflow tracking is considered lower risk; an MES update that changes the automated control of critical parameters is considered high risk and requires greater regulatory scrutiny.
Determining Assurance Activities
The guidance outlines different types of testing and verification, scaled according to risk:
- Unscripted testing (scenario testing, exploratory testing, error guessing) → suitable for lower-risk functions.
- Scripted testing (step-by-step, repeatable, traceable test cases) → expected for high-risk functions, often in combination with unscripted methods.
- Hybrid approaches: Combining exploratory and scripted testing where appropriate.
Manufacturers are encouraged to adopt risk-based testing principles: allocate rigor and resources in proportion to the risk posed by the software feature.
Additional Considerations
Manufacturers should also consider:
- Vendor assurance: Evaluating suppliers through audits, certifications (e.g., ISO, SOC reports), or vendor documentation.
- Process controls: Leveraging inspection, monitoring, or redundant checks already in place.
- Cybersecurity: Incorporating security testing and controls for systems with network exposure.
- Digital evidence: Using system logs, audit trails, and automated records instead of duplicating paper documentation.
Supporting tools (e.g., debuggers, parameterization software) generally require only a least-burdensome assurance approach when not directly part of the quality system.
Establishing the Record
For each assurance activity, manufacturers should maintain sufficient documentation to demonstrate fitness for intended use. A complete record typically includes:
- The software’s intended use
- The risk-based analysis and classification
- A summary of assurance activities (test type, objectives, results, deviations)
- Conclusion of acceptability, including risk justification or corrective actions
- Identification of who performed the activity, when, and approval signatures where appropriate
FDA emphasizes that documentation should be no more than necessary to demonstrate assurance. Digital records (logs, audit trails, automated test outputs) are encouraged over screenshots or duplicate paperwork.
The CSA risk framework allows manufacturers to tailor their assurance strategy, focusing effort where it matters most while reducing unnecessary burden on low-risk software.
Electronic Records & Part 11 Considerations
A recurring challenge for manufacturers has been determining when 21 CFR Part 11 (Electronic Records; Electronic Signatures) applies to production and quality system software. The CSA guidance clarifies this point and connects it directly to the risk-based assurance approach.
When Part 11 Applies
Part 11 applies to electronic records that are:
- Created, modified, maintained, archived, retrieved, or transmitted under predicate rules such as Part 820.
- Submitted to FDA under the FD&C Act or Public Health Service Act.
- Required to bear signatures under Part 820, if those signatures are captured electronically.
In these cases, electronic records must be trustworthy, reliable, and equivalent to paper records and handwritten signatures.
When Part 11 Does Not Apply
Not all software-generated data falls under Part 11. For example:
- Required documentation (e.g., records demonstrating that an MES correctly automates material checks) → Part 11 applies.
- Routine system logs that are not necessary to demonstrate validation or product quality → Part 11 does not apply.
This distinction is important, as it helps manufacturers avoid over-applying Part 11 controls to data that is not regulatory evidence.
Enforcement Discretion vs. CSA Requirements
The FDA has historically applied enforcement discretion for certain aspects of Part 11 (e.g., the validation of computerized systems for record-keeping). However, this policy does not replace or eliminate the requirement under 21 CFR 820.70(i) to validate software used in production or quality systems for its intended use.
In other words, CSA principles apply fully, even if Part 11 enforcement discretion reduces the burden on certain electronic recordkeeping requirements.
Practical Takeaway
Manufacturers should:
- Identify which electronic records are predicate rule records and therefore subject to Part 11
- Apply CSA’s risk-based assurance to demonstrate that those systems reliably maintain record accuracy, integrity, and authenticity
- Leverage the least-burdensome documentation methods (digital logs, audit trails, electronic signatures) where appropriate
By aligning CSA activities with Part 11, firms can reduce ambiguity and streamline compliance, ensuring electronic records remain both regulatory-compliant and proportionate to actual risk.
Practical Examples from the Guidance
To make the CSA framework more tangible, the FDA’s guidance includes several real-world scenarios. These examples demonstrate how manufacturers can scale assurance activities according to the intended use and process risk.
Example 1: Nonconformance Management System
- Intended Use: Automating nonconformance initiation, electronic signatures, and product containment decisions.
- Risk Analysis:
- Initiation operations → Not high process risk, since other containment processes are in place.
- Product containment function → High process risk, as failure could prevent necessary recalls or corrections.
- Assurance Activities:
- For low-risk functions: exploratory testing + vendor assessment.
- For high-risk functions: scripted testing, repeatability checks, and detailed records.
- Lesson: Even within one system, assurance rigor varies based on the risk profile of each function.
Example 2: Learning Management System (LMS)
- Intended Use: Managing training assignments, user notifications, and training records.
- Risk Analysis: Failure affects training records but does not directly compromise patient safety → Not high process risk.
- Assurance Activities: Supplier evaluation + scenario testing with users to confirm correct functionality.
- Lesson: Common quality tools like LMS are low risk; assurance can be minimal if vendor capability and installation checks are sound.
Example 3: Business Intelligence (BI) Applications
- Intended Use: Analyzing and reporting production/quality data.
- Risk Analysis: Incorrect reports may affect decision-making but do not directly alter process parameters → typically Not high process risk.
- Assurance Activities: Exploratory testing of reporting functions, verification of data accuracy, and reliance on vendor documentation.
- Lesson: Data analysis tools require evidence of reliability, but scripted validation is not always necessary.
Example 4: SaaS Product Lifecycle Management (PLM) System
- Intended Use: Managing product lifecycle data, supplier inputs, and design records in a cloud-based environment.
- Risk Analysis: Depends on features used; design records impacting compliance or device safety can present high process risk.
- Assurance Activities:
- Vendor assessment (e.g., SOC reports, certifications)
- Testing of critical workflows
- Digital audit trails for electronic records
- Lesson: Cloud-hosted systems demand robust vendor management and risk-based assurance of critical features.
Key Takeaways from FDA’s Examples
- Assurance scales within the same system: not all features require the same level of rigor.
- Vendor evaluations are central to CSA, especially for cloud-based or COTS solutions.
- Exploratory and unscripted testing play a legitimate role, especially for lower-risk features.
- Records must reflect proportionality: enough evidence to support assurance, without unnecessary duplication.
Implications for Manufacturers
The final CSA guidance marks a significant shift in how the FDA expects companies to approach software assurance within production and quality systems. While the underlying requirement to validate software for its intended use remains unchanged, the path to demonstrating compliance is now more flexible and risk-driven.
Rebalancing Validation Efforts
Manufacturers can redirect resources away from exhaustive testing of low-risk systems toward more robust assurance of high-risk features. This not only improves efficiency but also aligns quality efforts more closely with patient safety priorities.
Audits and Inspections Will Evolve
FDA inspectors are likely to scrutinize:
- How manufacturers classify software features as high or not high process risk.
- Whether assurance activities are proportionate to the risk identified.
- The documentation trail: was the rationale well-justified, and are digital records reliable and complete?
Firms should be prepared to explain their decision-making logic as much as their test results.
Increased Reliance on Vendors
Vendor management becomes a cornerstone of compliance, especially for cloud-hosted systems (SaaS, PaaS, IaaS) and COTS solutions. Supplier evaluations, certifications, and cybersecurity assurances will carry more regulatory weight.
Shift Toward Agile and Modern Testing Practices
CSA explicitly acknowledges methods such as exploratory testing, scenario testing, and continuous monitoring. Manufacturers who have felt constrained by scripted-only validation can now adopt more agile, iterative approaches, provided the risk justification is documented.
Integration with ISO 13485 Transition
With 21 CFR Part 820 aligning with ISO 13485:2016 in 2026, manufacturers can utilize CSA principles to harmonize their software assurance practices with international expectations, thereby easing the burden of global compliance.
Cultural Change in Quality Systems
Perhaps most importantly, CSA encourages a mindset shift: from viewing validation as a paperwork exercise to treating assurance as a dynamic, risk-informed process. This requires training teams to think critically about the intended use, risk, and proportionality, rather than merely ticking boxes.
Best Implementation Practices
Adapting to the CSA guidance requires more than updating SOPs; it involves embedding risk-based thinking into everyday quality and IT processes. Manufacturers can start by focusing on these practical steps:
- Map Intended Use Clearly
- Break down software by feature, function, or operation.
- Distinguish between direct use, supporting use, and non-applicable business software.
- Classify Risk Proportionately
- Apply the guidance’s high vs. not high process risk distinction.
- Document how failures could impact product quality or patient safety.
- Align Assurance Activities with Risk
- Reserve scripted, detailed testing for high-risk features.
- Use exploratory or scenario testing for lower-risk functions.
- Leverage vendor testing and certifications where appropriate.
- Strengthen Vendor Oversight
- Incorporate supplier assessments, audits, and certification reviews.
- Establish risk-based controls for cloud services and COTS software.
- Leverage Digital Evidence
- Use logs, audit trails, and automated test outputs instead of duplicating paper documentation.
- Ensure digital records meet integrity, authenticity, and availability standards.
- Train Teams in CSA Principles
- Shift validation culture from documentation-heavy to risk-focused.
- Encourage quality and IT staff to apply critical thinking rather than box-checking.
Conclusion & Outlook
The FDA’s final CSA guidance (September 2025) represents a pivotal step in modernizing software assurance. By focusing on intended use, proportional risk, and fitness for purpose, manufacturers can direct their efforts where they matter most—on functions that could compromise product quality and patient safety.
For manufacturers, this is both an opportunity and a challenge. Those who embrace CSA can expect to reduce unnecessary validation burden, adopt digital technologies more confidently, and align with the upcoming ISO 13485 integration.
At the same time, success depends on robust documentation of risk assessments, effective vendor oversight, and a cultural shift toward risk-based assurance.
