What Changed — From CSV to CSA
For decades, the pharmaceutical industry validated computerised systems using an approach called Computer System Validation (CSV) — a document-heavy, protocol-driven methodology centred on the V-model and formal IQ/OQ/PQ qualification. In 2022, the FDA published a new guidance document introducing Computer Software Assurance (CSA), a risk-based alternative that emphasises critical thinking over documentation volume.
CSA does not replace CSV. The underlying GAMP 5 framework and the V-model remain valid. What CSA changes is the philosophy of how you apply testing effort — directing it toward activities that genuinely assure software works correctly for its intended use, rather than generating documentation for documentation's sake.
The FDA's CSA guidance explicitly states that the goal is to reduce "unnecessary or redundant testing and documentation" while maintaining assurance that software performs its intended function. The guidance encourages leveraging vendor testing, focusing human effort on scripted testing of critical functions, and using unscripted exploratory testing more deliberately.
The Key Differences in Practice
What Stays the Same
Engineers reading about CSA sometimes conclude it means less validation work overall. That's a misreading. What CSA reduces is low-value documentation — scripted test cases for functions that are self-evidently correct, repeated execution of tests that vendors have already conducted and published results for, and protocols that exist to generate paper rather than to assure function.
What stays the same under CSA: the requirement to validate, the IQ/OQ/PQ structure, the need for a traceability matrix, 21 CFR Part 11 compliance, and the requirement that critical functions are tested with scripted, executed, documented evidence.
CSA in Practice — What Changes for PLC/SCADA Engineers
In a CSA-informed approach to a SCADA validation project, the practical changes are:
- Leverage the platform vendor's test evidence — Siemens TIA Portal, Wonderware, or Ignition have been tested by their vendors. You don't need to re-test that the PID algorithm calculates correctly; you need to test that you configured it correctly for your process
- Risk-score test depth — critical functions (patient safety, product quality, data integrity) get multiple scripted test cases. Non-critical functions (screen colours, report formatting) may get exploratory testing with a documented rationale
- Unscripted testing for low-risk areas — exploratory testing by a qualified engineer, documented as a test session with observations recorded, rather than a scripted protocol with pass/fail verdicts for every step
- Shorter protocols, better documented rationale — a 40-page OQ with tight test cases and clear risk-based justification is more credible than a 200-page OQ where half the test cases verify things the vendor already tested
CSA is an FDA guidance — EU GMP Annex 11 has not been formally updated to incorporate CSA principles (the 2026 revision may address this). In practice, EU-focused pharma companies and their QA teams are often more conservative. If your client's QA team is EU-trained, discuss the approach explicitly before reducing scripted test coverage based on CSA principles alone.
The QLean templates are structured to support both traditional CSV and a CSA-informed approach. The risk assessment template includes a "testing approach" column where scripted, exploratory, or vendor-reliance can be documented per function. The OQ template supports both full scripted execution and documented exploratory test sessions.