CSA vs CSV: validating quality software after FDA's final Computer Software Assurance guidance

Computer software validation (CSV) and computer software assurance (CSA) aim at the same thing: evidence that software used in production or the quality system is fit for its intended use. The difference is how you get there. Traditional CSV often treats every function with the same scripted, screenshot-heavy testing. CSA, as described in FDA's final guidance, asks you to identify how each function is used, decide whether its failure could compromise safety, and scale the testing and paperwork to that risk. CSA does not remove the requirement to validate. It changes where you spend the effort.

Below: what the guidance says, how it relates to GAMP 5 and EU Annex 11, and what an eQMS vendor's validation package can cover.

Where the FDA guidance stands

FDA's Center for Devices and Radiological Health (CDRH) and Center for Biologics Evaluation and Research (CBER) issued the final guidance Computer Software Assurance for Production and Quality System Software on 24 September 2025, three years after the 2022 draft. On 3 February 2026 FDA replaced it with a revised version, renamed Computer Software Assurance for Production and Quality Management System Software. The guidance history in the document says the revision aligns it with the amended 21 CFR Part 820, the Quality Management System Regulation (QMSR), which took effect on 2 February 2026 and incorporates ISO 13485:2016 by reference. If you work from a copy downloaded in 2025, replace it.

A few points about scope are easy to miss:

• It is guidance, not law. The document says it contains nonbinding recommendations. The legal requirement to validate software used in production or the quality management system comes from Part 820, through ISO 13485 subclauses 4.1.6, 7.5.6 and 7.6.
• It covers device production and quality system software, not software that is itself a medical device. It supersedes Section 6 of FDA's General Principles of Software Validation guidance.
• Cloud is in scope. IaaS, PaaS and SaaS are included when used as part of production or the quality management system.
• General business and infrastructure software is generally out. Email, accounting, networking, user authentication and backup infrastructure not specific to the quality system are generally not in scope.
• Pharma is not the target audience. The guidance was prepared in consultation with CDER but addresses device manufacturers. Medicinal product manufacturers can learn from the reasoning, but it does not replace drug GMP expectations. See the EU section below.

If your QMS is moving to the QMSR at the same time, our article on FDA's QMSR and ISO 13485 covers the wider change.

CSA vs CSV: what actually changes

CSA is a correction to how CSV came to be practised, not a new regulation. The FDA guidance notes that testing alone is often insufficient and that validation effort should be no more than necessary to address the risk. The shift looks like this:

• Starting point. CSV often starts from a template protocol. CSA starts from the intended use of each feature, function or operation.
• Risk. CSV frequently grades everything as "GxP-critical". CSA asks one focused question: could a failure lead to a quality problem that foreseeably compromises safety? If yes, it is high process risk. If not, it is not high process risk, even if you call it moderate or low internally.
• Testing. CSV defaults to pre-approved, step-by-step scripts. CSA accepts unscripted testing (scenario or ad hoc testing, error guessing and exploratory testing) where the risk allows, and keeps scripted testing for higher-risk functions.
• Evidence. CSV collects screenshots of every step. CSA recommends using system logs, audit trails and other digital records rather than screenshots or duplicated results.
• Vendor work. CSV often repeats the supplier's testing. CSA treats the supplier's development practices, validation work and documentation as the starting point and adds only what is missing.

What does not change: you still need a documented decision, objective evidence and a conclusion that the software is fit for its intended use, signed off by someone with the authority to do so.

The four-step CSA framework

1. Identify the intended use

FDA distinguishes software used directly in production or the quality system, such as software that maintains a quality record, from software that supports it, such as tools that test other systems. Both must be validated, but supporting software usually carries lower risk.

The guidance recommends breaking complex software into features, functions and operations, because one product can serve several intended uses. In its spreadsheet example, recording temperature readings needs little beyond vendor assessment and installation, while a custom formula calculating process statistics may need more. Document how you decided what is in scope.

2. Determine the process risk

This is the step that changes the most work. FDA lists examples of functions that are generally not high process risk, and several will look familiar to anyone running an eQMS:

• CAPA routing
• automated logging and tracking of complaints
• automated change control management
• automated procedure management
• collecting and recording data for monitoring and review, without direct impact on production

High process risk examples include software that maintains process parameters essential to device safety, decides product acceptability with limited or no human review, or adjusts the process automatically without additional human review.

This does not mean eQMS workflows need no testing. It means the evidence should match the process risk rather than the patient-safety risk of a production control system.

3. Choose the assurance activities

For high process risk functions, FDA suggests scripted testing or a hybrid of scripted and unscripted testing. For functions that are not high process risk, unscripted methods are appropriate: scenario testing, error guessing, exploratory testing, or a combination. The guidance is clear that these are not rigid categories. Exploratory testing can suit a high-risk function, and automated scripts can be the efficient choice for a low-risk one.

You can reduce effort further by leveraging existing controls: downstream review, purchasing controls, monitoring and the vendor's own testing. FDA accepts that an on-site vendor audit may not be feasible and lists alternatives such as reviewing certifications, SOC reports, development and security documentation, and data integrity controls.

4. Establish the record

FDA recommends that the record includes the intended use, the result of the risk-based analysis, a description of the testing, any issues found, a conclusion on acceptability, who performed the testing and when, and review and approval where appropriate. For unscripted exploratory testing, a high-level test plan with pass/fail criteria per objective is enough. No step-by-step procedure is needed.

Illustrative example: assuring a cloud eQMS

This is an illustrative example, not a template. A 40-person device company adopts a SaaS eQMS for document control, training and CAPAs:

• Document approval with electronic signatures. In FDA's own SaaS example (Appendix A, Example 4), the electronic signature function is rated not high process risk, because failure would compromise compliance but not foreseeably safety. The manufacturer performs scenario testing with users. You would do the same for your configured approval routes in document management: users draft, review and approve a test SOP, and you confirm that the signature records name, date and time, and meaning.
• Access control and audit trail. FDA's example treats these as significant to QMS integrity but still not high process risk. It uses configuration verification plus an automated or scripted check of role permissions that can be re-run after changes. A short, scripted test that confirms each role can and cannot do the right things is reasonable here.
• Training assignment, reminders and records. FDA's learning management system example (Appendix A, Example 2) rates these as not high process risk. It adds unscripted error-guessing to the vendor assessment, such as trying to get around the workflow or delete the audit trail. Recording a handful of such attempts against clear objectives is proportionate.
• Dashboards and reports. These support review. Vendor assessment plus a quick exploratory check that counts match the underlying records is usually sufficient.
• Vendor releases. In FDA's SaaS example, the vendor documents changes and testing for automatic updates, and the manufacturer assesses the impact on its intended use and tests accordingly. Write that into your change control procedure so each release has a recorded impact decision.

How GAMP 5 Second Edition fits

ISPE published GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems (Second Edition) in July 2022. ISPE describes the update as emphasising critical thinking by experienced subject matter experts, encouraging companies to make full use of supplier knowledge and documentation, supporting iterative and incremental development, and discussing FDA's CSA work. FDA's guidance in turn points to GAMP 5 Second Edition as a resource on testing and validation approaches.

The two are complementary. GAMP 5 gives the lifecycle structure that pharma and biotech QA teams already use. CSA gives a sharper way to decide how much testing each function needs.

What EU GMP companies should do with CSA

If you manufacture medicinal products for the EU market, EudraLex Volume 4 Annex 11 is the reference for computerised systems, not the FDA guidance. The current Annex 11 dates from 2011 and is already risk-based. Section 1 asks for decisions on the extent of validation to be based on a justified and documented risk assessment. Section 4.7 asks for evidence of appropriate test methods and test scenarios without prescribing scripts. CSA-style thinking therefore fits the current text reasonably well.

The draft revision of Annex 11 that the European Commission published for consultation in July 2025 is more prescriptive. It expects qualification and validation evidence in the form of executed test scripts and, where relevant, screen dumps (section 9.4). It says test cases should be traceable to requirements (9.5) and that work should follow approved plans, protocols and test scripts detailed enough to be repeated (9.7). In its consultation comments, ISPE pointed out that requiring pre-approved test scripts would prevent unscripted testing. As of early October 2026, the final text has not been published. Our article on the EU GMP Annex 11 revision tracks the status.

A pragmatic position for EU GMP companies today:

• Keep a documented risk assessment per system and, for critical systems, per function.
• Keep traceability from GMP-relevant requirements to tests, as both the 2011 text and the draft expect.
• Use scripted tests for GMP-critical functions such as electronic signatures, audit trails and access control, and justify unscripted testing for lower-risk functions in your validation plan.

What a vendor's validation package can and cannot cover

Buying from a vendor that markets a "validated" system does not end the discussion. The FDA guidance makes manufacturers responsible for choosing the assurance activities, and the draft Annex 11 says the regulated user remains fully responsible when relying on a vendor's qualification (section 7.1).

A good vendor package for a SaaS eQMS can reasonably include:

• a description of the vendor's quality management system and software development lifecycle
• relevant certifications or independent audit reports
• a standard requirements or functional specification for the product
• evidence of the vendor's testing of standard functionality
• release notes and testing summaries for each update
• a description of audit trail, electronic signature, access control, backup and data export controls
• support for your supplier audit or questionnaire, and during inspections

What remains your responsibility:

• the intended use and risk assessment for your processes
• reviewing and approving the requirements as they apply to you (the draft Annex 11 says you should take ownership of the specification, section 6.3)
• the supplier assessment and quality agreement
• verifying your configuration: roles, workflows, numbering and templates
• testing the functions you rely on, at the depth your risk assessment justifies
• the validation summary and the conclusion that the system is fit for use
• assessing each vendor release, periodic review, and keeping SOPs and training aligned with how the system is configured

Common pitfalls

• Treating CSA as permission to skip validation. Unscripted testing still needs objectives, results, issues found and a signed conclusion.
• Rating everything as high risk. If every function is high process risk, you have reproduced CSV with a new name.
• Not justifying the method. An inspector should be able to see why you chose exploratory testing for a function, not just that you did.
• Ignoring automatic updates. A SaaS product changes under you. Without a release assessment step, your validated state is an assumption.

What auditors and inspectors look for

Typical questions: Where is your inventory of GxP computerised systems? How did you decide the risk of each? Show me the evidence for this function, and who approved it. How do you control vendor changes? When did you last review this system? The volume of paper is not the measure. A clear rationale and evidence that matches it is. Data integrity controls such as audit trails and access reviews get particular attention. Our guide to ALCOA+ data integrity covers what that means day to day.

A practical CSA checklist for small teams

1. List every system used in production or the quality system, and mark which are direct and which are supporting.
2. For each system, list the features you actually rely on and their intended use.
3. Rate each as high or not high process risk, with a one-line rationale.
4. Assess the vendor and record what evidence you are leveraging.
5. Choose scripted, unscripted or hybrid testing per feature, and record why.
6. Test your configuration and record objectives, results, issues and conclusions.
7. Use system audit trails and logs as evidence where they are reliable.
8. Approve a short validation summary before go-live.
9. Assess each vendor release through change control.
10. Review the system periodically, and repeat the risk rating if your use changes.

Next step

Start with a short inventory and risk rating of the software you already use. It will show which few functions deserve scripted testing and where lighter assurance is enough. If you are evaluating an eQMS at the same time, QFacts is one option. It provides document control with electronic signatures and audit trails, role-based access, training, CAPAs and change control. You can map its features against your intended uses during the 7-day free trial before deciding how you would assure it.