Understanding the FDA’s Final CSA Guidance

Could you provide an overview of the FDA’s Final CSA Guidance and what this means for the pharmaceutical industry? What’s changed from the old CSV approach?

Traditional CSV is very rigorous and documentation-heavy.  Test scripts typically consist of very detailed formal step-by-step instructions to test every functional area.  Screenshots are often taken, sometimes at nearly every step, leading to even more documentation to review and maintain.  We often joked that we were being “paid by the pound of paperwork produced” as we filled up one large three ring binder after another with the aim of impressing future auditors and regulatory inspectors with our meticulous documentation and pretty paperwork.  But were we really testing the system sufficiently?

CSV scripts are typically executed by test engineers or validation engineers against specific requirements.  Script errors and deviations are common due to typographical errors and the likelihood of last-minute system updates not being captured in documents that are already going through lengthy review and approval cycles in order to be ready in time for testing to begin.

Computer Software Assurance, or CSA, seeks to overcome many of these limitations by recommending that industry seek the least burdensome approach to software validation.  It offers and encourages us to find a “better way”, one we knew had to exist as we worked through the issues above.

Robust scripted testing, the traditional methodology of CSV is still available and isn’t going away.  It is still the best way to test high risk or custom applications.  But now, it’s not our only approach.  We have limited scripted testing as an available option as well as several levels of less scripted or even unscripted testing options such as ad-hoc, experience-based, error guessing, and exploratory testing scenarios.  Those less formal test scripts lead to fewer script errors and deviations because the documentation, while still as meticulous and complete as always, is now more flexible and amenable to changes or even to the addition of supplemental testing on the fly.  These new test architectures can also help us to reduce the number of screenshots needed, reserving them for only the most critical steps or end results while also encouraging the user to apply their own discretion to determine where a supplemental screenshot might be appropriate and informative.

And that’s where one of my favorite parts of the guidance comes into play.  Instead of having the scripts performed by validation or test engineers who are often external consultants seeing the system and the client’s work processes for the first time, the guidance encourages testing to be performed by the actual end users who are going to use this system to do their work everyday for years to come!  Who better to understand and be able to rigorously test their system to make sure it meets their requirements and will help them do their work, not get in the way of it?

Of course, now that we have more testing approaches and options, it’s even more important that we choose the right one for each part of the system.  The guidance gives us tools to help us do this.  It recommends a risk-based approach based on intended use at every step of the process and classifies software into two main types: Direct Software and Support Software to help us determine the risk level.  Risks can be further classified as High Process Risks and Not High Process Risks to help ensure that the appropriate approaches are taken.

The Appendix section of the guidance also provides detailed real-world examples of actual CSA validations of modern software applications including a nonconformance management system, learning management system (LMS), business intelligence applications, and a Saas-based product lifecycle management system (PLM).  These examples are good references and starting points for CSA validation projects.

How does CSA align with global bioanalytical regulatory requirements, such as EMA and ICH guidelines, particularly for bioanalytical method validation?

While FDA, EMA and ICH differ in their agencies’ scope, levels of authority and levels of regulatory oversight, their actual guidelines and regulations are frequently analogous to each other and where they do differ, they often complement and supplement each other.

For example, EMA Annex 11 is currently under revision and many of the elements around risk assessment, fitness for intended use, periodic reviews and auditing/ leveraging vendor software test data are echoed and amplified in the FDA’s CSA guidance.

Bioanalytical method validation follows its own guidelines such as ICH M10, but before any method can be validated, we must confirm that the instrument used for validation as well as all of its associated data acquisition, analysis and storage and retrieval systems (e.g., chromatography or other instrument data systems, LIMS systems, etc.) have been properly validated.

Instrument vendors typically provide and execute protocols that do a very good job of validating their hardware and indirectly testing the instrument software by virtue of the fact that they perform the validation using the instrument’s native software.  However, these protocols do not always cover data integrity and 21CFR Part 11/ Annex 11 requirements to the level of rigor demanded by GxP quality systems.  CSA can provide an efficient approach to identify these gaps, assess the risk, and determine the appropriate level of testing to rapidly remediate any deficiencies found.

In addition to the instrument software, any other software that is used to process, analyze or store the data (e.g., chromatography systems, LIMS systems and their associated data interfaces) must also be validated prior to its use in method validation.  CSA can provide a more efficient approach to this by using risk analysis and the vendor audit process to leverage some or all of the vendor’s test data to validate the system.

With your experience in validating AI-based algorithms for clinical trial data management, what unique challenges do AI systems pose for CSA validation and how can these be overcome?

For that particular project we used very rigorous traditional CSV techniques because both the software and the algorithms were novel, highly customized and the intended use was for direct data analysis of active clinical trials which made the risk level extremely high.  We also repeated each test script several times with modified parameters to introduce supplemental scenarios to further challenge the system and make sure it responded appropriately to those alternate scenarios.

As AI grows, matures and is better understood, the risk level will not always be as high as it was in that case.  Instead, we will see more of what I like to call a “spectrum of risk” where some elements of a single system may be high risk while others are moderate or even lower risk depending on intended use and whether it’s a direct or support function.  The CSA framework gives us multiple levels of testing that lend themselves very well to this variable spectrum of risk.

At last year’s Interphex Panel discussion on the “AI revolution in Life Sciences Manufacturing” I stressed the importance of keeping the “human in the loop” and keeping a “trust but verify” mindset when working with AI applications.  Even the most rigorously validated, most advanced AI systems will continue to require this level of oversight for the foreseeable future.

What lessons have you learned from implementing CSA across multiple company sites, particularly in cell and gene therapy?

Cell and gene therapy companies are generally very innovative thanks to their novel approaches to treating and sometimes potentially even curing diseases.  This innovative spirit may well have been part of the reason that my first CSA projects after the 2022 draft guidance were at cell and gene therapy startup companies.  Their willingness to embrace the latest and greatest technology extended from their therapeutics to their approach to CSV.   Using the more efficient techniques of CSV, we were able to quickly remediate gaps in vendor validation and get these companies inspection-ready within a matter of months instead of the typical 6 month to 1 year project timeframe typical when using traditional CSV methods.  And in the startup world, time savings are more than just simple cost savings.  With limited funding and resources available, it can often be a matter of survival!

Traditional big bio/pharma took more of a “wait and see” approach when the draft guidance was issued, but even so, I began to recognize some elements of CSA gradually appearing in newer revisions of their CSV standard operating procedures (SOPs).  Now that the final guidance has been issued and endorsed by both the FDA’s Center for Biologics Evaluation and Research (CBER) and Center for Devices and Radiological Health (CDRH), it’s no longer seen as “only applicable to medical devices”, which is where the original CSA initiative began. I recently learned that one of the top 5 global pharmaceutical companies has launched a global initiative to migrate all CSV activities to CSA moving forward.  I expect other biopharmas to quickly follow suit.

How can companies effectively apply CSA principles to legacy systems without disrupting existing operations or compliance? What strategies do you recommend?

When talking to a new client about a software validation project, there are three main questions I always ask to evaluate the state of their CSV program.

1. Could you provide me with a copy of your current CSV/CSA SOP?
2. Are you currently doing CSA?
3. If not, do you want to introduce CSA principles to your validation program?

Sometimes the answers to questions two and three are “no” or a more diplomatic “we aren’t quite ready for that yet” and those are valid responses.  Traditional CSV principles are still a valid approach and there may be other updates needed to a client’s quality systems before they are ready to implement CSA successfully.

If they do want to introduce CSA, the first thing I suggest is that we evaluate and update their CSV SOP to allow the use of CSA techniques.  Often the CSA approach can be included as a new section of their CSV SOP, but it could also be implemented as its own distinct SOP depending on the client’s preference.

Once the updated SOP is in place, we can identify a system that is a good pilot candidate for CSA validation.  This could be a brand-new software system, an existing system that is being upgraded with a newer version of software and/or new functionality that requires revalidation, a SaaS upgrade (CSA is an excellent choice for keeping up with quarterly SaaS updates), or even an already validated system where gaps in the validation have been identified during periodic review (regular periodic review of validated systems is another major component of CSA) .

Once the system is identified and the project team is gathered, it’s also vital to ensure that the appropriate end users of the system are directly involved in the development of requirements and test scripts.  Ideally, the organization has already included users in these processes, but if not, this is the right time to do it!  End users with their practical day to day process experience will generally specify more realistic and achievable requirements, stronger and more realistic test cases, and because of their direct involvement and investment in the success of the system, they will be more comfortable with the new technology when it goes live.

In your opinion, are there any gaps or limitations in the guidance?

Although the final guidance was issued in September 2025, revised guidance has already been issued in February 2026 to improve alignment with the latest Quality Management System Regulation (QMSR) update.  As the guidance is adopted by more and more companies and is implemented for a wider variety of computer software applications, more gaps and limitations will certainly be found.  Since its start, the CSA initiative has always been a collaborative effort between industry and the FDA, and I’m confident that this continued collaboration will help us all to be successful in implementing CSA as a valid approach to reducing the level of validation effort while increasing its effectiveness.