What is Computer Software Assurance (CSA)? How Lab Leaders Can Transform Validation Processes

As of 2022, the FDA published guidance for Computer Software Assurance (CSA) to define a new “risk-based” approach to audit systems and software in labs. 

This change has been coming for some time. However, publishing guidance signals a pivotal shift in how regulated labs validate their systems — one that promises to cut its documentation burden while strengthening focus on what truly matters: patient safety and data integrity.

For life sciences and manufacturing labs still following CSV best practices, this may seem like an abrupt change in direction and even raise alarm bells along with concerns of lengthy process changes. 

In this guide, we’ll explain what CSA is, how to adapt your audit and testing workflows to it and show how it can empower your lab’s compliance processes.

What is Computer Software Assurance?

For years, labs have followed Computer System Validation (CSV) guidelines to audit all computerized systems and software. As you can imagine, validating each computerized system can be a time-consuming process –  especially for life sciences labs that heavily utilize software in their processes.

Computer Software Assurance (CSA) is a modern, risk-based approach to validating computerized systems that focuses on critical thinking and patient safety rather than extensive documentation. While CSV often results in 80% of your time documenting processes, with 20% of your time actually spent testing, CSA flips it: 80% of your time should be spent on critical thinking and testing, while 20% should be spent on documentation. 

CSA emphasizes testing what matters most based on risk assessment. For instance, under CSA, a laboratory implementing a LIMS might concentrate its validation efforts on high-risk functions that directly impact patient safety or data integrity while applying less rigorous testing to lower-risk features, resulting in a more efficient validation process.

Is CSA Mandatory for Labs?

Following Computer Software Assurance guidelines is not mandatory, but it is strongly recommended in order to meet compliance requirements. While shifting your lab’s processes takes work, it’s worth it for the following reasons:

• The FDA recommends CSA as a more modern approach to testing and auditing your systems. 
• The underlying principles of a risk-based approach support other FDA regulations like 21 CFR Part 11. 
• CSA affords your lab more flexibility in how it approaches software validation, which frees up time in the long run. 

Read on for a breakdown of how to perform a risk-based approach to testing in your lab.

How to Measure/Understand Risk

High-risk and low-risk are dangerously subjective terms, so you’re in good company if the thought of judging the risk of software functions gives you pause.

Fortunately, the FDA does provide some guidance here. The FDA considers a software feature/function to be high-risk if its failure to perform as intended results in a quality problem that compromises safety. This includes things like features that:

• Maintain process parameters (e.g., temperature, pressure, or humidity) that affect the physical properties of critical product or manufacturing processes.
• Measure, inspect, analyze, and/or determine the acceptability of a product or process with limited/no human review.
• Produce directions for use or other labeling provided to patients and users that are necessary for the safe operation of the product.
• Automate surveillance or tracking data that the manufacturer identifies as essential to medical device safety/quality. 

Lower-risk processes, according to the FDA, cover software features and functions that would not result in a quality problem that foreseeably compromises safety but are still worth documenting and testing.

How to Perform a Risk-Based Approach to CSA

Rather than create a validation plan that treats each system equally, a lab that wishes to follow CSA guidelines would work through the following phases:

• Risk assessment and categorization
• Perform high, medium, and low risk testing
• Use varied testing methods
• Continuous risk evaluation

Risk Assessment and Categorization

The first step of CSA is to begin with risk assessment and categorization by thoroughly analyzing each function.

For example, a lab implementing a new LIMS would start by identifying sample accessioning as high-risk because errors could lead to misidentification of patient samples and potentially harmful treatment decisions. Their risk assessment documentation would explain this critical relationship between correct sample identification and patient outcomes, justifying the high-risk classification. This is important because the lab will allocate more time, testing, and resources to higher-risk activities rather than treat each aspect of the LIMS equally (we’ll share how to handle medium and low-risk functions later).

Perform High, Medium, and Low-Risk Testing

For high-risk functions, you must run and document the most tests to demonstrate quality. 

Using our hypothetical lab example that identified sample accessioning as high risk, the next steps they would take is to verify that barcodes are correctly generated and read, that unique identifiers are never duplicated, and that sample information remains intact throughout the workflow. They would then need to document this testing with formal test scripts, expected results, actual outcomes, and deviation records to provide evidence of proper function for this critical process. Focusing on high-risk activities first allows your lab to go deeper into tests that matter before moving on to medium-level risks. 

Medium and low-risk functions will require comparatively less testing and documentation. In some cases, documentation could be a simple screenshot of expected results with supporting notes.

Use Varied Testing Methods

As you can see, different risk levels will require different levels of testing. It’s important to take a varied approach to testing so that your methods are appropriate to each function’s risk level.

This could include:

• Automated scripts
• Detailed notes
• Screenshots

A varied approach to testing focuses your lab’s resources where they matter most for data integrity.

Continuous Risk Evaluation

Finally, your lab should establish a plan for continuous risk evaluation of its systems. 

CSA is an ongoing process, not a one-and-done activity. Make sure to review your systems after updates to assess whether functions have changed in ways that alter their risk profiles. This includes feature changes or new features, as well as new workflows that your team builds. With each evaluation, run through the risk assessment and test-writing process accordingly.

Scripted vs. Unscripted Testing in CSA

A fundamental shift in CSA is the approach to testing methodology, which varies based on risk levels. CSA introduces two primary testing approaches:

Scripted Testing involves formal, documented test protocols with predefined steps, inputs, and expected results. This approach includes:

• Robust scripted testing: Comprehensive documentation of test cases with detailed steps, expected outcomes, and formal evidence collection
• Limited scripted testing: A streamlined version that maintains structure but with reduced documentation requirements

Unscripted Testing allows for more flexible, creative approaches to verification without rigid documentation. This includes:

• Ad-hoc testing: On-the-spot testing based on tester knowledge and intuition
• Error-guessing: Testing based on experience with common failure modes
• Exploratory testing: Simultaneous test design and execution that adapts as the tester learns about the system

CSA encourages using unscripted testing for low-risk functions while reserving more rigorous scripted testing for high-risk functions. This is a significant departure from CSV, which typically required scripted testing for all functions regardless of risk level.

By matching the testing methodology to the risk level, your lab can focus its validation efforts where they matter most, saving time and resources while maintaining compliance and quality.

Benefits of CSA Over CSV

CSA allows for a nuanced approach to verifying your systems that gives your lab flexibility and control over its testing. This nuance leads to a more efficient use of time and resources, along with these other benefits:

• More flexible: Greater flexibility in testing methodologies allows laboratories to select appropriate validation approaches based on risk. Instead of applying rigid, script-driven testing universally, teams can employ automated testing, ad hoc testing with screenshots, or leveraging vendor documentation where appropriate, making the validation process more adaptable.
• Reduced paperwork: Reduced documentation burden significantly decreases the paperwork associated with validation. Rather than generating extensive test scripts and results for every system function, CSA encourages documenting the critical thinking process and focusing detailed documentation only on high-risk areas, cutting unnecessary administrative overhead.
• Quicker implementation: Faster implementation timelines result from the streamlined approach. With less emphasis on exhaustive documentation and more focus on critical functions, organizations can validate and deploy systems more quickly, accelerating time-to-value without compromising quality or compliance.
• Agile: Better alignment with modern software development practices is another advantage. CSA accommodates agile development methodologies and continuous delivery models better than traditional CSV, making it more compatible with how software is actually developed and maintained today.

Common Challenges You May Face When Implementing CSA

With any process change, there will be speed bumps along your road to implementation. The most common challenges you can expect to face are:

• Internal resistance – your staff will be used to the “way things are done” and may resist change (even though this change will make things easier in the long run).
• Trouble developing a risk framework – while the nuance of CSA is freeing, it also puts the onus on your lab to judge what is higher risk and lower risk, which can be a hurdle.
• Balancing testing with documentation – while CSA reduces documentation requirements, labs still need sufficient records to demonstrate compliance during audits. Finding the right balance can be challenging, especially when teams are used to extensive documentation.

With time and practice, your lab can overcome each of these challenges. It’s important to remember that CSA emphasizes an agile approach, which gives you the freedom to evolve your testing methods and prioritization as time goes on.

CSA is One Piece of Lab Compliance. Download Our Lab Compliance Checklist For the Rest

Computer Software Assurance gives labs the ability to take a nuanced and risk-based approach to validating their software and systems.

But understanding CSA is just one piece of a compliant lab. For the rest, we recommend you download our lab compliance checklist. 

In this checklist we break down the steps you can take to meet common lab regulations along with recommendations for software products to support your lab in meeting them. Fill out the form below to get the free guide and take a step toward better data and compliance.

‍