In pharma and medtech, it is not enough for a system to work — it must be validated. Computer system validation (CSV) is the documented proof that a computerised system consistently does what it is intended to do. This beginner's guide explains the terms, the standards, and the fundamental shift the FDA made in 2025 with Computer Software Assurance.

In brief: Computer system validation (CSV) is the documented, risk-based proof that a GxP system works as intended. With the FDA's final guidance on Computer Software Assurance (CSA) of 24 September 2025, the focus shifts from exhaustive documentation to critical, risk-based testing — automation included.

Figure 1: CSV as risk-based proof — the ALCOA+ principles of data integrity.

What does GxP testing mean?

GxP is the umbrella term for the "Good Practice" frameworks in regulated life sciences — such as Good Manufacturing Practice (GMP) or Good Laboratory Practice (GLP). GxP testing means checking computerised systems used in these environments according to the validation and data-integrity rules that apply there.

The core is data integrity: records must satisfy the ALCOA+ principle — attributable, legible, contemporaneous, original and accurate, plus complete, consistent, enduring and available (MHRA, 2018). How to produce this evidence in practice is covered in Audit Trails in Software Testing.

Key terms you need to know

Before we get to the standards, the key terms in plain form:

• CSV (Computer System Validation): the traditional, documentation-heavy proof that a system works as intended.

• CSA (Computer Software Assurance): the FDA's risk-based successor approach that scales test effort to risk.

• GAMP 5: ISPE's industry framework for risk-based validation.

• 21 CFR Part 11: the FDA regulation on electronic records and signatures.

• EU GMP Annex 11: the European counterpart for computerised systems.

• IQ/OQ/PQ: the three qualification stages — installation, operation and performance.

How CSV works: GAMP 5 and the V-model

Figure 2: The IQ/OQ/PQ qualification model in three steps.

The defining framework is GAMP 5 in its Second Edition, published by ISPE in July 2022 (ISPE, 2022). GAMP 5 follows a risk-based lifecycle: validation effort scales with a system's complexity and its impact on product quality and patient safety.

Software is classified into categories — from infrastructure (category 1) through configured standard products (category 4) to custom-developed applications (category 5). The higher the category, the more rigorous the testing. Importantly, the V-model used in GAMP 5 is explicitly not meant to be linear — the Second Edition supports iterative and agile approaches as well as automation, and itself references the CSA approach.

Qualification follows the IQ/OQ/PQ model:

The CSA shift: less paper, more testing

Figure 3: CSV versus CSA — from documentation focus to risk-based testing.

For a long time CSV was seen as "compliance by the pound": teams invested most of their effort in documentation rather than actual testing — a view widespread in the industry, even if the exact split varies by source. This is precisely where the FDA's Computer Software Assurance comes in.

The CSA guidance "Computer Software Assurance for Production and Quality System Software" was published in final form on 24 September 2025 — so it is no longer at draft stage, as many older sources still claim (Federal Register, 2025). CSA scales test effort to risk: software whose failure would endanger product or patient safety is tested intensively; for low risk, unscripted testing and the use of supplier evidence are explicitly permitted.

Important: CSA reduces the documentation burden, not the responsibility. The risk-based proof of fitness for intended use, data integrity and the validated system state remain mandatory — automation reduces manual effort, not the duty to demonstrate.

Medical devices: IEC 62304 and traceability

For software in medical devices, IEC 62304 applies additionally. It classifies software by potential harm into three safety classes: Class A (no injury possible), Class B (non-serious injury possible) and Class C (death or serious injury possible) (Greenlight Guru, 2024). The higher the class, the stricter the requirements for development, verification and documentation.

The European guidance MDCG 2020-1 requires that the technical performance of medical device software be demonstrated through verification and validation and that clinical evidence be fully traceable (European Commission, 2020). Traceability is therefore the connecting principle here too — the overall regulatory frame is set out in the guide Testing in Regulated Industries.

First steps toward validation-ready testing

Figure 4: Five steps to validation-ready, automatable testing.

If you want to set up CSV pragmatically and in an automatable way, start like this:

• Assess risk: Rate each system by its impact on product quality and patient safety.

• Determine the GAMP category: Derive the required depth of testing from it.

• Think critically: Concentrate effort on high-risk functions, as CSA intends.

• Test automatically and verifiably: Generate audit trails automatically rather than manually.

• Secure traceability: Link each test to a requirement and a risk.

In client projects in regulated environments, automated, qualified tests noticeably reduce validation effort, provided the validated state is documented cleanly. How to bring tests across web, mobile, API and desktop into an end-to-end flow is shown in our overview of test workflows.

Frequently asked questions

What is the difference between CSV and CSA?

Computer System Validation (CSV) is the traditional, documentation-heavy proof that a GxP system works as intended. Computer Software Assurance (CSA), bindingly described since the FDA's final guidance of September 2025, is the risk-based successor that scales effort to risk and puts critical testing above paperwork.

What is GAMP 5?

GAMP 5 is ISPE's framework for the risk-based validation of GxP-relevant computerised systems. The 2022 Second Edition emphasises critical thinking, supports agile approaches and automation, and addresses topics such as AI/ML, cloud and data integrity.

What do IQ, OQ and PQ mean?

IQ (Installation Qualification) evidences correct installation, OQ (Operational Qualification) operation across the specified range, and PQ (Performance Qualification) consistent performance under real conditions. Together they form the classic qualification model in GxP environments.

May you test automatically in GxP environments?

Yes. GAMP 5 (Second Edition) and the CSA approach explicitly support automated testing. What remains mandatory is the risk-based proof of fitness for intended use and data integrity — automation reduces the documentation burden, not the obligation to evidence.

Conclusion

GxP testing demands more than working software: it demands validated, verifiable systems. With GAMP 5, the requirements of 21 CFR Part 11 and Annex 11, and the IQ/OQ/PQ qualification model, the framework is set — and with the final CSA guidance of 2025, the door opens to risk-based, automated testing with less documentation ballast. Those who document the validated state cleanly gain speed without sacrificing compliance. If you want to automate GxP-relevant testing in an audit-ready way, talk to the Autemos team about your specific use case.