For twenty years computer system validation in life sciences has been dominated by volume: long IQ/OQ/PQ protocols, screenshots of every step, test scripts that exercise the obvious path and miss the risky one. FDA's Computer Software Assurance (CSA) guidance, finalised in 2025 for production and quality system software, formally endorses a different approach.
The core idea
Identify the intended use of each function, assess the risk of that function failing (to product quality and patient safety), and choose assurance activities proportionate to that risk. High-risk functions get scripted testing with objective evidence. Lower-risk functions can be covered by unscripted or ad hoc testing, vendor evidence, or documented exploratory testing. The record of the thinking is as important as the record of the testing.
What CSA is not
It is not a licence to skip validation, and it does not change 21 CFR Part 11 expectations for electronic records and signatures. Audit trails, access controls and data integrity still need evidence. What changes is how much evidence is required for functions that cannot hurt anyone.
Where teams go wrong
- Applying CSA labels to the same old scripts, so the paperwork shrinks but the risk thinking is absent.
- Treating vendor documentation as sufficient without a documented supplier assessment.
- Forgetting that SaaS releases arrive on the vendor's schedule; the assurance approach must cover change, not only initial deployment.
A workable model
- Write the intended-use statement and a functional risk assessment before any test scripts.
- Classify functions into scripted, unscripted and vendor-covered, and record why.
- Keep a traceability view from requirement to risk to assurance activity.
- Define the periodic review and the change assessment process for releases.
Our validation and CSV consultants help organisations move from CSV to CSA without losing inspection readiness.