Most CSA transitions do not reduce effort. They rename it. The documents get new titles, the word assurance replaces the word validation, and the same volume of scripted test scripts gets written because nobody was willing to decide which requirements did not need them.
The FDA finalised its Computer Software Assurance guidance in September 2025 and reissued it in February 2026, superseding Section 6 of General Principles of Software Validation. The reduction it permits is real and it is conditional: depth has to follow risk per requirement, and the reasoning has to be written down. The second half is where programmes fail.
This is how we run CSA services so the effort actually comes down.
Risk is per requirement, not per system
This is the single most common error. A system gets assessed as high risk, and high risk then applies uniformly to every requirement in it, including the search box.
Systems do not have one risk level. An MES contains recipe approval, which can affect product, and a dashboard, which cannot. Assessing at system level and inheriting downwards guarantees that the dashboard is tested as though it could kill someone, and that is where the effort goes.
Assess at the requirement level, or at the level of small groups of related requirements. Two questions settle most of it: if this function behaved incorrectly, could it affect product quality, patient safety or data integrity — and would the failure be detected by something else before it mattered. The second question matters as much as the first and is usually skipped. A function whose failure is caught immediately by a downstream control carries less risk than its description suggests. AI Risk Assessment is how we keep the determination explicit rather than implied.
The four assurance paths
Once risk is determined per requirement, each requirement gets an assurance approach proportionate to it. In practice there are four, and most organisations only use one.
- Scripted testing. Predefined steps and expected results. Reserve it for high-risk functions, and write it at the boundaries rather than through the middle — the value is in the edge case, not in the happy path. Test case generation is how we produce them at that depth.
- Unscripted and exploratory testing. A qualified person exercises the function with a stated objective and records what was examined and what was found. This is a legitimate assurance activity under the guidance, not a lesser substitute, and it covers the broad low-risk surface efficiently.
- Vendor evidence. Where the supplier has tested something and will show you, assess it and record why it is adequate for your intended use. supplier qualification covers the discipline.
- No testing, with a documented rationale. The one organisations are most reluctant to use and the one that produces the largest reduction. Some requirements genuinely do not warrant independent testing, and saying so with a reason is better practice than generating evidence nobody will read.
Unscripted testing that holds up
The anxiety about unscripted testing is that it looks like nothing happened. That anxiety is well founded when the record is a sentence saying it worked.
An unscripted test record that survives scrutiny contains five things: the objective, who performed it and when, what they actually examined, what they found including anything unexpected, and the conclusion. That is not onerous and it is not a script. The distinction is that the tester decides what to examine rather than following predetermined steps, and the record describes what happened rather than confirming what was predicted.
Done properly, unscripted testing finds more defects per hour than scripted testing, because the tester is thinking rather than executing. Unscripted testing under CSA goes into the mechanics.
Where teams quietly revert to CSV
Three failure patterns, all recognisable.
Risk assessment as a formality. Every requirement comes out high risk, because nobody wants to be the person who marked something low and was wrong. The result is a risk assessment that costs effort and changes nothing. The fix is organisational rather than technical: the person assessing needs the authority to assess low, and the reasoning needs to be reviewable so the decision is shared rather than personal.
Vendor evidence nobody obtained. The plan says vendor evidence will be leveraged. Nobody asked the vendor, the project runs out of time, and scripted tests get written instead. Ask during procurement, when you have leverage.
Unscripted testing performed and not recorded. The testing happens, the record is thin, and at audit it is indistinguishable from untested. This is the most frustrating pattern because the work was done.
What an inspector actually asks
Not whether you followed CSA. Whether your assurance was adequate for the risk, and how you decided.
So the document that matters is the one explaining the reasoning. For each requirement or group: the risk determination, why, the assurance approach chosen, and why that approach is sufficient. With that, a light test set is defensible. Without it, a light test set reads as an under-tested system, and an inspector is entitled to that reading.
The reasoning is the deliverable. That is the whole of CSA in one sentence, and it is the part that gets left out. Defending CSA to an inspector covers the conversation itself.
A realistic sequence
Do not convert the whole estate. Take one system, preferably a mid-risk one with a live implementation, and run it end to end under the new approach. Measure the test volume against what the old approach would have produced, and keep the reasoning document as the template.
Then expand by system rather than by policy. A procedure instructing everyone to be risk-based produces compliance theatre; a worked example produces change. The CSV to CSA transition plan is the transition plan in more detail, and book a demo if you want the first one run alongside your team.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.
