From CSV to CSA: What the Assurance Approach Changes in Practice
Computer software assurance allocates effort by risk: determine the intended use, assess what failure would affect, then choose an assurance activity proportionate to that. It shifts effort toward thinking and away from uniform scripted testing. It does not reduce the obligation to know the system is fit for use.
The appeal is obvious and is also where implementations go wrong. CSA gets read as permission to produce less documentation, the documentation is duly reduced, and the risk determination that was supposed to justify the reduction never happens. That version is harder to defend than the scripted approach it replaced.
This guide sets out where the effort actually moves, how to determine risk, which assurance activities suit which risk level, and what the approach does not excuse. It sits under what you own and what the vendor owns in eClinical validation.
After reading this you will be able to:
- Determine software risk from intended use rather than from complexity
- Choose an assurance activity that matches the risk you determined
- Size the record to the activity instead of to a house template
- Recognize an implementation that reduced documentation without doing the thinking
Where the Effort Moves
The first column is the one that gets skipped, and it is the one that makes everything else defensible. Determining intended use sounds like a formality until you try to write it for a feature and discover that two people in the room believed it did different things.
The second column is redistribution rather than reduction. High-risk features may receive more attention than they did under a uniform approach, because uniform effort spread across everything is by definition not concentrated anywhere.
Determining Risk
The question is what happens if the software fails. Not how complicated it is, not how much it cost, and not how new it is.
Notice that the same product appears at different levels depending on the feature and the use. An EDC calculating an eligibility flag that a site relies on is in a different row from the same EDC producing an enrollment report for a management meeting. Assessing at product level rather than feature level is the error that makes everything either over or under assured.
The last row is worth attention. Where a vendor has already assured a feature, that evidence can be used rather than reproduced, provided you verify your configuration of it. What the vendor covers and what remains yours is set out in what the vendor validates and what you still own.
Choosing the Activity
Unscripted testing is the one that causes the most discomfort, usually because it sounds like testing without rigor. It is better understood as testing by someone who knows what the feature should do, exercising it the way a user would, and recording what they covered and found. The rigor sits in the tester’s knowledge rather than in the script.
Error guessing is underrated and worth using everywhere regardless of risk level. Deliberately trying the inputs most likely to break something finds more than a script written from the specification, because a script written from the specification tests what the specification anticipated.
What CSA Does Not Excuse
Three things remain unchanged, and they are the ones an implementation under time pressure tends to drop.
The obligation to know the system is fit for its intended use is not reduced. The requirement to record what you did is not removed, only sized. And the risk determination itself has to be documented with its rationale, because without it there is no basis for any of the reductions and an inspector is looking at a system that was tested less for no stated reason.
The rationale is the artifact that makes CSA defensible. A risk determination with scores and no reasoning behind them is a spreadsheet, not a justification.
Adopting It Without a Policy Rewrite
Most organizations do not switch wholesale, and attempting to is a good way to stall.
A more workable route is to take one system, reassess each feature by intended use and impact, and compare the result against what was actually tested under the existing approach. The comparison tends to make the argument by itself, because it usually shows heavy scripted effort on low-impact features and thin coverage on something that matters.
From there the approach extends to the next system rather than being retrofitted across everything. Changes to already-validated systems are where it pays off fastest, since the scoping question is the same one covered in scoping revalidation after a mid-study change.
The Case That Breaks Scripted Testing Entirely
There is one category where the assurance approach is not an efficiency improvement but a necessity: features whose output is not deterministic.
A test script states an expected result. A model that produces a different plausible output on two runs of the same input has no single expected result to assert, which means the scripted approach has nothing to attach to. Assurance built on intended use, bounded risk, monitoring and human review is the only form that applies. That is worked through in validating AI and machine learning features under GxP.
Clinical and R&D AI covers where those features genuinely earn their place in a regulated workflow and where they do not.
References
- Computer Software Assurance for Production and Quality System Software. US Food and Drug Administration guidance for industry. www.fda.gov
- 21 CFR Part 11, Electronic Records; Electronic Signatures. US Code of Federal Regulations, Title 21, Part 11. www.ecfr.gov
- Annex 11, Computerised Systems. EudraLex Volume 4, Good Manufacturing Practice guidelines. health.ec.europa.eu
This guide describes process and regulatory expectations in general terms and is not legal or regulatory advice. Confirm the current version and applicability of any standard or guidance for your study and region.
Frequently Asked Questions
What is computer software assurance?
An approach that allocates validation effort according to the risk the software presents, rather than applying uniform scripted testing to everything. It starts from intended use, determines whether failure would directly affect patient safety or product quality, and then selects an assurance activity proportionate to that. The emphasis shifts toward critical thinking about what matters and away from producing documentation volume as evidence of rigor.
Does CSA mean we can test less?
It means testing differently, and for high-risk features it may mean testing more. What reduces is scripted testing and documentation applied to low-risk features where it was adding paperwork rather than assurance. If your implementation produced only reductions across the board, the risk determination probably was not driving the decisions, and that is the version of CSA that does not survive scrutiny.
How do we determine whether software is high risk?
Ask what happens if it fails, not how complex it is. Software that directly affects patient safety or product quality is high risk. So is software producing a record that someone relies on to make a decision. Software that supports a quality process indirectly, or that is administrative, sits lower. The same product can appear at two levels depending on which feature you are assessing and what you use it for.
What counts as acceptable evidence under an assurance approach?
Enough to show the activity happened, what it covered, what it found and who did it. For unscripted testing that can be a concise record of the tester, the scope exercised, the issues raised and the conclusion. For high-risk scripted testing it remains a full record with steps, expected results, actual results, deviations and approval. The sizing follows the risk rather than a house template.
Does CSA replace CSV?
It is better understood as a way of doing validation rather than a replacement for the obligation. The requirement to have assurance that a system is fit for its intended use does not change. What changes is how effort is allocated to reach that assurance, and how much of it is expressed as scripted testing versus other activities. Organizations typically move toward it gradually, feature by feature, rather than switching wholesale.
Can Nirmitee Healthtech help us move from CSV to CSA?
Yes, and the practical entry point is a risk determination exercise on an existing system rather than a policy rewrite. Taking one validated system, reassessing each feature by intended use and impact, and comparing the result against what was actually tested usually makes the case on its own. From there the approach can be applied to the next system rather than retrofitted everywhere at once.
