The FDA’s evolving approach to software validation for life sciences companies reflects the rapidly changing nature of technology in medical device and highly regulated manufacturing, where manufacturers have expressed desire for greater clarity and more iterative, agile validation approaches.
The September 2025 final guidance formalizes a fundamental shift toward risk-based computer software assurance (CSA) that began in 2022. The new approach balances regulatory compliance with operational efficiency, leans heavily on critical thinking, as well as support from software vendors servicing the industry.
For pharmaceutical and biotech companies managing complex validation requirements, Kneat’s expert team and industry-leading solution help quality assurance and validation teams overcome compliance and operational challenges every day. Understanding the FDA’s CSA framework is essential for organizations seeking to modernize their validation practices while maintaining regulatory compliance.
What is CSA for production and quality system software?
Quick definition
Computer software assurance is a risk-based approach for establishing and maintaining confidence that software is fit for its intended use. Unlike traditional software validation that often requires exhaustive testing at every development stage, this approach considers the risk of compromised safety and/or quality of the device (should the software fail to perform as intended) to determine the level of assurance effort and activities appropriate to establish confidence in the software.
The guidance describes “computer software assurance” as a risk-based approach to establish confidence in the automation used for production or quality systems, and identifies where additional rigor may be appropriate.
Scope and purpose
This guidance provides recommendations regarding CSA for computers or automated data processing systems used as part of production or the quality system for medical devices and highly regulated products. The scope specifically covers:
- Software intended for automating production processes, inspection, testing, or the collection and processing of production data
- Software intended for automating quality system processes, collection and processing of quality system data, or maintaining a quality record
- Cloud computing models (IaaS, PaaS, SaaS) when used as part of production or quality systems
- Automation tools, data analytic tools, artificial intelligence/machine learning tools
- Any system that effects product quality, patient safety, or regulatory compliance
- Note: this may include large systems, such as manufacturing execution systems (MES) or simple databases used to store records.
Out of scope
- Software for general business processes not specific to production or quality systems (email, accounting)
- Infrastructure software not specific to production or quality systems (networking, user authentication, backup and restore)
Regulatory authority
The guidance was prepared by the FDA’s Center for Devices and Radiological Health (CDRH) and Center for Biologics Evaluation and Research (CBER) in consultation with CDER, OCP, and OII on September 24, 2025. The draft was issued on September 13, 2022, and this guidance supersedes Section 6: Validation of Automated Process Equipment and Quality System Software of the Software Validation guidance.
The guidance carries regulatory weight through its connection to quality system obligations including requirements in 21 CFR Part 820, specifically, 21 CFR 820.70(i), which requires manufacturers to validate computer software used as part of production or the quality system for its intended use.
History and key revisions
Through engagement with the Medical Device Innovation Consortium (MDIC), site visits, and benchmarking with other industries, the FDA recognized the potential for technologies including automation, robotics, and digital capabilities to provide significant benefits for enhancing quality, availability, and safety of medical devices.
Looking forward, on February 2, 2024, the FDA issued a final rule amending 21 CFR Part 820 to align more closely with ISO 13485, effective February 2, 2026. This harmonization will further support the risk-based computer software assurance approach.
Kneat perspective: The shift toward risk-based computer software assurance aligns perfectly with modern digital validation approaches. Kneat Gx is purpose-built for life sciences companies to go 100% paperless, accelerating production and lowering costs.
The platform’s flexibility supports both traditional and agile validation methodologies, allowing organizations to create any validation process their way within one complete solution, choosing document or data-centric approaches to build and manage process flows as required.
Key requirements of CSA
Risk-based framework components
The FDA outlines a six-step risk framework for computer software assurance:
1. Identifying the intended use
The regulation requires manufacturers to validate software that is used as part of production or the quality system for its intended use (21 CFR 820.70(i)), including major systems or supporting applications.
The FDA recognizes that software used in production or the quality system is often complex and comprised of multiple features, functions, and operations; software may have one or more intended uses depending on the individual features, functions, and operations. The FDA recommends that manufacturers examine the intended uses of the individual features, functions, and operations to facilitate development of a risk-based assurance strategy.
2. Determining the risk-based approach
The critical determination is whether software poses “high process risk”:
High Process Risk: The FDA considers a software feature, function, or operation to pose a high process risk when its failure to perform as intended may result in a quality problem that foreseeably compromises safety, meaning a medical device risk.
Examples include software that:
- Maintains process parameters affecting physical properties essential to device safety
- Measures, inspects, analyzes and/or determines acceptability with limited or no human review
- Performs process corrections based on automated feedback without human awareness or review
- Produces instructions for use or labeling necessary for safe operation
- Automates surveillance or tracking of data essential to device safety (e.g., cybersecurity) and quality
Not High Process Risk: Software whose failure would not result in a quality problem, or may result in a quality problem that does not foreseeably lead to compromised safety:
- Collects and records data for monitoring and review without direct impact on production performance
- Used for CAPA routing, automated logging/tracking of complaints, change control management, procedure management
- Manages data, automates calculations, increases process monitoring, or provides alerts when exceptions occur
- Used to support production or the quality system
Note: even though software vendors may supply evidence of testing that can be used to validate, it’s ultimately the responsibility of the organization to determine the risk of any given application.
3. Determining appropriate assurance activities
Once the manufacturer has determined whether a software feature, function, or operation poses a high process risk, the manufacturer should identify assurance activities commensurate with said risk.
Testing methodologies:
The guidance describes two primary testing approaches:
Unscripted testing: Dynamic testing in which the tester’s actions are not prescribed by written step-by-step instructions in a test case. These may include:
- Scenario testing: Specification-based test case design technique based on exercising sequences of interactions between the test item and other systems
- Error guessing: A test design technique in which test cases are derived on the basis of the tester’s knowledge of past failures or general knowledge of failure modes
- Exploratory testing: Experience-based testing in which the tester spontaneously designs and executes tests based on existing relevant knowledge, prior exploration, and heuristic “rules of thumb”
Unscripted tests should still have pass/fail recording and align with ALCOA++ data integrity standards.
Scripted testing: Testing in which test cases are recorded and can be executed manually or automatically, with level of detail and evidence depending on the risk.
For high process risk software features, functions, and operations, manufacturers may choose to consider more rigor such as the use of scripted testing or a hybrid approach of scripted testing and unscripted testing, scaled as appropriate.
For software that is not high process risk, manufacturers may consider using unscripted testing methods such as scenario testing, error-guessing, exploratory testing, or a combination.
4. Additional considerations for assurance activities
When deciding on appropriate assurance activities, manufacturers should consider whether there are any additional controls or mechanisms in place throughout the quality system that may decrease the impact if failure of the software were to occur.
Manufacturers can leverage:
- Vendor validation work: The manufacturer could incorporate the software development practices, validation work, and electronic information already performed by developers as the starting point
- Process controls: Activities to reduce cybersecurity exposure, monitoring of critical process parameters, verification testing of all outputs
- Continuous monitoring: Data and information periodically or continuously collected by software for monitoring or detecting issues and anomalies
- Development tools: Tools supporting software development and system life cycle activities (bug tracking, requirement traceability)
- Iterative testing: Testing and results done in iterative cycles and continuously throughout the software life cycle
Vendor assessment:
The FDA recognizes that manufacturers may have limited access to information from the software vendor and recommends manufacturers establish and apply a risk-based analysis of the software vendor. The manufacturer’s assessment may consider:
- Onsite audits of the vendor, if applicable, though the FDA acknowledges it may not be feasible or appropriate
- Review of the vendor’s accreditations and certifications (Service Organization Controls reports, ISO certifications)
- Review of practices and documentation for software development, quality assurance, cybersecurity (security risk assessments, threat modelling, security design reviews, SBOM, testing) and risk mitigation
- Review of data integrity capabilities: retaining records, archiving data, generating accurate copies; securing data at rest and in transit with audit trails and encryption; access controls, electronic signature controls and authorization checks
5. Establishing the appropriate record
When establishing the record, the manufacturer should capture sufficient objective evidence to demonstrate that the software feature, function, or operation was assessed and performs as intended.
Required documentation:
- The intended use of the software feature, function, or operation
- The result of the risk-based analysis
- Documentation of assurance activities conducted, including description of testing, issues found, conclusion statement declaring acceptability, record of who performed testing/assessment and date
- Established review and approval when appropriate
Digital records:
As a least-burdensome approach, the FDA recommends incorporating the use of digital records, such as system logs, audit trails, and other data generated and maintained by the software, as opposed to paper documentation, screenshots, or duplicating results already digitally retained.
The guidance provides detailed examples showing various levels of documentation for different testing types, from robust scripted testing to exploratory unscripted testing.
Electronic records requirements (21 CFR Part 11)
Part 11 sets forth criteria under which the FDA considers electronic records, electronic signatures, and handwritten signatures executed to electronic records to be trustworthy, reliable, and generally equivalent to paper records. Part 11 applies to records in electronic form that are created, modified, maintained, archived, retrieved, or transmitted under any records requirements set forth in Agency regulations.
For computer software used as part of production or the quality system, the applicable predicate rules include those under Part 820. A document required under Part 820 and maintained in electronic form would generally be an “electronic record” under Part 11.
Important Note: The FDA’s enforcement discretion policy regarding validation of computerized systems expressly does not apply to the validation requirement for computer software used as part of production or the quality system arising under 21 CFR 820.70(i).
Manufacturers may utilize the least-burdensome, risk-based approach outlined in this guidance to provide assurance that the software that maintains electronic records subject to Part 11 performs as intended.
Kneat Perspective: Kneat provides data integrity, traceability, and compliance across the entire validation lifecycle, with no other validation system matching Kneat’s robust data integrity controls — ensuring complete accuracy, compliance, and security with automated, tamper-proof records. Kneat ensures data integrity with secure, time-stamped audit trails, role-based access controls, and automated traceability, enhancing compliance and trust in validation processes, directly supporting both the FDA’s computer software assurance expectations and 21 CFR Part 11 requirements.
Why compliance matters
Regulatory penalties and enforcement
While the guidance itself does not create new legally enforceable requirements, compliance with quality system obligations including those in Part 820 is required for manufacturers of finished medical devices and regulated products, including requirements to validate computer software used as part of production or the quality system for its intended use.
Non-compliance with 21 CFR 820.70(i) can result in:
- Warning letters and Form 483 observations
- Consent decrees
- Product recalls
- Import alerts preventing product entry into U.S. commerce
- Criminal prosecution in egregious cases
Business and patient impact
Software that is fit for its intended use and that maintains a validated state should perform as intended, helping to ensure that finished devices will be safe and effective and in compliance with regulatory requirements.
Beyond regulatory compliance, proper computer software assurance:
- Reduces manufacturing errors and product defects
- Prevents costly recalls and remediation
- Protects patient safety
- Maintains market access
- Preserves company reputation
- Enables operational efficiency
The FDA believes that applying a risk-based approach to computer software used as part of production or the quality system would better focus manufacturers’ quality assurance activities to help ensure product quality while helping to fulfil validation requirements.
Kneat Perspective: Organizations implementing Kneat’s platform consistently achieve measurable business impact. Multiple customer case studies show Kneat reduces cycle times by over 50% in every step of the validation lifecycle, from protocol creation to review, approval, test execution, and more. Organizations can reduce validation costs by up to 35% through digitalization, eliminating paper records, enhancing efficiency, and accelerating cycle times for significant savings. These efficiency gains directly support both compliance objectives and business performance.
Step-by-step compliance roadmap
Gap assessment
Step 1: Inventory Software Systems: Create a comprehensive inventory of all computerized systems used in production and quality operations. For each system, document:
- System name and version
- Vendor information
- Current validation status
- Business process supported
Step 2: Evaluate Intended Uses: Examine the intended uses of individual features, functions, and operations to facilitate development of a risk-based assurance strategy. Determine which software:
- Is used directly as part of production or quality system
- Supports production or quality system
- Falls outside scope entirely
Step 3: Conduct Risk Assessment Determine whether each software feature, function, or operation poses a high process risk by assessing if its failure to perform as intended may result in a quality problem that foreseeably compromises safety.
Step 4: Identify Gaps Compare current validation documentation against the FDA’s risk-based framework to identify:
- Over-validated low-risk software
- Under-validated high-risk software
- Missing risk assessments
- Inadequate vendor assessments
- Documentation gaps
Process and technology controls
Implement Risk-Based Testing: Apply principles of risk-based testing in which the management, selection, prioritization, and use of testing activities and resources are consciously based on corresponding types and levels of analyzed risk.
For high process risk software:
- Consider more rigor such as scripted testing or a hybrid approach of scripted testing and unscripted testing, scaled as appropriate
For not high process risk software:
- Consider using unscripted testing methods such as scenario testing, error-guessing, exploratory testing, or a combination suitable for the risk
Establish Vendor Assessment Procedures: Manufacturers should establish and maintain the requirements they have for suppliers within their procedures. These should be on the basis of their ability to meet specified requirements and define the type and extent of control to be exercised.
Leverage Existing Controls: Consider whether there are any additional controls or mechanisms in place throughout the quality system that may decrease the impact of compromised safety and/or quality if failure of the software were to occur.
Documentation best practices
Adopt Digital Records: The FDA recommends incorporating the use of digital records, such as system logs, audit trails, and other data generated and maintained by the software, as opposed to paper documentation, screenshots, or duplicating results already digitally retained.
Maintain Required Elements: Ensure records include:
- Intended use, risk-based analysis results, documentation of assurance activities, issues found, conclusion statement, record of who performed testing and dates, established review and approval when appropriate
Scale Documentation to Risk: Documentation of assurance activities need not include more evidence than necessary to show that the software feature, function, or operation performs as intended for the risk identified.
Ongoing monitoring and audit readiness
Continuous Assurance: Computer software assurance establishes and maintains that the software used in production or the quality system is in a state of control throughout its life cycle (“validated state”).
Manage Changes: The FDA has previously outlined principles for software validation, including managing changes as part of the software life cycle. For production or quality system software changes, follow the risk-based approach to determine appropriate assurance activities.
Prepare for Inspections: Maintain readily accessible documentation showing:
- Risk assessments for all software in scope
- Justification for assurance activities selected
- Evidence that software performs as intended
- Vendor assessments and service agreements
- Change control records
Kneat Perspective: Organizations using Kneat can be audit ready all the time, managing audits in real time and sharing documents instantaneously. Kneat maintains a state of continuous compliance and documentation accuracy to ensure preparedness for regulatory inspections and all forms of audits. The platform’s ability to harmonize validation processes across all sites ensures consistent compliance, streamlined oversight, and improved operational control, making audit preparation significantly more efficient.
Common pitfalls and how to avoid them
Pitfall 1: Over-validating low-risk software
The Problem: Organizations apply the same rigorous validation approach to all software regardless of risk, consuming resources on low-impact systems.
Pro Tip: For software features, functions, and operations not posing high process risk, manufacturers may consider using unscripted testing methods suitable for the risk. Focus intensive validation efforts where they matter most.
Kneat Solution: Kneat gives you the flexibility to configure, create, manage, and optimize validation workflows your way — without code — choosing document or data-centric approaches to build and manage process flows as required, enabling appropriately scaled validation for different risk levels.
Pitfall 2: Inadequate vendor assessments
The Problem: Manufacturers fail to conduct thorough vendor assessments or don’t leverage vendor validation work effectively.
Pro Tip: Establish and apply a risk-based analysis of the software vendor, considering vendor accreditations, certifications, software development practices, quality assurance, cybersecurity documentation, and data integrity capabilities.
Kneat Solution: Organizations can document vendor assessments within Kneat’s platform, maintaining a complete audit trail of vendor evaluation activities and linking vendor documentation to specific validation activities.
Pitfall 3: Ignoring digital record opportunities
The Problem: Companies continue creating manual documentation and screenshots instead of leveraging system-generated evidence.
Pro Tip: As a least-burdensome approach, incorporate the use of digital records, such as system logs, audit trails, and other data generated and maintained by the software.
Kneat Solution: Kneat provides robust data integrity controls with secure, time-stamped audit trails, role-based access controls, and automated traceability, automatically generating the digital evidence required for validation documentation.
Pitfall 4: Treating all features equally
The Problem: Validating entire software systems as monolithic entities rather than evaluating individual features, functions, and operations.
Pro Tip: Manufacturers may decide to conduct different assurance activities for individual features, functions, or operations as related to the intended use.
Kneat Solution: Kneat enables you to digitalize and manage any validation process your way in one easy-to-use solution, making the complex tasks of managing variability and compliance easier, supporting feature-level validation strategies.
Pitfall 5: Insufficient risk justification
The Problem: Organizations don’t adequately document the rationale for determining whether software poses high process risk.
Pro Tip: Document decision-making process for determining whether a software feature, function, or operation is or will be used as part of production or the quality system through the quality management system.
Kneat Solution: Kneat’s workflow capabilities support structured risk assessment documentation, ensuring consistent application of risk criteria across all validation activities.
Pitfall 6: Neglecting cloud-specific considerations
The Problem: Treating cloud-based systems the same as on-premise software without considering unique IaaS, PaaS, or SaaS characteristics.
Pro Tip: When considering cloud computing models, focus on the intended use of the software, as not all cloud models are “directly” used as part of production or the quality system. For IaaS cloud storage solutions, focus assurance efforts on features or functions relevant to the integrity of records and Part 11 requirements applicable to records intended to be stored.
Kneat Solution: Kneat’s cloud-based, scalable system provides real-time insight and traceable data, ensuring data integrity and audit readiness throughout the validation cycle, designed specifically for cloud deployment models.
Pitfall Seven: Missing Part 11 connections
The Problem: Organizations don’t recognize when electronic records fall under Part 11 requirements or assume the FDA’s general enforcement discretion applies.
Pro Tip: Remember that the FDA’s enforcement discretion policy regarding validation of computerized systems expressly does not apply to the validation requirement for computer software used as part of production or the quality system arising under 21 CFR 820.70(i). Determine when a record is required under Part 820 by considering whether the record would be necessary as evidence to document required validation.
Kneat Solution: Kneat’s solution automates and streamlines software validation and quality management, ensuring regulatory compliance with laws such as the FDA’s 21 CFR Part 11, with built-in electronic signature and audit trail capabilities.
FAQs
What is the main goal of Computer Software Assurance for Production and Quality System Software?
Computer software assurance establishes and maintains confidence that software is fit for its intended use and maintains that the software used in production or the quality system is in a state of control throughout its life cycle (“validated state”). The approach follows a least-burdensome approach, where the burden of validation is no more than necessary to address the risk, supporting efficient use of resources while promoting product quality.
Does CSA for Production and Quality System Software apply to SaaS/Cloud systems?
Yes. The regulation requires manufacturers to validate software that is used as part of production or the quality system for its intended use, including various cloud computing models related to computerized systems, such as IaaS, PaaS, and SaaS. However, manufacturers should focus on the intended use of the software when considering cloud computing models, as not all cloud computing models are “directly” used as part of production or the quality system.
For example, an IaaS cloud storage solution used to store quality records established under applicable quality system obligations would be considered used directly as part of production or the quality system, with assurance efforts focused on features relevant to record integrity and Part 11 requirements.
How often is re-validation required under CSA for Production and Quality System Software?
The guidance focuses on maintaining a “validated state” throughout the software life cycle rather than prescribing specific re-validation intervals. By allowing manufacturers to leverage principles such as risk-based testing, unscripted testing, continuous performance monitoring, and data monitoring, as well as validation activities performed by other entities, the computer software assurance approach provides flexibility and agility.
Changes to software should trigger a risk assessment to determine appropriate assurance activities. For devices with approved PMAs or HDEs, manufacturers should apply the principles outlined in the guidance when determining whether a change may affect safety or effectiveness.
Can electronic signatures satisfy CSA for Production and Quality System Software requirements?
Yes, when properly implemented. Part 11 sets forth criteria under which the FDA considers electronic records, electronic signatures, and handwritten signatures executed to electronic records to be trustworthy, reliable, and generally equivalent to paper records. The guidance examples show electronic signature functions as features requiring validation, with documentation including intended use, risk-based analysis, testing performed, issues found, and conclusions.
The key is ensuring the electronic signature function performs as intended and meets Part 11 requirements through appropriate assurance activities commensurate with the risk.
Recent updates and future outlook (2024-2025)
September 2025 Final Guidance
The Computer Software Assurance for Production and Quality System Software guidance was issued in final form on September 24, 2025, after being released in draft on September 13, 2022. This represents the FDA’s most current thinking on risk-based validation approaches for production and quality system software.
The final guidance incorporates stakeholder feedback from the three-year comment period, reflecting ongoing the FDA engagement with stakeholders via the Medical Device Innovation Consortium (MDIC), site visits to medical device manufacturers, and benchmarking efforts with other industries.
Quality system regulation harmonization
On February 2, 2024, the FDA issued a final rule amending the device Quality System Regulation, 21 CFR Part 820, to align more closely with international consensus standards for devices, which will take effect on February 2, 2026. Once in effect, this rule will withdraw the majority of current requirements in Part 820 and instead incorporate by reference the 2016 edition of ISO 13485.
When the final rule takes effect, the FDA will also update this guidance, including references to provisions in Part 820, to be consistent with the rule. This alignment will further support international harmonization while maintaining the risk-based computer software assurance approach.
Industry adoption and evolution
The pharmaceutical and biotech industries continue advancing digital maturity. In recent years, advances in manufacturing technologies, including the adoption of automation, robotics, simulation, and other digital capabilities, have allowed manufacturers to reduce sources of error, optimize resources, and reduce patient risk.
The FDA recognizes the potential for these technologies to provide significant benefits for enhancing the quality, availability, and safety of medical devices, and has undertaken several efforts to help foster the adoption and use of such technologies.
The computer software assurance guidance directly supports this digital transformation by providing clear, flexible expectations that accommodate modern software development and deployment practices.
Looking forward
The FDA believes that these recommendations will help foster the adoption and use of innovative technologies that promote patient access to high-quality medical devices and help manufacturers to keep pace with the dynamic, rapidly changing technology landscape, while promoting compliance with laws and regulations.
Expected trends include:
- Increased adoption of cloud-based validation solutions
- Greater use of automated testing and continuous monitoring
- More sophisticated AI/ML applications in quality systems
- Enhanced cybersecurity integration with validation practices
- Broader international harmonization through ISO 13485
Kneat Perspective: Organizations positioned for the future of validation compliance are investing in platforms that support both current and emerging requirements. Kneat creates value beyond compliance by transforming validation efficiency, ensuring audit readiness, delivering global standardization and reducing costs — helping companies go to market faster, with confidence. As 8 out of 10 of the world’s leading life sciences companies have chosen and trust Kneat for proven validation efficiency and compliance, the platform continues evolving to meet the FDA’s vision for risk-based, digitally enabled computer software assurance.
Ready to modernize your computer software assurance approach?
Kneat provides the world’s most developed validation software solution, backed by a comprehensive expert team and technology, making validation faster, easier, and smarter for Life Sciences.
