CSV to CSA
CSA does not replace CSV. It changes how test effort is distributed inside it — and most transitions stall on procedure rather than technique.
- FDA
- EMA
- MHRA
- PMDA
- CDSCO
- GAMP 5
- ICH Q9
- 21 CFR Part 11
Moving from CSV to CSA means sizing test effort to the consequence of failure rather than applying uniform depth. High-risk requirements still get scripted testing with full evidence; others may be covered by unscripted testing with a session record, or by assessed supplier evidence. The written rationale is what makes the reduction defensible rather than merely smaller.
Most organisations have adopted CSA on paper only
They have updated a policy and nothing else. The validation SOP still mandates scripted testing, the protocol templates only accommodate scripted steps, and QA has not agreed what an acceptable rationale looks like. So teams keep scripting everything, now under a CSA heading.
The effort is unchanged, and the organisation concludes CSA does not work — when what did not work was changing the words without changing the machinery.
The opposite failure is rarer and worse: testing reduced because CSA permits it, with no documented reasoning. That is not CSA. It is under-testing with a justification borrowed from a guidance document, and an inspector will read it exactly that way.
What actually changes
CSA is applied where the decision lives — at the individual requirement. Each one is assessed for what would happen if it failed and whether a failure would be caught downstream. That assessment determines which of three assurance activities it receives.
Scripted testing
Pre-defined steps, expected results, captured evidence. For requirements where failure would reach the patient or corrupt a record.
Unscripted testing
Exploratory or error-guessing testing with a session record: tester, scope, duration, findings. For non-high-risk functions.
Supplier evidence
The vendor's own executed testing, reviewed and accepted — where you hold a current supplier assessment saying what you rely on.
A system is not high risk or low risk. It is a collection of requirements with very different consequences, and treating it as one risk level is what produces uniform depth in the first place.
The four phases that make it stick
Make it permissible
Nothing else can start until the paperwork allows it. Update the validation SOP so unscripted testing and assessed supplier evidence are explicitly permitted. Define how risk maps to assurance activity — the mapping must be stated, not left to judgement in the moment. Agree the QA position in writing before the first package, not at approval. Rebuild the protocol templates: one that only accommodates scripted steps will quietly enforce scripted testing forever.
Build the judgement
Risk assessment is a skill, and teams who have only ever scripted everything have never had to justify doing less. Train assessors on consequence rather than complexity — the commonest error is scoring a feature high because it is technically complicated rather than because failure would matter. Produce two or three worked examples across different risk levels. Then calibrate: have several people assess the same system independently and compare. Wide divergence means the criteria are not yet usable.
Prove it on new work
Establish the model where there is no legacy to unpick. Choose a real project of modest risk with a team who will engage. Track effort against your old baseline so you can answer whether it is working. Then review the package as if under inspection, with someone probing the rationale — the rationale is what is new, so that is what to test. Feed the lessons back into the templates before the second system, not after the tenth.
Scale carefully
Extend by system class, where the existing rationale largely transfers. Leave the already-validated legacy estate alone until a change or periodic review gives a reason to revisit. Refresh supplier assessments — relying on vendor evidence requires current ones, and this becomes the bottleneck at scale. Have internal audit check whether risk decisions are sound rather than whether the package is thick.
Expect the first CSA package to take longer than its CSV equivalent. You are building judgement and precedent as well as a validation package; the saving arrives from the third system onward.
The rationale is the deliverable
A reduced test effort with no written reasoning is not CSA. The reason each requirement received the depth it did has to be captured when the decision is made, not reconstructed when someone asks — a rationale written after an audit question reads exactly like one.
That record is what gets the reduction through QA approval, and what makes it survivable at inspection. It is also why the reasoning has to be visible before the package reaches the approver: a CSA rationale rejected at approval costs more time than scripting everything would have.
Common questions
What is the difference between CSV and CSA?+
CSV is the activity: producing documented evidence that a GxP system is fit for its intended use. CSA is FDA's guidance on how to size the effort inside it. You still produce a validation lifecycle, a traceability matrix and a summary report. What changes is how much testing each individual requirement receives, and on what documented basis.
Is FDA's CSA guidance final?+
Yes. It was issued as a draft in September 2022 and finalised on 24 September 2025, superseding the draft. It applies to computers and automated data processing systems used as part of production or the quality system. Material still describing CSA as a draft is out of date.
Does CSA mean less documentation?+
It means less testing on some requirements, with a recorded reason. The lifecycle documentation is unchanged — plan, requirements, risk assessment, protocols, executed records, traceability matrix, summary report. Because document assembly is usually the real bottleneck, teams expecting CSA alone to halve their effort are generally disappointed.
Why do CSV to CSA transitions fail?+
Almost always for procedural reasons. The validation SOP still mandates scripted testing, the protocol templates only accommodate scripted steps, assessors have never had to justify testing less, or QA sees the new approach for the first time at approval and rejects the rationale. None of these are technical problems, and none are fixed by training alone.
What is unscripted testing and is it acceptable?+
Exploratory, ad-hoc or error-guessing testing performed without pre-defined steps, documented with a session record naming the tester, the scope covered, the duration and the findings. FDA explicitly recognises it as an assurance activity for non-high-risk functions. Findings are recorded and resolved exactly as they would be from a scripted test — unscripted does not mean unevidenced.
Do we have to re-validate existing systems under CSA?+
No. Systems validated under a traditional approach remain validated. Revisit them when a change, an upgrade or a periodic review gives you a reason to, and apply CSA to new work. Deliberately re-baselining an entire estate is a much larger undertaking than it first appears and rarely survives contact with a budget.
How much testing can we actually remove?+
It depends entirely on your risk profile and how much of your estate is configured commercial software with assessable supplier evidence. Any vendor quoting a fixed percentage without seeing your systems is guessing. What matters is that whatever reduction the assessment produces arrives with a written rationale attached — a thinner package without one is under-testing, and reads that way.
Where to go next
Work through it with our CSA framework and the transition whitepaper. For delivery see our CSA service, or how GxP Copilot applies CSA per requirement.
See it on your own data. In 30 minutes.
Bring a system, a URS, or an AE listing. We'll show you how GxP Copilot and TraceDraft compress the validation and clinical documentation cycle without compromising Part 11 or Annex 22 posture.