Insights
CSA and CSV: what inspectors actually expect
Computer Software Assurance is not a new regulation; it is the risk-based approach GAMP 5 second edition already describes. What changes in testing and documentation, and what does not.
The problem
Many validation programs still run the same protocol depth on every system: full IQ/OQ/PQ scripts, screenshots of every step, for a document management tool and a batch release system alike. The team runs out of hours before it runs out of systems, and the paper proves effort rather than assurance.
The risk
EU Annex 11 (2011) §1 requires decisions on the extent of validation to be based on a justified and documented risk assessment. §4.1 requires manufacturers to justify their standards, protocols, acceptance criteria and records on that basis. A one-size protocol set is hard to justify in either direction: over-scoped on a low-risk system it wastes money, under-scoped on a high-risk one it invites an observation.
What CSA changes, and what it does not
FDA's Computer Software Assurance approach and GAMP 5 second edition (2022) point the same way. The GAMP text is the one most European inspectors and Israeli QA teams already hold, so this article anchors there.
Critical thinking over checklists. GAMP 5's key concepts put science-based quality risk management at the center: effort is focused on the critical aspects of a system in a controlled and justified way, and software categorization is explicitly not a checklist for validation (Chapter 2 §2.1.4; Appendix M4 §12.2).
Scaled life-cycle activities. Activities scale with the system's impact on patient safety, product quality and data integrity, with its complexity and novelty, and with the outcome of supplier assessment (Chapter 2 §2.1.3).
Unscripted testing is legitimate. Appendix D5 lists acceptable assurance approaches including ad-hoc, error-guessing, exploratory and "day in the life" testing with lighter documentation, and states that unscripted does not mean undocumented (§25.5.2, §25.5.3). Scripted testing remains appropriate where a failure could reach the patient or the batch record.
Leverage the supplier. Regulated companies should maximize supplier involvement and use supplier knowledge and documentation, subject to a satisfactory supplier assessment; the more effective the supplier's own testing, the less the regulated company needs to repeat (Chapter 2 §2.1.5; Appendix D5 §25.8.1). Annex 11 §3.3 says the same: review the supplier's documentation to check that user requirements are fulfilled.
Categories are a continuum. Category 1 infrastructure, 3 standard, 4 configured, 5 custom; categories 3 to 5 have no absolute boundaries (Appendix M4 §12.3). A configured SaaS QMS is not a custom build and should not be tested like one.
What does not change: the need for a documented risk assessment, defined user requirements based on GMP impact (Annex 11 §4.4), traceability from requirement to evidence, and a summary that states whether the system is fit for intended use.
What this means for an Israeli QA team
Israeli sites are inspected by the Israel Ministry of Health, by FDA for US supply, and by EMA member-state authorities for EU supply. All three accept risk-based validation; none accepts an undocumented one. The practical move is a validation master plan that assigns each system a risk tier and, per tier, a defined assurance approach: which functions get scripted tests, which get unscripted testing with a record, and which rely on supplier evidence. That single document turns "we do CSA" into something an inspector can read.
Want this applied to your systems?
Book a discovery call. We will map where manual review is costing you the most, and whether CSV/CSA, AI governance, or an AI tool assessment is the right place to start.