CSV vs CSA: What Computer Software Assurance Changes

Computer system validation (CSV) is the established practice of proving, with documented evidence, that a computerised system does what it is intended to do. Computer Software Assurance (CSA) is a risk-based approach described by the US FDA that keeps that goal but moves the effort away from producing documents and towards critical thinking and testing where failure would matter most.

For QA, IT and validation teams in Indian and GCC pharma, this matters because validation packs have grown very large while real defects still slip through. CSA offers a defensible way to test smarter, if you understand what it changes and what it leaves untouched.

What traditional CSV looks like in practice

At many sites, CSV has become shorthand for paperwork: a validation plan, user requirements, risk assessment, specifications, IQ, OQ and PQ protocols, a traceability matrix and a summary report, each with several signatures.

Testing is usually fully scripted, with an expected result, actual result, screenshot and signature for every step. Much of the effort goes into low-risk functions such as report layouts, while complex failure modes are rarely explored. Regulations never required this exact form; they ask for validation suited to intended use.

What CSA is and where it came from

In September 2022, FDA's Center for Devices and Radiological Health and Center for Biologics Evaluation and Research published the draft guidance Computer Software Assurance for Production and Quality System Software. It covers software that medical device manufacturers use in production or the quality system, not software that is itself a device. Check FDA's website for the current status and whether the final guidance applies to you.

Pharma companies took notice because the thinking matches ISPE GAMP 5 Second Edition (2022), which puts critical thinking at the centre of computerised system work. For a drug or API manufacturer, CSA is a well-argued model of risk-based assurance, not a rule that replaces existing obligations.

The four CSA steps

1. Identify the intended use. Is the software used directly in production or the quality system, or does it support them indirectly?
2. Determine the risk-based approach. For each function, ask whether a failure could cause a quality problem that compromises safety. If so, it is high process risk; if not, it is not high process risk.
3. Choose assurance activities. Match testing rigour to risk, and use existing evidence such as supplier testing and built-in controls.
4. Establish an appropriate record. Document what was tested, by whom, when, the result and any issues.

The key shift is in step 2. Risk is assessed function by function, not system by system. One LIMS can contain high-risk result calculations and low-risk dashboards.

Scripted vs unscripted testing

Scripted testing follows predefined steps and expected results. It remains the right tool for high-risk functions where you need repeatable, objective evidence, such as a calculation that supports batch release or an electronic signature.

Unscripted testing covers ad hoc testing, error guessing and exploratory testing. An experienced tester works to a defined objective, such as trying to break the sample login workflow, and records what was tested and what was found rather than every click. It often finds defects a script misses, because the tester follows the system's behaviour. Screenshots are captured where they prove something, not by default.

Leveraging vendor evidence

CSA encourages you to use work your supplier has already done. If a supplier assessment shows a mature development and testing process, the supplier's release testing and documentation can reduce what you repeat. You still own the decision and still verify that the configured system meets your intended use.

How CSA fits with Part 11, Annex 11 and GAMP 5

CSA does not replace the rules on electronic records. Where 21 CFR Part 11 applies, its requirements for audit trails, electronic signatures, access control and record retention still stand. For EU markets, EU GMP Annex 11 on computerised systems sets similar expectations, including risk management, supplier oversight and periodic review. Annex 11 has been under revision, so check the current version.

GAMP 5 Second Edition provides the working framework: life cycle, software categories, supplier involvement and scaled verification. The shared message is to focus effort on patient safety, product quality and data integrity, and justify your choices. Data integrity principles apply in full; see ALCOA and data integrity explained.

CSV vs CSA side by side

Worked example: a LIMS upgrade at a Hyderabad API plant

An API manufacturer near Hyderabad supplies regulated export markets and runs a commercial LIMS for raw material, in-process and finished API testing. The vendor releases a major version with a new stability module, redesigned dashboards, changed report templates and security fixes.

Under the old approach, the validation lead would have re-executed the full OQ, several hundred steps with screenshots. Instead, QA, the LIMS administrator and two senior analysts applied a CSA-style assessment to each changed function:

• Specification checks and result calculations: high process risk, because a wrong pass or fail could release a failing batch. Scripted tests with boundary values, including results exactly at the limit and rounding cases.
• Electronic signatures and audit trail: high risk for data integrity. Scripted tests confirming signature linkage and that edits are captured with old and new values.
• New stability module: scripted tests for pull scheduling and trend calculations, exploratory testing for the rest.
• Dashboards and report layouts: not high process risk. Exploratory testing against a written charter, recorded as a short summary.
• Security fixes: vendor release notes reviewed under an existing supplier assessment, plus a post-installation smoke test.

Exploratory testing showed that one dashboard filter hid samples close to their due date, something the old script never checked, and the vendor fixed it before go-live. The final package was far smaller than a full re-execution, yet each record showed why the testing was enough. The team described the approach as GAMP 5 risk-based thinking informed by CSA, not compliance with a device guidance.

Common mistakes

• Treating CSA as permission to stop documenting. You still need a record showing what was tested and why it was enough.
• Rating a whole system as low risk when only some functions are.
• Running unscripted testing with untrained testers and no defined objective.
• Accepting vendor evidence without a supplier assessment.
• Assuming CSA covers Part 11, Annex 11 and data integrity controls.
• Rewriting validation SOPs without briefing QA and auditors.

Key takeaway: CSA does not remove validation. It asks you to identify intended use, judge risk function by function, test hardest where failure could harm patients or product, use supplier evidence wisely and keep records that add value.

Frequently Asked Questions

Does CSA replace computer system validation?

No. Validation is still required; CSA changes how you achieve and document it. The goal remains confidence that software is fit for its intended use. CSA puts the emphasis on risk-based thinking, testing that targets real failure modes and records that add value, rather than maximum paperwork for every function.

Does FDA's CSA guidance apply to pharmaceutical companies?

The September 2022 draft came from FDA's device and biologics centres and covers production and quality system software used by medical device manufacturers. Pharma companies often apply the same principles through GAMP 5 Second Edition. Check FDA's current guidance and your own regulators' expectations before citing CSA as the basis for your approach.

Is unscripted testing acceptable to auditors?

It can be, when it is used for lower-risk functions, performed by competent testers against a defined objective and recorded properly. A good record states what was tested, who tested it, when, what was found and how issues were resolved. Unstructured clicking with no record will not satisfy an auditor or an inspector.

Does CSA change 21 CFR Part 11 or EU GMP Annex 11 requirements?

No. CSA addresses how much assurance activity is appropriate, not the rules for electronic records and signatures. Where Part 11 or Annex 11 applies, audit trails, access control, electronic signatures, data retention and periodic review are still needed. Many teams use CSA thinking to focus their testing on exactly those controls.

Next steps

To build practical skills in risk-based validation and audit trail review, see Data Integrity & Computerised System Validation. If you would like help choosing the right course for your role, speak to a counsellor.

Related reading: GAMP 5 software categories explained, ALCOA and data integrity explained and deviation vs change control vs CAPA.