The Software Validation Lifecycle Explained

What the validation lifecycle means

Computer system validation (CSV) is a life-cycle discipline under GMP — not a single protocol signed at go-live. The software validation lifecycle spans planning, requirements, design, build, installation verification, operational testing, intended-use confirmation, maintenance, and controlled change.

FDA's General Principles of Software Validation (GPSV, Document 938) describes validation as establishing documented evidence that software conforms to user needs and intended uses. GXPLearn's public glossary defines CSV as demonstrating fitness for intended use through documented lifecycle activity — the same vocabulary used in Modules 09 and 10.

This page explains the full lifecycle hub. For CSV discipline definition see /what-is-csv; for IQ/OQ/PQ qualification layers see /iq-oq-pq-explained.

FDA GPSV grounding

GPSV applies to software used in medical device production, quality systems, and related regulated automation. Section 2.4 notes that software changes after initial release are a leading cause of validation failures — making lifecycle maintenance as important as initial qualification.

Section 5.1 lists typical software life cycle activities: quality planning, requirements, design, construction, testing, installation, operation, maintenance, and retirement. Verification and validation tasks occur throughout — not only at the end.

Section 6.2 emphasises that validation cannot succeed without defined user requirements documenting intended use and the extent of dependence on the automated system. These GPSV anchors underpin how CSV teams structure V-model artefacts and evidence.

Requirements and specifications

GPSV §3.1.1 and §5.2.2 require clear, testable software requirements. A specification states requirements that can be checked — user requirements, functional requirements, design specifications, and test specifications are design outputs requiring verification.

GPSV §6.2 defines user requirements as documenting intended use and the extent to which the manufacturer depends on the software for a quality product. Requirements should cover inputs, outputs, functions, performance, interfaces, safety-related features, and objective acceptance criteria.

In GXPLearn Module 10, the V-model left side starts at user requirements — e.g. BR-201 temperature hold or URS-14/15 interlock intent in Module 09. Vague requirements that cannot be tested undermine the entire lifecycle chain.

Verification vs validation

GPSV §3.1.2 distinguishes verification (building the product right) from validation (building the right product). Verification confirms outputs meet specifications; validation confirms the system meets user needs and intended use.

Module 10 trains this distinction through the V-model: functional and design specifications on the left map to IQ, OQ, and PQ evidence on the right. Quiz guidance in GXPLearn notes the V-model's primary purpose is tracing every user requirement to test evidence.

Conflating verification with validation is a common gap — passing installation checks does not alone prove operational fitness for every intended-use scenario.

Design review

GPSV §3.5 recommends formal design reviews — especially before committing major resources to a design solution. FDA suggests reviews at the end of each life cycle activity, with particular importance at the end of requirements before design proceeds.

Design reviews ask whether tasks, outputs, and products comply with requirements and whether they satisfy standards and intended use. Problems found before build are cheaper to fix than defects found during OQ or in production.

GXPLearn's V-model training treats design/configuration specification as the bridge between intended behaviour and testable evidence — configuration audit trails and revision control are part of defensible design review outcomes.

Validation lifecycle phases

Execution, IQ/OQ/PQ, and user site testing

The right side of the V-model produces executed evidence: installation checks, operational qualification, and performance confirmation. GPSV §3.1.3 discusses IQ/OQ/PQ terminology for user site qualification; see /iq-oq-pq-explained for detailed qualification guidance.

GPSV §5.2.6 states user site testing is essential — testing outside the developer's controlled environment with actual hardware and software configuration, through actual or simulated intended use.

Module 09 practises OQ execution with deviation handling when OQ-INT-001 Step 2 fails. Module 10 links requirements through design into test evidence. Together they represent the execution phase of the lifecycle, not the whole lifecycle.

How much evidence is enough?

GPSV §6.1 states validation effort should be commensurate with risk posed by the automated operation — considering complexity and dependence on the process. Documented requirements and risk analysis define the scope of evidence needed.

GPSV §4.8 Validation Coverage requires activities commensurate with software complexity and safety risk — not firm size or resource constraints. Lower-risk functions may need baseline activities; higher risk adds depth.

GXPLearn quiz content on the Validation Digital Twin uses ALCOA+ as a lens for whether records would survive scrutiny — evidence quality matters as much as volume. CSA thinking (Module 11) further proportiones depth within the lifecycle structure.

Change control and revalidation

GPSV §4.7 requires re-establishing validation status after any software change — even small changes may have global system impact. Conduct validation analysis for the change and its effect on the entire system, then appropriate regression testing.

GPSV §5.2.7 addresses maintenance and software changes. The public glossary defines change control as formal assessment of GxP impact with traceable approval before implementation — a core maintained validated state activity.

Module 24's Validation Digital Twin workspace practises change-to-closure: stage changes, assess impact, execute tests, review evidence, close deviations, and generate a validation summary with scored feedback.

Ten GPSV validation principles

FDA GPSV Section 4 summarises principles that should guide every validation programme. The following digest maps each principle to practical CSV lifecycle thinking.

1. Requirements (§4.1) — A documented software requirements specification is the baseline for validation and verification; validation cannot complete without it.
2. Defect prevention (§4.2) — Focus on preventing defects during development; testing alone cannot establish fitness for intended use.
3. Time and effort (§4.3) — Build a case for confidence with a mixture of methods appropriate to risk, size, and environment.
4. Software life cycle (§4.4) — Validation spans birth to retirement; activities iterate as the project evolves.
5. Plans (§4.5) — A validation plan defines what will be accomplished — scope, approach, resources, and schedules.
6. Procedures (§4.6) — Procedures define how validation activities are executed with repeatable sequences.
7. Validation after a change (§4.7) — Any change re-establishes validation status; analyse system-wide impact and regression scope.
8. Validation coverage (§4.8) — Activities must match complexity and safety risk, not documentation habit.
9. Independence of review (§4.9) — Independent evaluation improves objectivity, especially for higher-risk applications.
10. Flexibility and responsibility (§4.10) — Manufacturers choose how to apply principles but retain ultimate responsibility for demonstrated validation.

Practise the lifecycle in GXPLearn

Module 09 (CSV Validation) — execute OQ-INT-001, document deviations, and close with targeted re-test evidence. Module 10 (V-Model) — trace requirements through design to IQ, OQ, and PQ evidence layers.

Module 20 (Validation Digital Twin) — launchpad for the end-to-end validation chain. Module 24 capstone workspace — nine-chapter guided scenario with role switching, CSV/CSA lenses, and audit-style scoring from change through validation summary.

Modules 11–12 add CSA assurance and CSV vs CSA comparison. Explore /csv-csa-training for the guided path, or start free foundation Modules 01–03 for system and batch context.