GAMP 5 and Computerised System Validation: What QMS Teams Need

Computerised system validation (CSV) is documented evidence that a computerised system does what it is meant to do, and keeps doing it, throughout its use in a regulated trial. GAMP 5, the ISPE guide A Risk-Based Approach to Compliant GxP Computerized Systems, is the framework most quality teams use to plan that evidence. For a clinical research quality management system, GAMP 5 answers one operational question: how much validation effort a given system needs, based on the risk it carries to participant safety, data integrity and the trial result.

This guide explains what CSV means in clinical research, what GAMP 5 actually says, how its software categories set the level of rigour, the validation lifecycle a QMS team runs, and the deliverables an inspector expects to see. It is written for QA leads and research IT teams who own system validation but do not spend every day inside a validation standard.

Key Takeaways

• Validation is proportionate to risk. GAMP 5 sets validation effort by what a system can affect, not by a fixed checklist applied to every tool.
• Software category drives the approach. GAMP 5 uses categories 1, 3, 4 and 5. Category 2 was retired in the second edition.
• Validation is a lifecycle, not a one-off project. A system stays validated through change control, periodic review and audit trail review, not only at go-live.
• Supplier work can count as evidence. GAMP 5 lets a research team use a supplier’s testing as evidence once the supplier is assessed, which reduces duplicated effort.
• The evidence is what gets inspected. User requirements, risk assessments, IQ/OQ/PQ records, traceability and the validation summary are the artefacts an MHRA inspector reviews.

What is computerised system validation in clinical research?

Computerised system validation is the documented process of confirming that a system meets its defined requirements and consistently performs as intended. In clinical research this covers any system that creates, holds or manages regulated records: a CTMS, an eTMF, an electronic site file, a randomisation system, a pharmacy inventory tool, or the QMS itself.

The obligation is not optional. ICH-GCP E6(R3) expects sponsors and institutions to ensure that computerised systems used in a trial are fit for purpose, validated, and kept under control across the study lifecycle. Data held in those systems must meet ALCOA+ principles: attributable, legible, contemporaneous, original, accurate, and then complete, consistent, enduring and available. A system that produces records an inspector cannot trust undermines the trial result regardless of how the science was run.

Validation proves the system is trustworthy. Data integrity proves the records it holds are trustworthy. An inspection tests both.

What does GAMP 5 actually say?

GAMP 5 is guidance, not law. It gives regulated organisations a structured, risk-based method to reach and evidence a validated state. The second edition, published by ISPE in 2022, updated the guide for cloud services, agile software development, automated tooling and the greater role of external suppliers. Regulators including the MHRA and FDA recognise GAMP 5 as good practice, which is why a research QMS built around it stands up well at inspection.

Three ideas carry the whole framework:

• Risk-based effort. Validation scales with impact on patient safety, product quality and data integrity. A read-only reporting tool and a system that assigns randomisation do not warrant the same rigour.
• Critical thinking. The second edition asks teams to apply product and process knowledge to decide what to test, rather than run a fixed script for every system. The outcome is a system fit for use, evidenced by targeted testing.
• Using supplier evidence. A team can use a supplier’s development and testing as part of its evidence once it has assessed that supplier’s quality system. This removes duplicated testing while keeping accountability with the regulated organisation.

Accountability is the line that does not move. A sponsor or institution can draw on supplier work and delegate tasks, but it retains responsibility for the validated state of every system it relies on. Inspection readiness depends on being able to show that responsibility was met with evidence.

How do the GAMP 5 software categories work?

GAMP 5 classifies software into categories that set the expected validation approach. The category reflects how much a system is built or changed for its use, because bespoke configuration and custom code carry more ways to fail than standard, unmodified software. The second edition uses four active categories. Category 2, which covered firmware in earlier versions, was removed.

Most clinical research systems sit in category 4. A CTMS, an eTMF or an electronic quality management system arrives as a commercial product, then gets configured to study workflows, user roles and approval routes. That configuration is where risk enters, so it is where testing concentrates. Categorising a system correctly is the first control, because it prevents both under-validation of a high-risk tool and wasted effort on a low-risk one.

What does the validation lifecycle involve?

Validation runs as a lifecycle from requirements to retirement. Each stage produces a record, and the records connect so that every requirement traces to the test that proves it. The core stages a QMS team runs are set out below, each described as the activity and the outcome it delivers.

• User requirements (URS). The team states what the system must do in its context, which gives every later test something specific to prove.
• Risk assessment. The team scores each function for impact and likelihood of failure, which focuses testing on the functions that affect safety and data integrity.
• Supplier assessment. The team evaluates the vendor’s quality system, which lets it use supplier testing and reduce duplicated effort.
• Installation qualification (IQ). The team confirms the system is installed and configured as specified, which establishes a known, controlled baseline.
• Operational qualification (OQ). The team tests that functions behave correctly against requirements, which demonstrates the system works as designed.
• Performance qualification (PQ). The team confirms the system performs in the real process with real users, which proves it is fit for actual use.
• Traceability and validation summary. The team maps requirements to tests and results, which gives an inspector a single line of sight from need to evidence.
• Periodic review. The team re-checks the validated state at set intervals, which confirms the system still meets requirements after changes and upgrades.

Also Read: TMF Completeness Tracking: How RAG Scoring Prevents Inspection Findings.

Reactive validation versus a controlled lifecycle

The central difference between teams that pass an inspection on system validation and teams that get a finding is not the size of the validation binder. It is whether validation is treated as a project that ended at go-live or as a state maintained through control. The contrast is set out below.

Where does system validation fail in practice?

Validation rarely fails at go-live. It fails in the months after, when a system changes and the evidence does not keep up. A worked example shows the pattern.

Example: a research team runs a configured eTMF, a GAMP category 4 system. Eight months into a study, the vendor releases an upgrade that changes how document metadata is indexed. The upgrade is applied on a Friday to fix a separate issue. The change is real, it touches a function that affects record retrieval, and no risk assessment, no re-test and no change-control record is created. The system still looks fine day to day. At inspection the following year, the inspector asks for evidence that the metadata change was assessed and tested. There is none. The finding is not that the upgrade was wrong. The finding is that a change to a validated system went live with no evidence that its validated state was maintained.

The failure is a process condition, not an individual error. The person applied a sensible fix. The system had no control that forced a change to pass through assessment before release. That control is what a validation lifecycle provides, and it is why change control and CAPA management sit alongside validation in a functioning QMS. A persistent gap in validation evidence is a candidate for a CAPA, not just a note in a file.

How do GAMP 5, Annex 11 and 21 CFR Part 11 connect?

GAMP 5 is the method. The regulations are the requirements it helps a team meet. Three sit behind most clinical research systems, and they reinforce each other rather than compete.

• EU GMP Annex 11 sets expectations for computerised systems in a GxP context, including validation, audit trails, access control and supplier oversight. A significant revision is in progress, expanding the guidance and adding cybersecurity as a core expectation.
• FDA 21 CFR Part 11 governs electronic records and electronic signatures. It requires that signatures are attributable and non-repudiable and that systems keep a secure, time-stamped audit trail.
• MHRA GxP data integrity guidance sets the expectation that records meet ALCOA+ and that audit trails are not only enabled but reviewed on a risk basis. Read the MHRA GxP data integrity guidance for the detail.

GAMP 5 gives a team the structure to satisfy all three at once. A category-appropriate validation, a maintained audit trail, controlled access and evidenced change control cover the common ground these regulations share. The ISPE GAMP 5 second edition is the primary source for the method.

What does a research QMS have to evidence?

An inspector does not audit the software. The inspector audits the evidence that the software was validated and stayed validated. A QMS team should be able to produce the following for each regulated system, on request, without a scramble.

• A system inventory that records each system, its GAMP category and its owner.
• User requirements and the risk assessment that prioritised testing.
• A supplier assessment where supplier testing was used as evidence.
• IQ, OQ and PQ records with results and any deviations resolved.
• A traceability matrix linking requirements to tests to evidence.
• A validation summary report that states the validated state.
• Change control records for every change made after go-live.
• Periodic review records and audit trail review records.

These artefacts overlap with the wider quality record. A validation summary references SOPs, a change record can trigger a CAPA, and a periodic review feeds inspection readiness. A connected quality management system holds them as one linked set rather than eight separate folders. For teams weighing whether to build validation tooling in-house, the validation burden of a custom build is itself a category 5 problem, with the heaviest evidence load of all.

Also Read: CTMS vs QMS for Clinical Trial Data Management.

What are the risks of skipping structured validation?

• Inspection findings. Missing or out-of-date validation evidence is a recurring theme in MHRA GCP inspection findings, and data integrity findings can be graded critical.
• Untrustworthy data. A system that was never validated for its configured use casts doubt on every record it produced, which can affect the trial result.
• Rework under pressure. Validation reconstructed retrospectively costs more, takes longer, and carries less weight than evidence created as the work was done.
• Uncontrolled change. Upgrades and configuration changes that go live without assessment accumulate silent risk until an inspection surfaces it.

How AQ QMS supports computerised system validation

The AQ quality management system gives a research team the structure to keep systems in a validated state, connected to the rest of the quality record. It holds a system inventory with categories and owners, manages SOPs and change control with version history, and links a change to the review, the CAPA and the training it triggers. Audit trails are captured across the connected modules, so an audit trail review has a single place to run rather than several exports to reconcile. Because AQ connects the QMS with the CTMS, eTMF, site files and CAPA, the validation record and the operational record stay in step.

AQ is a control structure, not the validation itself. The system does not decide a GAMP category, write a risk assessment, or run IQ/OQ/PQ testing. Those are the QMS team’s judgements and remain their responsibility. What AQ removes is the reconciliation cost: the effort of proving, across disconnected tools, that every system is validated, every change was controlled, and every record is current. AQ is aligned with G-Cloud, DSPT and Cyber Essentials standards, and supports the evidence a team needs to be ready for an MHRA inspection rather than replacing the team’s own quality judgement.

See how AQ keeps computerised system validation connected to the rest of your quality record. Book a 30-minute product tour.