From CSV to CSA: A Complete Guide to Risk-Based Validation for Pharmaceutical and Laboratory Systems

CSA (Computer Software Assurance) is now FDA policy, so it now represents the risk-based methodology through which CSV (Computer System Validation) obligations must be met. This makes CSA a live compliance matter, especially if you are involved in or planning a software application implementation, system upgrade, or audit cycle. It’s also essential if you are reviewing or updating your CSV/validation approach.

This guide will give an overview of the regulatory background to CSA and the practical differences between traditional CSV and modern risk-based validation methodologies. We’ll explore in detail how to apply CSA to LIMS and similar systems, the documentation that is required, and how to manage ongoing compliance.

What is CSA and Why It Matters

CSA is a risk-based approach to establishing and maintaining confidence that software is fit for its intended use.

That is a good summary definition, but there are two important qualifications to add:

• CSA applies specifically to production and quality system software, not software embedded in devices. This qualification of the CSA definition mostly applies to the medical device industry, but it is worth noting for all QC and validation professionals.
• CSA doesn’t create new validation obligations or remove established obligations. Instead, CSA is a methodology recommended by the FDA for fulfilling existing (and long-standing) validation obligations.

To clarify, CSA is not a replacement for CSV. It is not a deregulation, and it doesn’t relax compliance standards. The level of rigor in software validation remains the same.

However, that rigor shifts from documentation volume to risk-based critical thinking.

For example, in traditional CSV practice, about 80% of the validation effort is spent on documentation, with the remaining 20% spent on testing. CSA intentionally inverts this balance to focus the majority of effort on testing and critical thinking about risk.

As for documentation, it is sized to a level necessary to demonstrate confidence in the system.

The Origins of CSA

CSA’s origins date back to the FDA’s Case for Quality program. Along with industry collaboration, the FDA produced draft CSA guidance in September 2022. Final guidance was published in September 2025 and then updated in February 2026. It’s also worth noting that CSA is closely aligned with complementary industry frameworks such as GAMP 5 Second Edition.

What Systems Does CSA Apply To?

CSA applies to software used as part of production or the quality management system in life sciences sector organizations. This includes the pharmaceutical industry. System and software examples include:

• LIMS
• QMS
• CAPA systems
• MES
• Laboratory data systems

CSA covers all types of software deployments, including on-premises, hybrid, cloud, SaaS, IaaS, and PaaS. It also applies to AI and ML agents and tools, as well as automation bots.

For clarity, CSA does not apply to software embedded in medical devices (SiMD) or software as a medical device (SaMD).

The Regulatory Background of CSA

The FDA published its first draft guidance on CSA in 2022 following a multi-year evolution in policy relating to the validation of software in GxP critical environments. Highlights of that evolution include:

• The 2002 General Principles of Software Validation (GPSV)
• 21 CFR Part 11 (1997)
• 21 CFR Part 211 (for pharmaceutical manufacturers)
• The FDA’s Case for Quality program, which launched in 2008
• Ongoing collaboration with industry

This evolution culminated in the 2022 draft guidance on CSA principles. This guidance included the now familiar four-step framework:

• Define intended use
• Assess the risk of failure
• Plan assurance activities
• Document confidence

The 2022 guidance also established the high process risk/not-high process risk classification model. It also introduced scripted and unscripted testing and encouraged the use of vendor documentation.

Final Guidance on Computer Software Assurance for Production and Quality System Software

The FDA published its Final Guidance on Computer Software Assurance for Production and Quality System Software in September 2025. The final guidance represents a substantive evolution from the 2022 draft guidance. The changes (outlined in more detail in the table below) cover the scope, terminology, documentation requirements, and practical application of CSA principles.

The most significant additions include:

• A formalized definitions section covering cloud deployment models (IaaS, PaaS, SaaS).
• An expanded scope explicitly bringing AI/ML tools, bots, and data analytics platforms under the remit of CSA.
• A new subsection on software change management.

Additionally, “Scenario-based testing” replaced “ad hoc testing” in the final guidance, plus the relationship between CSA and 21 CFR Part 11 has been clarified.

It’s also important to note that the final guidance on CSA was issued jointly by CDRH and CBER. This confirmed what most assumed, i.e., that CSA applies to pharmaceutical manufacturing and quality systems as much as it applies to MedTech.

For pharmaceutical manufacturers, the obligation to validate computerized systems exists under 21 CFR Part 211 and EU GMP Annex 11. CSA is the FDA’s recommended methodology for fulfilling those obligations.

February 2026 Update

The February 2026 update was a regulatory realignment exercise. As a result, it did not involve a revision of CSA methodology, so the principles in the final guidance remain the same.

As part of this regulatory realignment exercise, the title changed from Quality System Software to Quality Management System Software, anchoring CSA to the new Quality Management System Regulation (QMSR) and ISO 13485:2016, both of which also came into force in February 2026.

With the February 2026 update, CSA guidance is now stable. It is expected that regulatory attention will now turn to implementation and inspection consistency.

Draft vs Final CSA Guidance: Summary of Key Changes

CSV vs. CSA: What Has Changed?

Let’s start by reiterating what has not changed: the legal obligation to validate remains exactly the same. The changes apply to how that obligation is fulfilled.

A Shift to Critical Thinking

As it evolved in real-world conditions, traditional CSV became heavily focused on generating documentation. This was viewed (and accepted) as the primary evidence of compliance. As a result, the volume and completeness of the paper trail became a proxy for quality.

CSA shifts this focus:

• Traditional CSV methodologies: generate lots of documentation for everything.
• CSA: test what matters based on risk and document the reasoning.

It’s important to note that this is a philosophical change to validation as much as a procedural one. It’s a different way of thinking about validation as much as it is a different way of doing validation.

Effort Rebalancing

With a shift to critical thinking, the validation effort is rebalanced:

• Traditional CSV methodologies: 80% of validation time and effort is spent on writing, reviewing, approving, and storing test scripts, protocols, and reports.
• CSA: 80% of validation time and effort is spent on meaningful, risk-based testing.

With this effort rebalancing, the amount of documentation produced using a CSA approach depends on what is genuinely necessary to demonstrate confidence in the software.

The result is typically less documentation, but that doesn’t mean less validation rigor. Rigor remains the same, while documentation is proportionate to risk.

Terminology Changes: IQ, OQ, PQ

IQ (installation qualification), OQ (operational qualification), and PQ (performance qualification) are not used in the final CSA guidance. They are replaced by scripted testing, unscripted testing, and hybrid testing.

While not included, it does not mean that IQ, OQ, or PQ are invalid approaches. For example, high-risk functions might still be tested under CSA methodologies that closely map to OQ-style protocols.

Although FDA CSA guidance emphasizes assurance activities rather than traditional qualification terminology, many organizations continue to use IQ, OQ, and PQ documentation structures internally. In these cases, CSA principles can be incorporated by applying risk-based testing, critical thinking, and right-sized documentation within existing qualification frameworks.

However, the language change is important for quality leaders to note.

What Unscripted Testing Actually Means

Unscripted testing is one of the more misunderstood aspects of CSA. So, it is worth being precise about what it does and does not mean.

It does not mean informal, undocumented, or ad hoc testing. The term “ad hoc” was used in the 2022 draft guidance and was deliberately replaced in the final guidance with “scenario-based testing”. This change reflects the structured intent behind the approach.

Under CSA, unscripted testing still requires a defined objective. It also requires a set of acceptance criteria and a documented conclusion. All seven elements of the appropriate record (see below) also apply.

What it does not require is a pre-written step-by-step test script. The tester works through the function using their expertise and knowledge of the system rather than following a prescriptive sequence of steps.

The practical saving is in preparation time. However, the evidential standard for demonstrating that testing was completed, and what it found, remains unchanged.

Terminology Changes: Validation vs Assurance

The use of the word “assurance” is deliberate, as “validation” could be interpreted as a point-in-time event. CSA is a lifecycle activity that the word “assurance” more closely reflects.

The Risk Classification Model

The tiering of risk could be applied using a traditional CSV approach, but this wasn’t formalized. As a result, a similar level of validation rigor was applied to all functions of a system, whatever the risk.

This is the most fundamental change with the formalization of CSA, as CSA requires a function-by-function assessment of risk. How functions are tested and the documentation that is then produced, are dependent on the outcome of the risk assessment.

For example:

• High-risk function that could compromise product quality or patient safety – scripted or hybrid testing with robust traceability.
• Low risk function – exploratory testing or vendor evidence.

The Role of Vendor Evidence

It is worth expanding further on the expanded role of vendor evidence, especially given its significance to LIMS and other specialist software used in the pharmaceutical industry.

• Traditional CSV – software was tested from scratch, duplicating tests and documentation already performed by vendors.
• CSA – explicitly allows the use of vendor-provided evidence.

Examples of the vendor-provided evidence that is allowed under CSA include:

• SDLC (software development lifecycle) documentation
• Test records
• SOC reports
• ISO certifications
• Cybersecurity artefacts

A risk-based vendor assessment is required under CSA. For example, you can’t simply accept a SOC 2 report from a vendor. You instead must assess whether the vendor’s controls are adequate for the risk levels of the function being supported.

That said, as vendor documentation can be utilized, most of the validation effort can be focused on things like configuration verification and the testing of high-risk functions.

Documentation: What Are the Changes?

Some documentation produced using a traditional CSV approach is no longer required. Examples include screenshots, templated test scripts for every function of a system, etc.

What is now required is the maintenance of an appropriate record. This should include the following seven elements:

• Intended use
• Risk-based analysis
• Objectives tested
• Testing performed
• Issues found
• Conclusion
• Who/when

It’s also important to note that digital evidence is preferred in the CSA guidance over paper records, i.e., system logs, audit trails, automated test outputs, etc.

Summary: Traditional CSV vs CSA

Risk-Based Thinking is at the Core of CSA

Risk-based thinking is at the core of CSA, and it is deliberately binary:

• High process risk
• Not high process risk

This should not be viewed as a limitation of CSA. Instead, it helps drive consistent decision-making as the question should always be the same: could a failure of this function compromise product quality or patient safety?

If the answer is yes, it’s a high process risk. If the answer is no, it is not a high process risk.

It’s also worth noting that we are talking about functions here, not systems. For example, it is not about classifying a LIMS system as either a high process risk or not high process risk. Instead, the individual functions within the LIMS software should be assessed and classified individually and independently.

This means the same system – such as a LIMS platform – could have functions that are high process risk and others that are not high process risk. Again, this is deliberate as it drives targeted testing based on risk.

High Process Risk Examples

Using a QC laboratory as an example, functions that are likely to come under the high process risk classification include:

• Automated calculation and reporting of analytical results used in batch release
• Audit trail and data integrity controls
• Electronic signatures on records required by predicate rules
• Out-of-specification detection and flagging
• Sample chain of custody where errors could lead to incorrect release decisions

Not High Process Risk Examples

Staying with our QC laboratory example, functions that might be classified as not high process risk include:

• User preference settings
• Report formatting and layout options
• Non-critical notification configurations
• Standard data export functions where the underlying data integrity is separately assured

The Role of Critical Thinking

The CSA guidance does not provide a lookup table or any other reference that can be consulted when classifying the risk of a function in a software application. As a result, subject matter experts (i.e., QC and QA professionals) remain essential in the validation process as they understand how the outputs of a software system could impact downstream decisions.

Getting Risk Classification Right

The risk classification given to each function in a software application determines:

• The testing approach
• The level of vendor evidence required
• The documentation standard
• The change control response necessary if the function is modified

As a result, getting the risk classification right at the outset is the most important and consequential step in the process because of its impact on everything downstream.

Illustrative Example Scenario: Applying CSA to a LIMS Upgrade

The Illustrative Scenario

A pharmaceutical QC laboratory is implementing a cloud-based LIMS to replace a legacy on-premises system. With the new system, analytical results will flow directly from the LIMS into batch release decisions.

Scoping Intended Use

Rather than validating the LIMS as a whole, intended use is defined at the feature and function level. This involves identifying specifically which functions the laboratory will use, in which processes, and with what outputs. This scoping decision determines everything that follows, so it is documented as the foundation of the assurance plan.

Integrations and Data Transfer Boundaries

LIMS platforms, for example, in modern QC laboratories rarely operate in isolation. Integration with chromatography data systems (CDS), ERP platforms, and laboratory instruments is the norm. CSA applies to these integrations as much as it applies to the systems themselves.

This is particularly important for risk classification. A vendor may provide robust assurance evidence for their system in isolation, but the data transfer boundaries between integrated systems should be presumed high process risk. This is because a failure or corruption at an integration point can impact batch release decisions without triggering an error visible within either system individually.

This means integration testing, data mapping verification, and the integrity of transferred records require scripted testing with documented rationale and traceability. This applies regardless of the risk classification applied to functions in individual systems on either side of the boundary.

Classifying Functions by Process Risk

Automated result calculations influencing batch release, audit trail integrity controls, electronic signatures on GxP records, and OOS flagging are classified as high process risk. This is because a failure in any of these functions could directly affect product quality or patient safety decisions.

User management settings, report layout preferences, and dashboard configurations are classified as not-high process risk. Therefore, they require proportionately less assurance effort.

Leveraging Vendor Documentation

Having completed a risk-based vendor assessment, vendor documentation can be used. This includes SDLC documentation, test records, SOC 2 reports, and ISO certifications. Under CSA, this evidence counts toward the assurance package, so re-testing is not required.

Defining the Testing Program

• High process risk functions – scripted or hybrid testing with documented rationale and traceability.
• Lower-risk functions – exploratory or scenario-based testing, with clear objectives and acceptance criteria but without fully scripted protocols.

The Appropriate Record

For each function tested, the record contains the seven FDA-defined elements recorded digitally: intended use, risk-based rationale, objectives, testing performed, issues found, conclusion, and sign-off. This produces an overall documentation package that is structured, traceable, and inspection-ready.

Go-Live and Maintaining a Validated State

As the software is a cloud-based LIMS with vendor-managed updates, go-live is not the end of the assurance obligation. Each software update or configuration change triggers a risk-based impact assessment where targeted re-testing might be required.

Comparison With a Traditional CSV Approach

The same project under traditional CSV would typically have taken several months, produced an extensive documentation package covering the majority of system functions regardless of risk, and required significant re-testing of vendor-provided functionality.

Under CSA, the effort is concentrated on the functions that actually matter to product quality and patient safety. As a result, the timeline and resource requirements reduce accordingly.

Change Control and Lifecycle Management

Traditional CSV was often viewed as a project with an endpoint. CSA, on the other hand, is, explicitly, a continuous condition that must be maintained. This shift has operational implications.

Change Control as a CSA Trigger

All software is changed and updated, whether initiated by the vendor or the organization using the software. Such changes require a documented risk-based impact assessment. This risk assessment should address a key question: does the change impact any function that has been classified as a high process risk?

If the answer is yes, the impacted functions should be re-tested and appropriate documentation produced.

If the answer is no, no further testing is required, and the rationale for this decision is documented.

This targeted approach saves time and effort compared to traditional CSV.

The Specific Challenge of Automatic Updates

Automatic updates are a common feature in modern software applications, especially cloud-based software (including leading LIMS and QMS platforms). As they are automatic, organizations using the software typically have limited (if any) control over the timing of updates. Automatic updates are also often continuous.

The automatic update feature of modern software platforms does not remove or transfer ongoing validation obligations. CSA, however, does address this reality using targeted regression testing.

Defined processes are essential in this regard. This should include processes for:

• Being notified of updates
• Assessing the scope of updates
• Classifying impacted functions
• Responding proportionately

As a result of the above, well-constructed service level agreements (SLAs) with SaaS vendors are essential. For example, a well-constructed SLA should include:

• Advance notification of updates
• Documentation of what has changed
• Vendor-provided test evidence for the update
• Clear responsibilities for data integrity and cybersecurity

Changes to Periodic Reviews

Traditional CSV required periodic reviews of software on a defined schedule. However, under CSA, a software application’s validated state must be continuously monitored rather than periodically reassessed.

That said, formal periodic reviews can still be good practice, especially for systems that have been changed multiple times. The purpose of periodic reviews changes, however, as they are no longer about revalidation. Instead, they are beneficial to confirm risk classifications remain accurate and assurance activities remain in line with system changes.

Summary of Common Mistakes and Misconceptions

• CSA replaces CSV. It doesn’t. The legal obligation to validate software for its intended use is unchanged. CSA is the FDA’s recommended methodology for fulfilling that obligation.
• Less documentation means less rigor. CSA reduces unnecessary documentation, not necessary documentation. The difference is that documentation is now proportionate to risk rather than exhaustive by default.
• Applying CSA means starting over. Organizations with mature CSV programs do not need to discard their existing validated systems. CSA principles are applied to new implementations, upgrades, and change control. Legacy systems can be managed through the transition to CSA at a pace proportionate to risk and resource availability.
• Classifying a system as low risk to reduce effort. Risk classification operates at the function level, not the system level. Classifying an entire LIMS as not-high process risk to avoid scripted testing is not a legitimate application of CSA and would not withstand inspection scrutiny.
• Recreating CSV documentation under a CSA label. One of the most common transitional failures is where organizations adopt CSA terminology but continue producing traditional validation packages. The effort saving never materializes, and the documentation no longer maps cleanly to either framework.
• Assuming vendor evidence removes the need for user-side testing. Vendor documentation reduces the scope of user-side testing for lower-risk functions. However, it does not eliminate the organization’s assurance obligations. High process risk functions require user-side verification regardless of what the vendor provides.
• Treating CSA as a one-time implementation project. CSA is a lifecycle obligation. Organizations that validate a new LIMS under CSA principles but revert to ad hoc change management afterwards are not maintaining the validated state, so they could be exposed at inspection.
• Waiting for regulatory certainty before acting. With the final guidance issued in September 2025 and updated in February 2026, CSA is current FDA policy. Organizations continuing to apply traditional CSV without a transition plan are working against the direction of regulatory travel.

How to Build a CSA Transition Plan

Transitioning from CSV to CSA is not a single project with a defined end date. Instead, it should be viewed as a program of change that impacts validation frameworks, SOPs, team capability, and supplier relationships.

The scale of that change will vary significantly depending on your organization. The following steps provide a practical framework for planning and sequencing the transition in a way that is manageable, risk-proportionate, and defensible at inspection.

Gap Assessment

Conduct an assessment to determine the gap between CSA expectations and current validated systems, SOPs, documentation standards, change control management, and vendor relationships. This gap assessment can then be used to plan your transition to CSA.

Prioritize by Risk and Opportunity

The transition to CSA doesn’t need to happen immediately. In fact, the FDA recommends starting with low-risk systems before moving to high-stakes systems like LIMS.

Major upgrades and new software implementations are natural entry points for CSA transitions. The validation of legacy systems, on the other hand, can be aligned with CSA methodologies through change control events and periodic review cycles.

SOP and Template Updates

Existing SOPs will reference documentation standards, protocol formats, and IQ/OQ/PQ structures that are not explicit in the CSA guidance. These will need to be updated to reflect CSA terminology and the overall validation framework.

Templates should also be updated, especially to reflect the seven record elements defined by the FDA.

Training

Validation teams need to adopt a different kind of thinking when using a CSA approach to validation. It’s a cultural change as much as a procedural change. As a result, CSA training should cover more than just processes and procedures. It should also explain why to enable validation teams to apply critical thinking consistently without reverting to CSV habits.

Stakeholder Alignment

CSA impacts more stakeholders than using a traditional CSV approach. This is because risk classification decisions require subject matter expertise from people who understand the processes that a software application supports.

As a result, alignment is required between IT, QA, QC, and regulatory. That alignment should cover risk classification methodology and the allocation of responsibilities.

Vendor Engagement

It is worthwhile to revisit relationships with software vendors, especially SaaS vendors that implement automatic updates to their platforms. The aim is to ensure SLAs cover CSA requirements in areas such as update notifications and vendor-provided test evidence. Renegotiation of existing agreements might be necessary.

Inspection Readiness

Inspectors will approach CSA evidence differently, with scrutiny shifting from documentation to the quality of risk reasoning. Questions you can expect include:

• Can you clearly explain why you classified the software functions the way you did?
• Why did you choose the testing approaches that you chose?
• How do you know the system remains in a validated state?

Being inspection-ready is about more than having the right documentation in place. You also need to be able to answer questions like the above from inspectors.

How Westbourne Supports CSA-Compliant Validation

Westbourne works with pharmaceutical and life sciences organizations across the full range of computerized system validation activities. Our expertise ranges from initial gap assessment and risk classification through to hands-on validation execution, SOP and template development, and ongoing lifecycle support.

This depth and breadth of expertise matter in a CSA context, where the decisions made at the outset of a validation project directly shape everything else.

Our Approach

Our approach to CSA is practical and grounded in how pharmaceutical and QC operations actually work. We do not apply a one-size-fits-all validation framework. Instead, we work with QA, QC, and IT stakeholders to build risk classifications that reflect how a system is genuinely used, as well as what its outputs mean for product quality and patient safety decisions.

For LIMS implementations, for example, this means understanding the laboratory processes the system supports as well as the system itself.

CSA and Validation Services

The services we provide across a CSA-aligned validation program include:

• Gap assessment and transition planning – evaluating where current validation practice sits relative to CSA expectations and identifying what needs to change. This includes SOPs, templates, vendor agreements, etc. We will also help you plan the transition in a way that is proportionate and manageable.
• Risk classification and assurance planning – we will work with you to classify system functions by process risk. We’ll then help define the appropriate testing approach before documenting the rationale in a form that is inspection-ready.
• Validation execution – we will help write and run validation protocols for high process risk functions, as well as conduct and document exploratory and scenario-based testing for lower-risk functions. These processes include putting together the appropriate record to FDA standards.
• SOP and template development – we will help you update legacy validation SOPs and documentation templates to reflect CSA terminology, the appropriate record structure, and current regulatory references, including QMSR and ISO 13485:2016.
• Vendor assessment support – we will help review vendor-provided evidence packages, as well as identify gaps and advise on SLA requirements.
• Training – we will help enhance CSA capabilities within your quality and validation teams with a focus on risk-based critical thinking.

When External Support Adds Most Value

In practice, the organizations that benefit most from external CSA support are those facing a specific trigger. For example, a LIMS implementation, system upgrade, or upcoming inspection. These are situations where getting the risk classification and documentation approach right from the outset is more efficient than correcting it later.

At Westbourne, we have supported organizations through such scenarios. In all cases, the combination of CSA methodology and system-specific expertise has produced validation programs that are leaner, more defensible, and faster to execute than their CSV predecessors.

If you are planning a LIMS implementation (or another software change), managing a CSA transition, or simply want to understand what a CSA-aligned validation program would look like for your organization, we would be glad to have that conversation. Contact us at Westbourne.

Subscribe to our latest insights