CSV is a lifecycle, not a document Computer System Validation (CSV) in pharmaceutical manufacturing is the documented process of ensuring that a computerised system consistently performs its intended functions in compliance with GxP requirements. It is not a single test, a report, or a certification. It is a lifecycle that begins at system requirements, continues through design and testing, and extends through the system’s operational life until decommissioning. The lifecycle produces a validation package — a traceable set of documents linking user requirements to design specifications, design specifications to test protocols, and test protocols to execution evidence. When an inspector reviews a validated system, they follow this traceability chain to verify that every stated requirement has a corresponding test and every test has documented evidence of execution and acceptance. For teams now deploying machine-learning components into GxP-regulated pipelines, the question is rarely whether to validate — it is which validation route applies. Since the FDA’s 2022 Computer Software Assurance (CSA) guidance, full CSV is no longer the only defensible answer. Choosing between the two is itself an engineering decision with downstream cost and timeline consequences. The CSV lifecycle in practice Phase Deliverables Purpose Planning Validation Plan, System Description, Risk Assessment Define scope, approach, acceptance criteria Specification URS, FS, DS, CS Document what the system must do and how Verification IQ, OQ, PQ protocols and execution records Prove the system works as specified Release Validation Summary Report, SOPs, training records Authorize the system for production use Operation Change control, periodic reviews, incident management Maintain the validated state Retirement Decommissioning plan, data migration, archive Remove the system while preserving data URS = User Requirement Specification; FS = Functional Specification; DS = Design Specification; CS = Configuration Specification. In our experience, a common failure mode is treating CSV as a one-time exercise completed at deployment. The most consequential validation activities tend to occur during the operational phase — when system changes, infrastructure updates, and data migrations create opportunities for the validated state to degrade. Every change to a validated system requires a documented impact assessment to determine whether revalidation is needed. This is an observed pattern across our pharma engagements rather than an externally benchmarked rate, but it reliably surfaces when teams underweight post-deployment governance. When does CSA apply, and when must you still do full CSV? The FDA’s Computer Software Assurance (CSA) guidance, finalised in 2022, offers a risk-based alternative to traditional CSV. CSA does not eliminate validation. It directs validation effort toward the activities that matter most — testing and assurance of the highest-risk functionality — while reducing documentation burden for lower-risk components. Under CSA, the determining factor is whether a software function has direct impact on product quality or patient safety. Functions with direct impact (automated batch release decisions, process control setpoints, quality data calculations, electronic records subject to 21 CFR Part 11 signatures) require thorough assurance activities including scripted testing. Functions with indirect or no impact on product quality may be assured through unscripted testing, vendor documentation review, or operational checks. For engineering teams, CSA changes the validation conversation from “document everything equally” to “identify what matters and test it thoroughly.” A practical decision rubric: System characteristic CSA-eligible Full CSV expected Direct GxP impact on product release or patient safety Possible, but scripted testing required for high-risk functions Default for high-risk, direct-impact systems Indirect GxP impact (training tools, document management, monitoring dashboards) Yes — unscripted testing, vendor evidence usable Rarely justified Vendor-supplied, configured-not-customised software CSA preferred — leverage vendor IQ/OQ Only for heavy custom configuration Bespoke, custom-developed software with novel logic Possible with risk justification Default — full lifecycle traceability AI/ML inference where outputs feed regulated decisions Hybrid: CSA framing, but model lifecycle still needs scripted assurance Often required for batch-impacting models The decision is not binary. Most production pharma stacks contain a mix: a configured LIMS validated under CSA, a custom batch release engine validated under full CSV, an ML drift monitor validated under a hybrid approach. The deliverable that captures this per-system is a GxP Regulatory Scope Analysis, which maps each system in scope to its correct validation route before validation effort begins. We treat the CSA-versus-full-CSV decision as a risk-based choice that depends on system classification and quality impact, made before validation planning rather than during execution. What full CSV actually requires when it is the correct approach When a system’s risk profile pushes it into full CSV, the deliverable set expands considerably. A complete project produces documentation that collectively demonstrates the system is fit for its intended use and compliant with regulatory requirements. The Validation Plan defines the validation scope, strategy, roles, responsibilities, and acceptance criteria. It is approved before validation activities begin and serves as the governing document for the project. The User Requirements Specification (URS) captures what the system must do from the user’s perspective. Functional Specifications (FS) describe how the system will meet the requirements. Design Specifications (DS) describe the technical implementation. These three documents create a traceability chain from user needs through design. Installation Qualification (IQ) verifies that the system is installed correctly per the design specifications. Operational Qualification (OQ) verifies that the system functions correctly under anticipated operating conditions. Performance Qualification (PQ) verifies that the system performs consistently under real-world conditions with actual data. The Traceability Matrix links every user requirement to its design specification, test protocol, and test result — providing a single-document view of validation completeness. If any requirement lacks a corresponding test, the matrix reveals the gap. Across our engagements, a medium-complexity system (50–100 requirements) typically absorbs 4–8 weeks of validation effort alongside development; this is an observed planning range from our project history, not a benchmarked industry rate. Documentation requirements for AI systems in a cGMP environment AI/ML systems introduce two challenges that neither traditional CSV nor basic CSA fully address on their own: Non-deterministic outputs. ML models produce different results as training data changes. Validation cannot assume fixed behaviour. Continuous learning. Models that retrain on production data change their validated state without a formal change control trigger. The documentation expectations for an AI system in cGMP scope therefore extend beyond the classical CSV deliverable set: Data lineage records. Training, validation, and test datasets must be versioned, with provenance traceable to source systems and any preprocessing steps documented. PyTorch, scikit-learn, and ONNX-based pipelines all need this regardless of framework. Model card and intended-use statement. A controlled document describing the model’s purpose, training data, performance characteristics, known limitations, and the regulated decisions it informs. Acceptance criteria with monitoring thresholds. Accuracy, precision, recall, calibration, and drift metrics with predetermined thresholds. These become the operational definition of the validated state. Change-control protocol for retraining. Whether retraining is automated or manual, the SOP must specify when a retraining event triggers revalidation versus when it falls within the pre-approved operating envelope. Continuous validation evidence. Logged inference performance against the acceptance criteria, with automated alerts and a documented response protocol when thresholds are breached. This is consistent with CSA’s risk-based philosophy while addressing the specific characteristics of learning systems. The emerging practice is to treat the model lifecycle (data → training → deployment → retraining → retirement) as a sub-lifecycle within the broader CSV or CSA frame, with its own change control and its own assurance evidence — not as a black box bolted onto a classically validated system. We pay close attention to this boundary in our pharma engagements because it is where most validation packages either earn or lose inspector confidence: an AI system documented like deterministic software typically fails to answer the question an inspector actually asks, which is “how do you know the model still performs as validated, today, on this batch?” FAQ What is the difference between FDA’s Computer Software Assurance (CSA) and traditional CSV? CSA is a risk-based assurance framework finalised by the FDA in 2022 that directs effort toward high-risk functionality and reduces documentation burden for lower-risk components. Traditional CSV applies a uniform lifecycle and documentation set across all system functions, regardless of risk. Both produce defensible evidence of fitness for use; CSA reaches that evidence with less uniform overhead. When does CSA apply to AI/ML software in a GxP environment, and when must I still do full CSV? CSA applies when the AI function has indirect GxP impact or where a vendor-supplied component carries sufficient prior assurance. Full CSV is expected when the AI system directly drives batch release, process control, or other decisions with direct product-quality or patient-safety impact. Many AI deployments in pharma are hybrids: CSA framing for the surrounding system, with scripted assurance for the model itself. How does CSA’s risk-based approach reduce validation effort without losing GxP defensibility? CSA reduces effort by replacing scripted testing with unscripted testing, vendor documentation, or operational checks where risk is low. Defensibility is preserved because the highest-risk functions still receive thorough scripted assurance, and the risk-based decisions themselves are documented and justified — an inspector can see why each function received the assurance level it did. Which parts of an AI system’s lifecycle (training, deployment, retraining) does CSA actually cover? CSA covers the assurance activities applied at each lifecycle stage, but the stages themselves remain. Training data versioning, model deployment qualification, and retraining change control all need documented evidence. CSA changes how much scripted testing is required at each stage based on risk, not whether the stage exists. How do inspectors evaluate CSA-based assurance evidence for AI software? Inspectors look for a documented risk rationale linking each assurance activity to the function’s GxP impact, evidence that high-risk functions received scripted assurance, and monitoring evidence showing the validated state is maintained in operation. For AI, they specifically expect ongoing performance evidence against predetermined acceptance criteria. What does a CSA-driven validation deliverable set look like compared to a CSV-driven one? A CSA-driven set keeps the Validation Plan, URS, Risk Assessment, Traceability Matrix, and Summary Report, but adjusts the testing layer: scripted IQ/OQ/PQ only for high-risk functions, with unscripted testing or vendor evidence elsewhere. A CSV-driven set applies full IQ/OQ/PQ uniformly. The CSA set is typically 30–50% smaller in document volume on engagements we have run — an observed pattern across our projects rather than a published industry figure.
