One of the main barriers to adopting Computer Software Assurance (CSA) is the established culture surrounding Computer Systems Validation (CSV). For an extended period, validation teams have frequently associated compliance with documentation volume; larger validation packages have been seen as indicative of compliance. As a result, professionals familiar with producing and reviewing detailed test scripts may be reluctant to change their approach.
The term “Computer Software Assurance” was 
introduced by John Murray to move away from longstanding associations with CSV. This shift in terminology is akin to using “team member” instead of “employee” or reframing “failure” as a “learning opportunity”; it was intended to encourage a shift in perspective and organizational culture, aiming to avoid pre-existing hangups. For those already using updated software engineering practices, this change had little impact. For others, the new terminology represented a separate and distinct new process to transition and navigate into, which led to resistance; we don’t need to adopt this new thing called a car our wagons are just fine. Sadly, CSV is one of the few jobs where a practitioner from 1997, when 21 CFR Part 11 final rule was published, can find a job today, without remedial training. The concept of “current” is missing from CSV. Current is exemplified in the “c” that is commonly used to denote that GMP is subject to ongoing updates; companies are expected to continuously improve practices, equipment, and training. The word “current” signals to manufacturers that best practices, technologies, and systems evolve over time. As explained by the U.S. FDA:
“The ‘c’ in cGMP stands for ‘current,’ requiring companies to use technologies and systems that are up-to-date in order to comply with the regulations.”
— FDA- Facts About the Current Good Manufacturing Practice (CGMP)
The importance of the “c” is more significant for validation:
• Methods evolve (for example, changes in software engineering practices and tools).
• Regulators expect adaptation to emerging risks, including data integrity and cybersecurity.
• Global harmonization initiatives (such as EU GMP Annex updates and ICH guidelines) promote continuous improvement.
The pushback against current was largely driven by a false dichotomy; team members viewed the CSA as a departure from the CSV, despite both 
following the same underlying software engineering practices. In fact, the naysayers that say CSA is noncompliant are unable to cite the compliance basis for what they do today. This situation highlights challenges in interpreting compliance requirements across the industry; regulations state that you must do CSV, but they do not specify the “how”. Despite these developments in software engineering, methodologies within validation roles often remain unchanged, with many practitioners still relying on paper-based processes. The reliance on legacy practices appears rooted in the belief that historical precedent equates to regulatory compliance or ethical justification. A belief that implyies that long-standing habits are inherently defensible; as if sticking to outdated methods absolves responsibility because ‘If we’ve always done it this way, it must be compliant or at least unchallengeable when it fails to work.’
Key reasons for this resistance include:
• Preference for Familiarity: In regulated environments, especially in quality assurance, there is a tendency to adhere to established practices due to perceived lower risk. Well-known CSV procedures and concerns about potential consequences of non-compliance encourage continued reliance on extensive documentation.
• Regulatory Uncertainty: Although the FDA has expressed support for Computer Software Assurance (CSA), many organizations remain hesitant to adopt modern practices. This is often due to a lack of internal expertise in articulating and justifying contemporary software engineering approaches during audits. In some cases, there is an overreliance on Quality Assurance (QA) teams to explain technical details that would be more appropriately addressed by IT professionals. QA teams may default to producing extensive documentation rather than providing a technical narrative, often because they may not have the necessary software engineering background to do so.
• Limited CSA Training and Awareness: Transitioning to CSA involves critical thinking, risk assessment, and familiarity with modern software development practices such as Agile. However, training for CSV professionals has not consistently addressed these areas, and some established frameworks aimed at integrating software engineering principles, like ISPE’s GAMP model, are not always fully utilized.
What’s in a name? Everything.
In discussions with Guneet Hayer and Suryansh Rana, we coined the term CSX to emphasize a
critical insight: CSA and CSV are not fundamentally different! They are two expressions of the same objective. This clarification is vital in reshaping perceptions, as the introduction of CSA was never meant to replace CSV, but to modernize how its principles are applied. Much of what CSA promotes, i.e., risk-based thinking, automation, streamlined documentation, has already existed within ISPE GAMP frameworks for years. The difference lies not in the substance, but in the mindset.
Early adoption of CSA was largely seamless for those already applying modern software engineering within validation activities. For others, the change felt disruptive, not because the practices were radically new, but because the name signaled a cultural shift they were unprepared to make. This resistance is rooted in longstanding habits, regulatory conservatism, and a comfort with voluminous documentation as a proxy for compliance.
However, the “c” in cGMP stands as a reminder that current best practices are not optional, and they are expected and required. Software engineering, like all aspects of manufacturing and quality, must evolve to meet emerging risks, technologies, and regulatory expectations. Organizations that cling to outdated practices in the name of safety or audit-readiness may inadvertently undermine both.
True compliance is not about preserving legacy validation scripts; it’s about demonstrating control, understanding, and fitness for purpose using the tools, methods, and thinking of today. CSX demands that we bring our validation culture in line with current capabilities. The shift is not in regulation, but in interpretation and execution. And that change starts not with new acronyms, but with new understanding.
The thoughts in the article represent my own views and not that of my company.
