In this piece, we outline considerations for applying computer software assurance (CSA ) to manufacturing software.  

Traditionally, validating computer software has relied on Computer Software Validation (CSV) techniques that can be burdensome as organizations focus more on documentation than risk. That approach, however, is becoming less practical as manufacturers adopt more complex software platforms and manage more frequent system changes. In response, the industry is increasingly moving toward Computer Software Assurance (CSA) for validating computerized systems.

The FDA has provided guidance on CSA, a risk-based approach to validation for production and quality system software that complements conventional validation principles rather than replacing them. The guidance also emphasizes that test method selection should be driven by risk and intended use, with consideration for existing controls.

Below, we discuss how life sciences organizations can apply CSA across different manufacturing software environments, from configuration and validation to live production and ongoing system support. 

Introduction to CSA 

As cloud-based systems and modern software environments continue to evolve, traditional CSV approaches that emphasize extensive scripted testing and documentation are being supplemented by the FDA’s CSA framework. This shift also aligns with broader regulatory harmonization efforts, including the FDA’s Quality Management System Regulation (QMSR), which became effective on February 2, 2026, and incorporates ISO 13485:2016 into the medical device quality framework. 

CSA’s risk-based approach emphasizes prioritizing testing software systems that may impact product quality, patient safety, data integrity, and regulatory compliance. Instead of applying the same level of testing to every function, CSA helps teams focus effort where risk is highest and avoid unnecessary over testing of lower-risk areas.  

For manufacturing software, this distinction matters. A system function used only in a configuration or test environment may not require the same level of assurance as a function used to calculate batch quantities or support batch release decisions in a live production environment. CSA gives manufacturers a practical way to scale assurance activities based on how software is used, where it’s used, and what could happen if a function fails. 

Why CSA Matters Across Manufacturing Software Environments 

Software-as-a-Service (SaaS) systems can evolve quickly, including Manufacturing Execution Systems (MES), Enterprise Resource Planning (ERP) platforms, and Laboratory Information Management Systems (LIMS), and may present validation concerns.  Companies need to be able to support system updates without slowing down critical manufacturing operations. This can feel difficult when traditional CSV techniques are used to validate system functionality broadly, regardless of risk. 

Instead, CSA allows companies to support faster software implementation and updates through a risk-based approach that prioritizes critical system functions. For example, manufacturers may reduce assurance effort for lower-risk changes, such as minor user interface updates or non-critical reporting functions, while applying more rigorous assurance activities to functions that directly affect product quality or patient safety. 

The goal isn’t to test less for the sake of speed but rather to test in a way that reflects actual system risk. By applying CSA across manufacturing software environments, organizations can make defensible decisions about what evidence is needed and where assurance effort should be focused. 

Applying CSA Across Manufacturing Software Environments  

The application of CSA should be informed by how software is used and the environment in which it operates. As software progresses from development and configuration into validation and production, assurance activities should reflect the system’s intended use. The same risk-based thinking applies to ongoing maintenance and support.  

1. Development and Configuration  

Development and configuration environments are typically fast paced and flexible. Teams may be building workflows or testing system settings as they evaluate how software will support manufacturing activities. In these environments, CSA can support a lighter assurance approach when the software doesn’t directly impact product quality, patient safety, or data integrity. 

During this stage of system work, the focus should be on understanding how the software behaves and identifying which functions may require more rigorous assurance later. Lower-risk activities may be supported through vendor documentation reviews, configuration walkthroughs, ad hoc testing, or unscripted testing when those methods are appropriate.  

Traditional CSV activities may be adjusted through CSA approaches such as: 

• Scripted test protocols (IQ/OQ/PQ) → Risk-based testing, including unscripted or exploratory methods when appropriate for the intended use 
• Full system regression or re-testing → Targeted testing based on the risk of affected functions 
• Formal, end-to-end validation testing → Scenario-based verification aligned to system use and risk 

In these environments, the value of CSA is flexibility – teams can document why a lighter approach is appropriate while reserving more structured testing for functions with meaningful quality impact. 

2. Test and Validation 

Test and validation environments are where teams begin building objective evidence that software is fit for its intended use. CSA helps teams determine which functions require scripted testing and which may be supported by prior evidence or less formal testing methods. 

For example, a workflow that supports batch record review may need structured testing because it can affect quality decisions. A formatting update to a non-critical report may only require documented confirmation, depending on its intended use and risk. 

In these environments, manufacturers should focus on connecting assurance decisions to risk. The level of evidence should reflect what the function does, how it will be used, and what could happen if it fails. This helps teams avoid applying the same testing burden to every function while still maintaining confidence in the system.  

3. Production 

In production manufacturing environments, software may directly support manufacturing execution, quality review, material control, or batch release. CSA activities should be more structured when a system function can affect product quality, patient safety, or data integrity. 

For example, if an MES system is used to calculate batch ingredient quantities or electronically approve batch release for a commercial drug product, manufacturers would typically perform more rigorous assurance activities. Depending on the function’s intended use and risk, those activities may may include scripted testing, role-based access verification, audit trail review, or electronic signature testing. 

That added rigor is appropriate because errors in these functions could result in incorrect product formulation or data integrity concerns. In some cases, a failure could contribute to the release of nonconforming product. In a live production environment, CSA helps teams justify the level of assurance selected by connecting that decision to intended use and risk. 

4. Support, Maintenance, and Change 

Once a system is in use, manufacturers need a practical way to assess updates, patches, configuration changes, and vendor releases. CSA is especially useful in support and maintenance environments because not every change carries the same risk. 

A minor user interface change may require limited verification, while a change to a calculation or data exchange may require more formal testing. CSA helps teams evaluate what changed and what the change could affect, then determine what evidence is needed before release. 

This is especially important for SaaS platforms that may upgrade multiple times a year. Rather than treating every vendor release as a full revalidation event, teams can assess each change based on intended use, potential impact, and existing controls. This makes it easier to maintain system confidence without creating unnecessary testing burden. 

Challenges and Best Practices 

Without evaluating every feature of manufacturing software, it can be difficult to know whether a system has been adequately assessed for integrity and compliance. That concern is understandable, given the level of scrutiny the FDA applies during audits of regulated environments.  

While CSA allows for a risk-based approach, organizations may still face challenges determining the appropriate level of testing and documentation. Teams also need to maintain confidence in system integrity without creating unnecessary assurance work.  

Here are some best practices to help combat these challenges: 

• Use critical thinking to make and document risk-based assurance decisions 
• Focus assurance activities on functions where failure presents greater risk 
• Scale testing and documentation to the function’s intended use and risk 
• Leverage existing knowledge and prior evidence when and where applicable 

Final Thoughts 

CSA gives manufacturers a more practical and flexible way to establish confidence that software is fit for its intended use while maintaining appropriate quality and compliance controls. By aligning assurance activities with risk, teams can focus their effort on the software functions where failure could have the greatest impact. 

To discuss how CSA approaches can support your manufacturing systems or validation strategy, connect with our team today.