CSA vs CSV: what changed
Published 12 min read
Fig. 01Computer software assurance (CSA) is not a replacement for computer system validation (CSV). It is FDA's current advice on how to do validation for production and quality system software: judge each feature by whether its failure could foreseeably compromise safety, spend scripted testing where it could, and keep a lighter record where it could not. The duty to validate, Part 11 included, did not move.
The short answer
FDA guidance, as filed (read 2026-10-22)
The CSA guidance on one sheet
- Title
- Computer Software Assurance for Production and Quality Management System Software
- Issued
- 2026-02-03
- Supersedes
- The final guidance “Computer Software Assurance for Production and Quality System Software”, issued 2025-09-24
- Draft
- 2022-09-13
- Status
- Final. “Contains Nonbinding Recommendations”
- Docket
- FDA-2022-D-0795
- Issued by
- CDRH and CBER, in consultation with CDER, the Office of Combination Products and the Office of Inspections and Investigations
- Covers
- Software used as part of medical device production or the quality management system. Not device software functions.
- Replaces
- Section 6 of the General Principles of Software Validation (2002) and nothing else. The rest of that guidance stands.
Read the header above and two things stand out. CSA is final, current as of February 2026, and it replaces one section of one older guidance. And its scope is device makers' production and quality system software, not every regulated lab. Everything else on this page follows from those two lines.
Common misreading
“CSA replaced CSV.” The guidance says it “supplements” the General Principles of Software Validation and supersedes only its Section 6. Validation is still the requirement; CSA is a way to size it. Teams that say “we moved from CSV to CSA” mean they changed how they validate, not whether.
CSV and CSA side by side
The left column is FDA's 2002 text plus the way many labs actually ran it; the rows marked “in practice” are habit, not anything FDA asked for. The right column is the 2026 guidance in its own words where a short quote fits.
Scroll sideways for every column
| Topic | CSV (GPSV Section 6 and common practice) | CSA (FDA guidance, 2026) |
|---|---|---|
| The first question | Which requirements does the system have, and is there a test for each one? | What is this feature for, and if it fails, could that foreseeably compromise safety? |
| What gets assessed | The system, against a user requirements specification. GPSV 6.1 already allowed validating only the functions in use. | Each feature, function or operation with its own intended use; the whole system when it has only one use. |
| Risk scale | Whatever the firm's SOP set. GPSV 6.1: effort “commensurate with the risk posed by the automated operation”. | Two bins: “high process risk” and “not high process risk”. A firm may keep “moderate” or “low”; those fall under not high. |
| Testing | In practice: scripted protocols with step-by-step instructions, expected results and a signed result for each step, for most functions. | Scripted (robust or limited) or unscripted: scenario, error-guessing and exploratory testing, chosen by risk. FDA writes "may consider", not "must". |
| The vendor's work | GPSV 6.3: the vendor's validation information is “a beginning point”; black-box testing where it is missing. | Vendor assessment (audits, SOC reports, ISO certificates, SDLC, data integrity controls). For some lower-risk features, the vendor's work “may be all the assurance that is needed”. |
| Other controls | Rarely credited in the protocol itself. | Downstream inspection, monitored process parameters and the software's own monitoring data can reduce the assurance effort. |
| The record | GPSV 6.2: user requirements, validation protocol, acceptance criteria, test cases and results, a validation summary. | Intended use, risk result, what was tested, issues found, a conclusion, who and when, approval "when appropriate". No "more evidence than necessary". |
| Evidence form | In practice: a screenshot per step, printed and signed. | Digital records the system keeps (logs, audit trails) “as opposed to paper documentation, screenshots”. |
| The legal duty | Validate: § 11.10(a) for Part 11 systems; ISO 13485 4.1.6, 7.5.6, 7.6 under the QMSR. | The same duty, unchanged. CSA is a way of meeting it, not a new rule. |
| FDA text | General Principles of Software Validation, Section 6 (2002). | CSA guidance (2026-02-03), which supersedes that Section 6 only. |
Read 2026-10-22: GPSV Section 6 (PDF) and the CSA guidance (PDF), both from fda.gov. The wording outside quotes is our reading.
The pattern in the table: the law row is the only one that reads the same on both sides. If your current validation pack follows the left column, the full lifecycle it came from is in computer system validation for small labs, and the tools that run it on paper or screen are compared in paperless validation software.
Fig. 02What actually changed
Risk-based validation was not invented in 2025. GPSV 6.1 already said the “level of validation effort should be commensurate with the risk posed by the automated operation”. What CSA changes is how that risk is judged, which tests count, whose evidence you may reuse, and how thin the file may be. Four changes carry most of the weight.
01Risk is judged against safety, in two bins
A feature is high process risk “when its failure to perform as intended may result in a quality problem that foreseeably compromises safety”. Everything else is not high, including failures that cause a quality problem with no foreseeable safety effect. FDA's examples of high: software that holds process parameters essential to safety, accepts product with little or no human review, or adjusts the process by itself. Its examples of not high: CAPA routing, complaint logging, change control, procedure management, and data collected for review.
02Unscripted testing is named as acceptable
The guidance lists scenario testing, error guessing and exploratory testing beside scripted testing, and says that for features that are not high risk manufacturers “may consider using unscripted testing methods”. For high risk it suggests “more rigor such as the use of scripted testing or a hybrid approach”. Neither is a rule; FDA adds that unscripted testing can suit a high-risk feature and scripted, automated tests can suit a low one.
03The vendor's work and your other controls count
A risk-based look at the vendor (audit where it makes sense, SOC reports, ISO certificates, its development and testing practice, its data integrity controls) becomes part of the assurance. The vendor's own validation can be “the starting point”, and for some lower-risk features “this may be all the assurance that is needed”. Downstream inspection, monitored parameters and the system's own error logs can also cut the testing you add.
04Less paper for features that are not high risk
The record for an unscripted test is a summary, the issues found, a conclusion and who tested when. Documentation “need not include more evidence than necessary”, and FDA recommends the system's own logs and audit trails “as opposed to paper documentation, screenshots, or duplicating results already digitally retained”. A high-risk feature still gets the full file: a test protocol, a result for each test case and, in FDA's own example, the signature of the person with signatory authority.
Takeaway
If your validation SOP scores risk on its own scale, keep it, but add one line per feature: could a failure foreseeably compromise safety, yes or no. That answer, not the score, sets the evidence.
What did not change
Most of what a QA lead answers for in an inspection is exactly where it was. CSA is guidance; it moved no regulation.
- Part 11 still requires validation. § 11.10(a) asks for “Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.” The text is the 1997 one; the Part 11 requirements, section by section sets out the rest.
- The predicate rules are unchanged. For device makers the duty now sits in ISO 13485 Subclauses 4.1.6, 7.5.6 and 7.6, which the QMSR incorporates; the old § 820.70(i) is gone. The guide to the QMSR covers that move. Drug, GLP and clinical records keep their own rules.
- Part 11 still applies to the records. CSA's Section V.B says a document Part 820 requires, kept electronically, “would generally be an ‘electronic record’ under Part 11”. The QMSR supplements other parts “except where explicitly stated otherwise”, and Part 11 is not excepted.
- The rest of GPSV stands. Only Section 6 was superseded. Software that is itself a device function is outside CSA and still follows GPSV.
Common misreading
“FDA does not enforce Part 11 validation, so CSA is optional all round.” The 2003 enforcement discretion covers the Part 11 wording of validation (§ 11.10(a), § 11.30). CSA says that policy “expressly does not apply” to validation required under ISO 13485 4.1.6, 7.5.6 and 7.6. A device maker validates its quality system software either way.
Who the guidance is written for
The CSA guidance covers “computers or automated data processing systems used as part of production or the quality management system for medical devices”. It was prepared by CDRH and CBER. That is narrower than most summaries suggest, and it matters for a small lab deciding what to cite.
Scroll sideways for every column
| You are | Does CSA apply? | What governs your validation |
|---|---|---|
| Device maker: production and quality system software | Yes. This is who FDA wrote it for (CDRH and CBER). | CSA, plus ISO 13485 4.1.6, 7.5.6, 7.6 and Part 11 for electronic records. |
| Device maker: software that is part of the device | No. Device software functions are out of scope. | The rest of the General Principles of Software Validation. |
| Drug CGMP lab or manufacturer | Not written for you. CDER was consulted; it is not an issuing centre. | Part 11 and § 211.68. Borrowed risk logic goes in your own SOP, justified there. |
| GLP lab or clinical-trial team | Not written for you. | Part 11 and your predicate rule (Part 58, Part 312 or 812). The same borrowing applies. |
| EU GMP site | Not an EU text. | Annex 11 § 1 already bases “the extent of validation” on “a justified and documented risk assessment”. |
For a lab that is not a device maker, the honest line is that FDA wrote CSA for device makers and its risk ideas are often borrowed elsewhere. Borrowing is reasonable: FDA's 2003 Part 11 guidance already asks for validation sized by a documented risk assessment, and EU Annex 11 says the same. Cite those, not CSA, as your authority.
One system, planned both ways
A small device maker buys an off-the-shelf cloud eQMS for document control, training and nonconformances. Under the habit in the left column, every feature gets a scripted protocol. Under CSA, the risk call decides. The risk calls below follow FDA's own Appendix A, where Example 1 works through a nonconformance system and Example 2 a training system, feature by feature.
Scroll sideways for every column
| Feature | CSA risk call | CSV habit | CSA plan |
|---|---|---|---|
| Company single sign-on | Generally not part of production or the QMS | OQ test cases for login, lockout and password rules, screenshot per step. | Infrastructure: no ISO 13485 validation. Who may sign and approve inside the eQMS is tested with the signature row below (§ 11.10(d), (g)). |
| Approval e-signature on controlled documents | Not high (FDA Example 1) | Scripted protocol per step: name, date, meaning, two components, re-sign after time-out. | Vendor assessment, then scenario testing with real approvers. Check the printed name, date and time and meaning (§ 11.50), the link to the record (§ 11.70) and two components (§ 11.200(a)). |
| Audit trail on documents | Not high | Scripted tests for create, modify, delete; screenshots of each trail entry. | Error guessing: try to edit an approved version, back-date an entry, delete a draft. FDA's Example 2 even tries to delete the trail. Keep the system's own trail export as the evidence (§ 11.10(e)). |
| Training task on SOP revision | Not high (FDA Example 2, a training system) | Scripted test of the assignment rule for each role. | Error guessing: try to get around the assignment flow and the access rules, as FDA's training-system example does. |
| Nonconformance initiation | Not high, while containment runs by its own procedure (FDA Example 1) | Full scripted protocol of the workflow. | Exploratory testing with high-level objectives; summary of what was tested and the issues found. |
| Prompt for correction or removal of distributed product | High (FDA Example 1) | Full scripted protocol. | Detailed scripted protocol of the interactions and failure modes, repeated across scenarios, approved and signed. |
| Open-items dashboard | Not high, if it only displays data for review | Scripted test of every widget and filter. | Vendor records plus installation and configuration. If complaint trending feeds safety decisions, re-classify it as high. |
Two things are easy to miss. The e-signature is not high process risk in FDA's example, yet it still has to meet Part 11: the scenario test is where you prove the manifestation, the link and the two components. And the single sign-on row drops out of validation only because FDA treats user authentication as infrastructure; the approval rights inside the eQMS stay in scope. Whether a record in that system is a Part 11 record at all is the question the Part 11 applicability checker answers.
Takeaway
Your split will differ: FDA's own MES example shows that software which adjusts critical production parameters by itself lands in the high bin. Do the risk call per feature in the CSA validation scope planner and let it, not the habit, set where the scripted protocols go.
Moving a CSV procedure to CSA
You do not rewrite the validation SOP from scratch. You change what drives the evidence. Six steps, in the order the guidance runs them:
- 01
List the features and their intended use
Per system, write what each feature, function or operation is for, and whether it is used directly, supports production or the quality system, or is outside it (email, accounting, networking). FDA recommends you document that decision. A URS already holds most of it.
- 02
Make the safety call for each one
High process risk or not high, with one sentence of reasoning that names the control downstream, if any. The CSA validation scope planner walks through this per feature.
- 03
Assess the vendor once, by risk
Collect what the vendor publishes (SOC report, ISO certificate, release notes, its test evidence) and keep the assessment under purchasing controls. Decide which features its evidence already covers.
- 04
Choose the assurance activity
Scripted or hybrid for high risk; scenario, error-guessing or exploratory testing where it fits the rest. Part 11 features (signatures, audit trail, access) get tested against their cites whatever their risk bin.
- 05
Write the record to FDA's list
Intended use, risk result, what was tested, issues, conclusion, who and when, approval where your SOP needs it. Export the system's logs instead of screenshots. A traceability matrix still helps for the high-risk rows.
- 06
Keep the validated state
Run every upgrade or configuration change through the same risk call. Monitoring data the system collects counts as part of the assurance.
Takeaway
The full lifecycle (plan, requirements, protocols, report, periodic review) is laid out in computer system validation for small labs. CSA changes the size of each step, not the steps.
CSA vs CSV on one sheet
- CSA is
- FDA guidance on how to validate production and quality system software by risk. Final, issued 2026-02-03.
- It replaces
- Section 6 of FDA's General Principles of Software Validation. Nothing else.
- Still required
- Validation: § 11.10(a) for Part 11 systems; ISO 13485 4.1.6, 7.5.6 and 7.6 under the QMSR.
- Risk
- High process risk if a failure may lead to a quality problem that foreseeably compromises safety. Everything else is not high.
- Testing
- Scripted or a hybrid for high risk; scenario, error-guessing or exploratory testing may fit the rest.
- Vendor
- Assess the vendor by risk; its own validation records can carry low-risk features.
- Record
- Intended use, risk result, what was tested, issues, conclusion, who and when. Logs over screenshots.
- Written for
- Medical device makers. Drug and GLP labs borrow the logic; their predicate rules still govern.
Questions
Does CSA replace CSV?
No. The CSA guidance says it “supplements” the General Principles of Software Validation and supersedes only its Section 6. The duty to validate is untouched; CSA is FDA's current advice on how much evidence that validation needs and what form it can take. A team that runs CSA is still doing computer system validation.
Is the CSA guidance still a draft?
No. The draft came out on September 13, 2022. FDA finalised it on September 24, 2025, then reissued it on February 3, 2026 as “Computer Software Assurance for Production and Quality Management System Software”. The 2026 version is the one to cite.
Is CSA mandatory?
No guidance is. The document carries FDA's line “Contains Nonbinding Recommendations” and says you can use another approach if it meets the regulations. What is mandatory is validation itself, under the QMSR for device makers and under § 11.10(a) of Part 11 for any system holding Part 11 records.
Can a drug or GLP lab use CSA?
FDA wrote CSA for device makers; its risk ideas are often borrowed elsewhere. A drug or GLP lab that adopts them should write the reasoning into its own validation SOP and tie it to its predicate rules (for example drug CGMP's § 211.68), not to the CSA guidance alone. FDA's 2003 Part 11 guidance already asks for validation based on “a justified and documented risk assessment”.
Does unscripted testing mean no documentation?
No. Table 1 of the guidance still expects, for each unscripted test, the intended use, the risk result, a summary of what was tested, the issues found, a conclusion, and who tested and when. Exploratory testing also needs high-level objectives with pass or fail criteria written before you start.
Do IQ, OQ and PQ go away under CSA?
The guidance does not use those labels. It talks of installation, configuration and assurance activities, and keeps scripted protocols for high process risk features. Many teams keep the IQ, OQ and PQ names in their protocol templates and simply write fewer, shorter test cases for the features that are not high risk.
Where does GAMP 5 fit?
GAMP 5 is ISPE industry guidance, not regulation. Its second edition (July 2022) discusses FDA's CSA work, and the CSA guidance names it as a resource for testing methods. The plain-words guide to GAMP 5 covers how the two sit together.
Sources
Regulation text quoted from the eCFR and EudraLex; guidance quoted from FDA. General information, not regulatory advice.
- Computer Software Assurance for Production and Quality Management System Software (final guidance, February 3, 2026), FDAread 2026-10-22
- Computer Software Assurance guidance, PDF, FDAread 2026-10-22
- Computer Software Assurance for Production and Quality System Software: final guidance availability, 90 FR 45945, Federal Registerread 2026-10-22
- Computer Software Assurance: draft guidance availability, 87 FR 56059, Federal Registerread 2026-10-22
- General Principles of Software Validation (January 2002), Section 6, FDAread 2026-10-22
- 21 CFR Part 11, Electronic Records; Electronic Signatures, § 11.10(a), eCFRread 2026-10-22
- Part 11, Electronic Records; Electronic Signatures — Scope and Application (2003 guidance), FDAread 2026-10-22
- 21 CFR Part 820, Quality Management System Regulation, eCFRread 2026-10-22
- EudraLex Volume 4, Annex 11: Computerised Systems (2011), § 1, European Commissionread 2026-10-22
- GAMP 5 Guide, 2nd Edition (product page), ISPEread 2026-10-22