Computerized Systems · 8 min read

CSA vs CSV: What Actually Changes in Practice

Most organizations adopting computer software assurance change their vocabulary before they change their decisions. The result is a validation program that costs the same and produces the same binders, now with a different cover page.

The change is where effort goes, not how much

CSA does not lower the bar for high-risk functionality. It reallocates effort. Functions whose failure could compromise product quality, patient safety or record integrity still warrant scripted testing, documented traceability and formal evidence. Functions whose failure would be immediately visible and trivially correctable do not.

The organizations that get value from CSA are the ones that genuinely stop doing the low-value work. Writing the same 200-step script for a document-management notification rule and calling it 'risk-based' is not CSA.

Intended use is the pivot point

Every assurance decision descends from a clear statement of what the system is used for in your process, and what it is explicitly not used for. Vague intended-use statements produce vague risk assessments, which produce testing scope determined by habit rather than analysis.

  • State the process the system supports and the records it creates or controls
  • State the decisions made from those records
  • State what the system is not used for, so scope stays bounded
  • Revisit the statement whenever configuration or process changes

Unscripted testing still needs evidence

Exploratory and ad-hoc testing are legitimate assurance activities, but 'unscripted' does not mean 'undocumented'. A reviewer should be able to determine who tested, what was covered, what the system did, and what conclusion was reached. Screenshots without context, or a checkbox with no record of what was exercised, will not survive inspection.

What does not change

  • Part 11 obligations for electronic records and signatures
  • Data integrity expectations across the record lifecycle
  • Change control and periodic review
  • The need for a documented, defensible rationale
  • Supplier assessment as the basis for leveraging vendor work

A practical adoption sequence

  • Update policy and SOPs so risk-based assurance is explicitly authorized
  • Build a short, usable intended-use and risk worksheet
  • Define assurance activity tiers with concrete evidence expectations
  • Pilot on two systems — one high risk, one low — and compare effort
  • Train reviewers and approvers, not just authors

Information published on ValidationEngineering.com is educational and informational. It is not legal or regulatory advice and is not a guarantee of regulatory compliance or of any inspection outcome. Organizations remain responsible for their own quality decisions.