Computer system validation is the underlying obligation, proving a system does what it is meant to do. Computer Software Assurance is a way of carrying out that obligation with less scripted overhead. CSA is a method inside CSV, not a replacement for it.
The requirement to know your systems, assess their risk, and hold evidence that they work as intended has not moved. Data integrity expectations under ALCOA+ have not moved. A vendor telling a compliance team that CSA means less oversight is describing a shortcut, not the actual guidance.
What changed is the testing method for lower risk functionality. Instead of a fully scripted test case with a screenshot for every step, a tester can use unscripted, exploratory testing guided by critical thinking, and record the outcome more lightly. The system still needs to be tested. The record of that testing gets thinner for the parts that do not carry much risk.
If someone describes a project plan, that is CSV, the overall obligation and lifecycle. If someone describes how a specific feature got tested, scripted versus unscripted, that is a CSA decision inside that lifecycle. Confusing the two is how teams end up either over testing everything or under documenting things that actually mattered.
A short walkthrough of how GxPForge keeps traceability current as your team works, instead of reconstructing it before a release.
Book a demo