CSV vs. CSA: What are the main differences?

In life sciences, most CSV projects are paperwork marathons dressed up as quality work.

You print test scripts nobody reads. You collect screenshots for features nobody uses. You sign documents to prove you validated a system you already trusted three suppliers ago.

Does this sound familiar?

The FDA agrees with you. That is why the agency finalised their Computer Software Assurance for Production and Quality Management System Software guidance on 3 February 2026, superseding the September 2025 version and rewriting the rules for any computerised system tied to production or the quality management system.

This new guidance was explicitly revised to align with the Quality Management System Regulation (QMSR) amendments to 21 CFR Part 820, which incorporate ISO 13485:2016 by reference.

So what changes? CSV proves your system works. CSA proves it works where failure would actually hurt the patient. One is a fitness certificate. The other is a fitness certificate plus a brain.

This post walks you through both approaches. The regulatory "what" and the practical "how". Pick the one your audit needs, or better, learn how to blend them.

What is the difference between CSV and CSA?

Both CSV and CSA are FDA-recognised approaches that demonstrate software used in regulated environments is fit for intended use. The split is philosophical, not technical.

The key difference is that CSV focuses on extensive documentation and predefined testing to prove compliance, while CSA uses a risk-based approach that prioritises critical thinking and targeted testing based on potential impact to patient safety and product quality.

In simple terms, CSV aims to demonstrate that a system works as specified, whereas CSA aims to ensure the system performs reliably where it matters most. As a result, CSA typically reduces unnecessary documentation and allows organizations to focus their validation efforts on high-risk areas, making the process more efficient without compromising compliance.

What is Computer System Validation?

CSV is a documented process that demonstrates a computerised system consistently does what it was designed to do, and that the data it produces is trustworthy, secure, and GxP-compliant.

The FDA introduced its General Principles of Software Validation in 2002, which still informs CSV today and remains in force, except for Section 6 (now superseded by CSA). Layer in 21 CFR Part 11 for electronic records and signatures, and you have the regulatory backbone behind every CSV deliverable you have ever signed.

Types of computerized systems

Computerized systems include a broad array of tools:

• Embedded equipment software (e.g. instrument firmware)

• Commercial Off-The-Shelf (COTS) software

• Spreadsheets used for GxP calculations

• Document Management Systems (DMS)

• Process Analytical Technology (PAT)

• IT infrastructure software (servers, networks, cloud platforms)

GAMP 5 categories of computerized systems

GAMP 5 2nd Edition categorises computerized systems (software and hardware) by complexity and configurability:

• Category 1: Infrastructure software, tools, and IT services.

• Category 3: Standard system components, non-configured products used out of the box.

• Category 4: Configured components tailored to your process.

• Category 5: Custom-developed applications and components.

Note: Category 2 was merged into category 3 and is no longer used as a separate category.

Quality Risk Management (QRM) is the connective issue. QRM is the systematic process of assessing, controlling, communicating, and reviewing risks across the life cycle. The category your system falls under sets the starting point. QRM scales the rigour from there.

How to plan the CSV documentation process

Before you write a single test script, answer four questions in this exact order. The order matters.

• What will be validated? Name the software and pin down the version.

• What are the acceptance criteria? The expected results for User Requirement Specifications (URS), Functional Specifications (FS), and Design Specifications (DS).

• How will it be validated? Write the strategy. Plan Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) tests.

• Who will validate? Assign every test to a named role.

Skip the sequence and you will end up testing the wrong things with the wrong people. I have watched whole teams rewrite their qualification protocols because they jumped to "who" before settling "what".

Scale every life-cycle activity to system impact on patient safety, product quality, and data integrity. The activities to cover:

• Prepare the validation plan

• Form the validation team

• Develop system requirements

• Conduct a thorough supplier assessment

• Define the extent and formality of validation

How to define acceptance criteria for CSV

Acceptance criteria sit on three documents. URS, FS, and DS. If all requirements in those documents pass, the system passes. Simple in theory, brutal in practice.

User Requirements Specification (URS)

The URS is your single source of truth for what users actually need. Write it before you talk to vendors. Once you involve a vendor, your requirements drift toward whatever they sell.

For example, a standard laboratory system URS might require:

• Tracking analyst training records against specific methods.

• Tracking samples received in the lab.

• Auto-assigning tasks based on analyst availability and training status.

• Sending sample test results directly to the ERP.

• Fulfilling 21 CFR Part 11 compliance. 

Functional Specifications (FS)

The FS document explains how the software meets the URS. Screen flows, automated calculations, regulatory logic such as audit trails and access controls. Functional specifications serve as the baseline for operational qualification (OQ) testing.

Design Specifications (DS)

The DS document covers the technical "how". Treat it as your blueprint:

• Database design: Field definitions, file layouts, and data flow diagrams.

• Logic and process design: Pseudo-code for complex calculations and process logic.

• Security design: Anti-virus provisions and hacker protection parameters.

• Interface design: Data transfer protocols, transmission frequency, and failure-handling logic.

• Architectural design: Hardware support, Operating System versions, network requirements.

• Peripheral support: Scanners, printers, and lab devices.

How to perform and report the CSV tests

GAMP 5 recognises two main verification approaches: linear (V-model) and iterative (Agile) (ISPE, 2022). Choose based on how stable your requirements really are. See also GAMP 5 vs GAMP 5 Second Edition differences.

Linear approach (V model)

The V-model maps each test phase to a specification phase. It works when requirements are settled before development begins, and it scales with system complexity, risk, and novelty.

Each test phase verifies a specification:

• Installation Qualification (IQ) verifies Design Specifications (DS).

• Operational Qualification (OQ) verifies Functional Specifications (FS).

• Performance Qualification (PQ) verifies the User Requirements Specifications (URS).

In a strict CSV approach, you run one formal test per requirement. The validation report must mirror the plan, document every result, and back each pass with evidence such as screenshots.

This exhaustive approach makes CSV highly document-oriented, frequently generating large, burdensome volumes of paperwork. 

Iterative and incremental approach (Agile)

Agile collapses planning, specification, configuration, verification, and reporting into iterative loops. You demonstrate fitness for intended use without printing a forest, which suits custom software and rapidly evolving platforms.

Implement a robust and efficient CSV process according to GAMP 5 without the headache.

What is Computer Software Assurance (CSA)?

Computer Software Assurance (CSA) is a risk-based approach to establish and maintain confidence that software is fit for its intended use.

The framework starts from one question. If this software fails, what is the worst thing that can happen to a patient or to product quality? Your answer drives the level of assurance effort you apply.

CSA enforces a least-burdensome principle. Activities scale to be no more than necessary to control identified risks. Less paperwork, more thinking, same compliance.

CSA also keeps systems controlled across their lifecycle, so the validated state is continuous, not a snapshot you renew every two years.

What CSA provides in practice:

• More testing where it matters most. Higher confidence in real-world system performance.

• Risk-based assurance. Rigour scales to risk to patient safety and product quality.

• Credit for upstream work. Take credit for prior risk controls and supplier validation.

• Testing over scripting. Unscripted methods take the lead on low- and medium-risk components.

CSA emphasizes critical thinking and risk-based validation, but that’s difficult to achieve with manual, document-heavy processes or SharePoint. An eQMS for life sciences, like Scilife, can help you operationalize CSA without sacrificing control.

Detailed risk framework for CSA

How to identify the intended use of software for CSA

The FDA splits software into three categories based on intended use:

• Direct production or quality system software: Automates production processes, inspections, testing, data collection, quality processes (CAPA, complaints, change control), or holds formal quality records.

• Support software: Development tools, software automating test execution for production or quality applications, or general record-keeping outside official quality records.

• Out-of-scope software: General business operations (email, accounting) or infrastructure unrelated to production or quality. No formal validation required under 21 CFR 820 obligations.

How to determine the risk-based approach for CSA

Run a risk analysis across configuration management, system security, data storage, data transfer, and operational error. Identify foreseeable failure modes and the consequences each would trigger.

High process risk examples

A function is at high risk when its failure foreseeably compromises safety. The FDA gives examples that include software that:

• Maintains critical process parameters (temperature, pressure, humidity) essential to device safety.

• Measures, inspects, and determines acceptability of a product with limited or no human review.

• Performs automated adjustments of process parameters based on continuous data monitoring.

• Produces labeling or directions for use necessary for the safe operation of a medical device.

• Automates critical tracking, trending, or surveillance data essential to safety.

Lower process risk examples

A function is lower risk when its failure does not directly compromise safety.

Examples include software that:

• Collects and records process data for monitoring or review purposes without direct impact on production performance.

• Routes quality system tasks such as complaint logging, change control tracking, document control management.

• Manages data storage, automates established manual calculations, or generates exception alerts inside an established process.

The risk assessment process follows three steps:

1. Identify the intended use: Define what the software is meant to do and which functions are critical to safety, quality, or compliance.

2. Determine potential failure impact: Evaluate severity across patient safety, product quality, and data integrity.

3. Categorize features based on risk: Classify features into High Risk (requiring strong validation and robust scripted testing), Medium Risk (requiring moderate validation and risk-based activities), and Low Risk (requiring minimal validation and exploratory testing).

Risk vs. testing intensity matrix

Risk level drives testing approach, which drives documentation. The table below sets out the relationship.

To make the matrix work in practice, four habits matter. Apply critical thinking to focus on what compliance actually requires. Reduce over-validation on non-critical features. Take supplier test evidence and stop duplicating it. Automate the assurance lifecycle with modern digital quality tools.

“By applying critical thinking, we can enhance our ability to ensure that our systems perform as intended consistently and safely and meet all the regulatory requirements while not being a huge money and time pit for organizations.”

Joseph Turton, QA Manager and CSV Specialist at The Knowlogy

How to determine the right assurance activities for CSA

Risk level dictates how you test. CSA recognises two families: unscripted and scripted:

Unscripted testing

The tester exercises the software dynamically, using knowledge, skill, and experience of past failures. No step-by-step instructions. It contains minimal documentation and includes:

• Ad-hoc testing: Free-form execution without formal scripts.

• Error-guessing: Tests built on the tester's experience of past failures and common human errors.

• Exploratory testing: Real-time test cases that probe for hidden properties, unanticipated user behaviours, or accidental misuse.

Scripted testing

A pre-approved plan with step-by-step instructions, expected results, and pass/fail criteria. Two variants:

• Robust scripted testing: Used for high-risk components. It includes full traceability to requirements, strict evidence of repeatability and precise auditability.

• Limited scripted testing: A hybrid approach scaled according to risk. Scripted on high-risk parameters, unscripted on the rest, all inside the same validation effort.

How to record the CSA

According to the FDA, the assurance record must contain:

1. The clear intended use of the software feature, function, or operation.

2. The specific risk determination based on your process analysis.

3. Documentation of the assurance activities conducted, describing the testing performed and any deviations or issues found along with their final disposition.

4. A clear conclusion statement declaring the acceptability of the results.

5. The exact date of testing alongside the name of the person who conducted the assessment.

6. Evidence of formal review and approval when appropriate.

CSV vs. CSA: side-by-side comparison

Key Similarities

• Both demand testing and objective evidence to demonstrate system reliability and compliance.
• Both ensure that computerized applications used in regulated industries meet regulatory and operational requirements.
• Both involve structured planning, execution, documentation, and formal reporting.

Key differences

When to use CSV vs. CSA

In practice, you rarely choose one and drop the other. You apply both, but at different intensities.

• Lean toward CSV when requirements are locked, the system is monolithic, the change rate is low, and your regulatory authority specifically requires the V-model evidence chain.

• Lean toward CSA when the system is configurable or SaaS, change is frequent, supplier evidence is strong, and the FDA QMSR (Part 820 incorporating ISO 13485:2016) is your reference frame.

• Blend the two when you have a high-risk subsystem inside a low-risk platform. Robust scripted tests on the dangerous bits, unscripted on the rest, one validation report covering both.

How to transition from CSV to CSA in 5 steps

Transitioning from traditional validation to an agile CSA model can be achieved gradually using a five-step framework:

1. Evaluate current validation practices: Audit your existing protocols. Hunt for duplicated or excessive documentation.

2. Apply risk-based thinking: Stop testing every package end-to-end. Target high-risk features.

3. Reduce unnecessary scripted tests: Scale back rigid step-by-step scripts for low and medium-risk components. Replace with exploratory or ad-hoc methods.

4. Adopt modern assurance tools: Replace manual workflows with purpose-built electronic quality management systems.

5. Train teams on CSA principles: Move people from checkbox compliance to critical thinking. This takes longer than the tooling change.

Benefits of CSA 

In a nutshell, CSA is a more critical thinking-driven and efficient approach compared with the CSV approach. You spend less on paperwork and more on the failure modes that actually move the risk needle.

That said, your objective shapes the choice. As a vendor, you may stick with exhaustive evidence so customers leave no stone unturned. As a user, prioritise testing the failure modes for high-risk features.

The bigger shift is cultural. CSA puts critical thinking at the centre of validation. It rewards engineers and QA people who understand the process, not those who can produce the heaviest binder. That is the part that takes the longest to land.

Scilife is fully behind this shift. If you want to compare your validation strategy against a modern eQMS approach, get in touch.

Watch our training webinar: Unlocking the power of critical thinking in CSV with a QA Manager and CSV Specialist at The Knowlogy!