Computer System Validation & CSA
Computerised system validation (CSV) is documented evidence that a GxP computerised system does what it is intended to do, and only that, throughout its operational life. Done well it is a risk-based lifecycle discipline focused on patient safety, product quality, and data integrity. Done badly it degenerates into documentation for its own sake — which is exactly what the FDA’s Computer Software Assurance (CSA) direction is meant to correct.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 27 LINKSCSV spans the validation, documentation, and quality-system disciplines: every GxP computerized system below must be proven fit for intended use — with effort scaled to risk, GAMP 5-style — and then held in a validated state for life.
06 · QUALITY MATURITY — COMPUTER SYSTEM VALIDATION & CSA, REACTIVE TO ADAPTIVE
Systems enter GxP use unvalidated or with go-live paperwork only; changes are applied without assessing the validated state.
A validation SOP and GAMP categorization exist, but every system gets the same document set regardless of risk.
Validation rigour scales with risk; requirements trace to tests; periodic review and change control keep systems validated.
Assurance effort follows critical thinking (CSA): supplier evidence is leveraged, and operational data feeds periodic review.
Validation is a lifecycle property: risk drives selection, unscripted testing targets what matters, and systems retire under control.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 4
Derived from the 4 standards SPEQ maps to this subject, across 3 regulatory bodies: FDA, EMA, ISPE.
RECORDS & OBJECTIVE EVIDENCE
- Validation plans and reports with risk-based scope rationale
- Requirements-to-test traceability for GxP functions
- Supplier assessment evidence supporting leveraged testing
- Change records assessing impact on the validated state
- Periodic review records covering access, audit trail, and backup
COMMON INSPECTION FINDINGS
- GxP systems in production use with no validation evidence
- Changes implemented without revalidation impact assessment
- Periodic reviews scheduled by procedure but never performed
- Test evidence with no traceability to requirements
- Spreadsheets driving GxP decisions outside any validation
GAMP 5 and the risk-based lifecycle
ISPE GAMP 5 (Second Edition) is the practitioner framework for validating GxP computerised systems. Its core idea is that effort should be scaled to risk: a system’s validation rigour is driven by its impact on patient safety, product quality, and data integrity, and by its novelty and complexity. A configurable off-the-shelf LIMS is not validated the same way as bespoke code.
GAMP 5 organises work across a lifecycle — concept, project (specify, configure/build, verify), operation, and retirement — and around software categories that set the baseline approach. It also leans on supplier assessment and leverage: where a supplier has robust development and testing, the regulated company can rely on that evidence rather than re-testing everything itself.
Part 11 and Annex 11 — electronic records and signatures
Where a system creates, modifies, maintains, or transmits GxP electronic records, the electronic-records/electronic-signatures controls apply: unique user access, audit trails, operational and authority checks, and — where used — compliant electronic signatures. In the US this is 21 CFR Part 11; in the EU it is EU GMP Annex 11. The two are closely aligned in intent.
These controls are the mechanism by which validation delivers data integrity. Validation proves the record is trustworthy; Part 11 / Annex 11 keep it that way — by ensuring changes are attributable, traceable, and non-repudiable.
Computer Software Assurance (CSA) — the shift in emphasis
The FDA’s CSA direction (final guidance for production and quality-system software, issued September 2025 after a 2022 draft) is a deliberate correction to validation that had become documentation-heavy and testing-light. CSA asks teams to spend their effort on critical thinking and on the features that actually bear on safety and quality — using unscripted and exploratory testing where appropriate, and reserving heavy scripted testing for high-risk functions.
CSA does not lower the bar for high-risk systems; it re-allocates effort. Less time producing screenshots that no one reads, more time analysing what could go wrong and testing that. It is the same risk-based philosophy GAMP 5 already teaches, stated by the regulator as an expectation.
What good looks like in operation
Validation is not finished at go-live. The operational phase — change control, periodic review, backup and restore, security and access management, and eventual data migration or retirement — is where most systems spend their life and where most findings arise. A validated system that is not kept in a validated state is no longer validated.
WORKED EXAMPLE — SPEQ SYNTHESIS
A hypothetical mid-size manufacturer is implementing a configured electronic logbook to replace bound paper logbooks on its packaging lines. The vendor supplies a standard product, the site will configure workflows and user roles, and the records will be used for GMP decisions. The validation lead is asked to scope the effort.
State the intended use in terms of the decisions made on the output
Not "an electronic logbook" but which GMP decisions will rest on these records — line clearance, batch release, deviation triggers. Intended use is what sets risk, and a description written in features rather than decisions produces a scope nobody can defend.
Determine electronic-record applicability record by record
Some records in the system will be GxP and some will not. Deciding system-wide is faster and usually wrong in one of two directions: it either burdens administrative records with signature controls or leaves a GxP record without them.
Assign the software category, and justify it rather than asserting it
A configured product is not a standard one, and treating a configured product as standard is the most common scoping error in this activity. The justification belongs in the plan, because it is the premise every downstream effort decision rests on.
Assess the supplier before deciding how much of their work to leverage
Leveraging supplier testing is legitimate and is the point of a risk-based approach. Leveraging it without an assessment of how the supplier develops and tests is an assumption, and it is the assumption an inspector will ask to see evidence for.
Scale the testing to risk, and write down what you are NOT testing
The scope decision is defined as much by its exclusions as its inclusions. A plan that lists what will be tested and stays silent on the rest reads, later, as an omission rather than as a decision.
Establish traceability at the start, and define retirement while you are there
Requirements to tests, maintained as the configuration changes. Retrofitting traceability after design is where it breaks. Periodic review and retirement belong in the plan now, because the data in this system will outlive the project that installed it.
A validation plan stating intended use, record-level applicability, a justified category, a supplier assessment, a risk-scaled test scope with its exclusions written down, and a traceability and lifecycle approach. The system is not thereby validated — execution against this plan is what produces that, and the conclusion is the organisation’s to draw.
WHAT WOULD CHANGE THIS
- If the product turns out to be custom-developed for this site rather than configured, the category changes and with it the whole effort model — the supplier assessment becomes a development-lifecycle review.
- If the logbook records are not used for GMP decisions at all, most of this scope falls away, and saying so is a legitimate outcome of step one rather than a failure to be thorough.
- If the system replaces a record that must be retained for decades, retention and retrievability become the dominant risk, ahead of functional testing.
FREQUENTLY ASKED
What is the difference between CSV and CSA?
CSV (computer system validation) is the overall discipline of proving a GxP system is fit for use. CSA (computer software assurance) is the FDA’s risk-based emphasis within it — spend effort on critical thinking and testing that matters for safety and quality, rather than on exhaustive documentation. CSA is an approach to CSV, not a replacement for it.
Is GAMP 5 mandatory?
No. GAMP 5 is an ISPE good-practice guide, not a regulation. But it is the de facto industry framework, and regulators expect a risk-based validation approach consistent with its principles. The binding requirements are the predicate rules plus 21 CFR Part 11 / EU GMP Annex 11.
Do all computerised systems need validating?
Only GxP systems — those whose failure could affect patient safety, product quality, or data integrity — need validation, and the rigour scales with that risk. GAMP 5’s software categories and risk assessment are how you decide how much validation each system needs.