How to Validate a Computerized System
Take a GxP computerized system from requirements to a documented validated state.
What a how-to is not
A how-to is SPEQ’s practitioner method, not a procedure. It does not replace your own SOP, it is not a validated approach, and the judgement calls in it belong to your quality unit.
Computerized system validation (CSV) proves a GxP system does what it is intended to do, reliably and securely, and keeps proving it. The modern approach is risk-based (GAMP 5) and critical-thinking-led (CSA): scale the effort to the system’s risk and category, and leverage what the vendor already tested. This is the lifecycle that satisfies both an inspector and a least-burdensome mindset.
- 1
Define intended use and requirements
Write user and functional requirements that state what the system must do in your GxP process. Requirements are the spine of validation — every test traces back to one, and you cannot validate against a use you never defined.
- 2
Assess risk and categorise the software
Classify the system by GAMP category (3 infrastructure/COTS, 4 configured, 5 custom) and assess patient/product/data risk. This decides how much validation effort each function needs — high-risk, custom functions get rigour; low-risk, vendor-tested functions get leverage.
- 3
Assess the supplier and leverage their evidence
For configured or COTS systems, a supplier assessment lets you rely on the vendor’s development and testing rather than re-testing it. This is where critical thinking (CSA) removes duplicative effort.
- 4
Plan and specify
Produce a validation plan, and the configuration/design specifications the system will be tested against. The plan defines scope, approach, roles, and acceptance — it is the contract for what "validated" means here.
- 5
Test to risk (IQ/OQ/PQ, scripted or unscripted)
Qualify installation, verify operation across the range, and confirm performance in intended use. Use scripted testing where risk is high and unscripted/exploratory testing where risk is low — record the assurance rationale either way.
- 6
Trace requirements to evidence
Maintain a traceability matrix linking each requirement to its test and result. Traceability is what proves coverage — an untraced requirement is an untested one.
- 7
Report, release, and maintain the validated state
Summarise results in a validation report, release the system, then keep it validated through change control, periodic review, and audit-trail review. Validation is a lifecycle, not a one-time event.
- !Re-testing vendor-tested functionality instead of leveraging a supplier assessment — effort spent where it buys no assurance.
- !Testing everything to the same depth regardless of risk, so critical functions get the same scrutiny as trivial ones.
- !Validating once and never maintaining the state — no change control, no periodic review, no audit-trail review.
- !Requirements too vague to test against, so "pass" means nothing.
How to Validate a Computerized System: frequently asked questions
Common questions on validate a computerized system.
What is the difference between GAMP 5 and CSA?
GAMP 5 is the risk-based framework for validating computerized systems across the pharma lifecycle; CSA is the FDA’s critical-thinking, least-burdensome approach for device production/quality-system software. GAMP 5’s second edition already incorporates CSA’s mindset, so modern CSV uses both together.
Do I have to script every test?
No. Risk-based approaches encourage scripted testing where risk is high and unscripted or exploratory testing where risk is low. What matters is that you record the assurance rationale and the evidence that the function works for its intended use.
How does Part 11 fit into CSV?
Part 11 governs the electronic records and signatures the system produces; CSV assures the system that produces them. You validate the system and separately ensure Part 11 controls — audit trails, access control, e-signatures — are in place and effective.
When must a validated system be re-validated?
When a change (to the software, configuration, or its use) could affect its validated state. Change control triggers a risk-based assessment of whether re-testing is needed; periodic review catches drift between changes.