GAMP 5Good Automated Manufacturing Practice (v5)

GAMP 5 is the International Society for Pharmaceutical Engineering (ISPE) guide A Risk-Based Approach to Compliant GxP Computerized Systems. The first edition was published in 2008; the second edition landed in July 2022. It is not a regulation — no inspector cites GAMP 5 as a predicate — but it is the de facto industry framework that EMA, MHRA, FDA, PIC/S, WHO and TGA inspectors expect to see referenced when a regulated company explains how it validates computerised systems. Where Annex 11 clause 4 says 'systems should be validated', GAMP 5 explains how.

GAMP 5 sits between three regulatory anchors. Above it: 21 CFR Part 11, EU GMP Annex 11, PIC/S PI 011, MHRA Data Integrity guidance. Below it: ICH Q9 (Quality Risk Management) and ICH Q10 (Pharmaceutical Quality System). It is the operational layer that turns the regulator's 'validate it' into a project plan.

The 2022 second edition modernised GAMP 5 in three substantial ways. First, it introduced critical thinking as a first-class principle — validation effort should be proportionate to risk and value, not template-driven. Second, it embraced iterative and agile methodologies as compatible with GxP validation, replacing the assumption that V-model waterfall is the only acceptable shape. Third, it explicitly addressed SaaS, cloud, IT service management, machine learning and continuous delivery.

The category system was also clarified. The old category 2 (firmware) was retired; categories are now 1 (infrastructure), 3 (non-configured products), 4 (configured products) and 5 (custom applications). The split between configured and custom is now risk-based rather than purely architectural — a heavily customised category 4 implementation may need category 5 treatment in the high-risk areas.

Second edition also formally accepted supplier-leveraged validation: when a competent supplier has performed validation activities, the regulated user can leverage that evidence rather than repeat it, provided the supplier audit and quality agreement support it. This is the basis for modern validated-SaaS delivery.

The category system scales the validation effort to the system's nature. Most real-world systems are a mix — an eBMR platform is typically category 4 (configured COTS), with category 5 elements where the customer has scripted custom logic, and category 1 elements at the infrastructure layer.

Mis-categorising a system is the most common GAMP 5 finding. Treating a configured platform as category 3 misses the configuration risk; treating a custom application as category 4 misses the development-lifecycle risk.

GAMP 5 first edition was built around the V-model: requirements → design → build → test → release, with validation phases (IQ/OQ/PQ) mapped to the right-hand side of the V. The model is durable but it assumes a single delivery, which does not match how modern software is built.

Second edition explicitly accepted iterative development. The principles do not change: every release still needs requirements, design, test evidence, and a traceability matrix. What changes is the cadence. A two-week sprint delivers a tested increment with the same evidence, just smaller in scope. A continuous-delivery pipeline runs the regression test pack on every commit and ships only when it passes.

The regulator does not require a six-month waterfall release. The regulator requires that every change to a GxP system is documented, tested, traced and approved. Modern CI/CD pipelines do this far better than a once-a-year release ever did.

GAMP 5 prescribes a system lifecycle from concept to retirement. The phases are concept, project, operation and retirement. Each phase has its own deliverables and its own quality activities.

Concept

Initial business need, high-level requirements, GxP impact assessment, supplier shortlist.

Project — planning

User Requirements Specification (URS), Validation Master Plan (VMP), supplier assessment (audit, quality agreement, SOC 2/ISO 27001 review), risk assessment (ICH Q9-aligned), validation plan.

Project — specification, configuration and coding

Functional Specification (FS), Design Specification (DS) for category 5, configuration documentation for category 4, code review for category 5, build evidence.

Project — verification (IQ/OQ/PQ)

Installation Qualification — installed per design; Operational Qualification — functions per spec across operating ranges; Performance Qualification — performs intended business process reliably in customer workflows. Traceability matrix links URS to PQ test.

Project — reporting and release

Validation Summary Report, approval by quality unit, release to operational use.

Operation

Change control, periodic review (Annex 11 clause 11), incident management, audit trail review, user training, security, backup and restoration testing.

Retirement

Data migration plan, archive plan, decommissioning record. Retained data must remain accessible for the predicate-rule retention period.

The headline change in GAMP 5 second edition is critical thinking. Validation effort should be proportionate to risk and patient impact, not driven by template completion. A high-risk eBMR step that controls a parametrically released parenteral needs deep PQ evidence; a low-risk reporting dashboard needs little.

ICH Q9(R1) provides the risk-management framework GAMP 5 leans on. The risk assessment identifies what could go wrong, how likely, how severe, how detectable. The validation plan then focuses depth where risk is highest. The Validation Summary Report explains the depth chosen.

The wrong reading of critical thinking is 'do less validation'. The right reading is 'do the right validation'. Inspectors are persuaded by a focused, defensible plan; they are not persuaded by a thousand pages of templated screenshots covering low-risk areas while the high-risk areas were skimmed.

The FDA's 2022 draft guidance on Computer Software Assurance for Production and Quality System Software (CSA) is the regulator's complement to GAMP 5 second edition. CSA explicitly prescribes a risk-based, value-driven approach to validation that prioritises critical thinking and unscripted testing over voluminous scripted-test paperwork.

CSA and GAMP 5 second edition are aligned: scale evidence to risk, leverage supplier validation where appropriate, use unscripted exploratory testing for low-risk paths, focus scripted testing on high-risk paths. Together they signal a regulatory shift away from page-counting toward outcome-focused validation.

A 2026 validation programme that still relies on hundreds of pages of templated test scripts for a configured SaaS eQMS is over-engineering against the modern guidance, not satisfying it.

Second edition formalised what the industry had been doing informally: when a competent SaaS supplier performs validation activities on the released product, the regulated user can leverage that evidence rather than repeat it. The leveraged evidence must be supported by a supplier audit, a quality agreement, and a documented assessment of the supplier's quality system.

In practice, a validated-SaaS delivery looks like this. The supplier provides validated builds — each release ships with a regression-test pack, a release-notes pack that maps to URS items, vendor IQ/OQ on the released version, a Validation Summary Report, and SOC 2 / ISO 27001 evidence. The customer adds the user requirements specific to their workflows, the PQ run for those workflows, the periodic review, and the operational SOPs.

The customer's validation effort shrinks by an order of magnitude. The total evidence pack is no smaller; what changes is who produces which part of it. The inspector still sees the same depth of evidence.

1. Mis-categorising the system — treating a configured platform as category 3 and skipping configuration risk.
2. Templated PQ that covers easy paths and skims the high-risk ones — critical thinking failure.
3. URS that lists every feature the platform supports rather than the requirements specific to the regulated user's process — turns into untestable scope.
4. Traceability matrix exists but does not actually trace — entries point at the wrong test or to deleted tests.
5. Supplier audit pack is older than the deployed version — leveraged evidence does not cover the in-use software.
6. Periodic review skipped because 'nothing has changed' — change control was incomplete, things changed.
7. Change control treats configuration as out of scope — configuration changes affect GxP behaviour and need the same control as code changes.
8. Validation Summary Report glosses over open risks instead of accepting them with documented rationale.
9. Retirement plan written at retirement — no migration evidence, archive cannot be queried.
10. Validation evidence stored only as printed signed paper — when the platform is upgraded the evidence is not searchable.

V5 is delivered as a validated SaaS platform aligned to GAMP 5 second edition. The supplier evidence pack covers the leveraged portion of every customer validation.

• Category alignment — V5 ships as category 4 (configured COTS) with configuration documented per workspace, and explicit category 5 evidence for any custom code paths a customer commissions.
• Validated builds — every release ships with a regression test pack, release notes mapped to URS items, vendor IQ/OQ on the released version, and a Validation Summary Report.
• Traceability matrix — every shipped feature traces to its URS item, its design, its automated test and its release. Customers extend the matrix with their PQ rows.
• Risk-based PQ templates — the V5 PQ pack focuses depth on high-risk paths (e-signature binding, formula approval, batch release, audit-trail integrity) and lighter scripted coverage on low-risk paths.
• Supplier evidence pack — SOC 2 Type II, ISO 27001, supplier audit questionnaire, quality agreement template, security posture documentation. Available to every customer on request.
• Change control built in — configuration changes (formula approvals, document approvals, role changes) all write to the immutable audit trail and require two-component e-signature.
• Continuous-delivery alignment — every commit runs the full regression test pack; releases ship only when green, and the release notes document the URS items touched and the test evidence.
• Retirement support — data exports preserve structured records, audit trails and rendered PDFs in formats that satisfy long-term archive readability.

See below for regulator-grade answers to the questions buyers ask most often about GAMP 5.

GAMP 5 frames the validation lifecycle as a V — left-side specification deliverables (URS → FS → CS/DS) descend to the implementation, and right-side verification deliverables (IQ → OQ → PQ) ascend back up to user acceptance. Every left-side deliverable has a matched right-side verification. Tracing through the V is the mechanism by which an inspector confirms that nothing was specified and not tested, and nothing was tested without a specification to test against.

The Requirements Traceability Matrix (RTM) is the spine that locks the V. Every URS item appears as a row; the columns identify the FS/CS reference, the test reference, the test result and the release decision. Inspectors pull the RTM first, pick three rows at random, and ask to see the full chain. Sites that maintain the RTM as a build artefact (generated from the underlying system) close the audit in minutes; sites that maintain it as a separate spreadsheet typically discover gaps the morning of the inspection.

The Second Edition (2022) formalised what mature programmes had been doing for a decade: validated SaaS is a shared-responsibility model. The supplier owns the platform's validated state and provides leveraged evidence; the customer owns the configuration, the data, the workflows, the user-access model, and the periodic-review evidence. Mis-attributing either side is the most common Second-Edition implementation error.

• Supplier-owned: platform code validation, IQ/OQ against the platform release, infrastructure qualification (Postgres, Cloudflare, the runtime), security testing, supplier-side audit programme, validation release pack per release.
• Customer-owned: URS authorship, configuration-specific validation, user provisioning and access reviews, periodic review, change control on tenant configuration, data-integrity controls (e-signature workflow gates, audit-trail review cadence), back-up/restore test against the tenant data, business-continuity testing.
• Shared: supplier audit (customer or proxy audits supplier annually), quality agreement (signed by supplier QA and customer QA), incident-and-deviation flow (supplier raises platform-level incidents that may impact the customer's validated state), change communication (supplier announces upcoming releases with the validation-impact assessment so the customer can plan their own periodic review).

The two failure modes are over-trust (the customer assumes supplier validation covers configuration — it does not) and over-validation (the customer re-tests platform behaviour the supplier already evidenced — wasteful and not what GAMP 5 expects). Second Edition is explicit that competent supplier evidence is leverageable if the supplier passes the supplier audit; re-testing is acceptable for the configuration layer only.

Second Edition added explicit guidance for machine-learning components inside GxP software, mirroring the parallel FDA CSA and EU AI Act direction. Any system that includes ML — predictive maintenance, exception triage, demand forecasting that feeds the regulated record — must add an AI/ML-specific layer to its validation evidence. The principles are the same; the failure modes are different.

• Intended-use boundary: the URS must name what decision the model informs, the human in the loop, and the consequence of a wrong output. ML inside a regulated execution path that auto-acts on its own output is rarely acceptable; ML as a suggestion to a human reviewer is the standard pattern.
• Data lineage: the training data, the data-version reference, the data-quality evidence, and the data-bias review must be retained for the life of every deployed model version.
• Model versioning: every model version is a configuration item under change control with the training data version, the hyper-parameter set, the validation-set performance metrics, and the deployment signature.
• Drift monitoring: performance metrics tracked in production (PSI for distributional drift, KS-test for input drift, error-rate trending against the validation baseline) with alerting thresholds documented in the URS.
• Retraining change control: any model retraining is a configuration change that re-enters the validation V-model — at minimum focused OQ-config testing, at most full re-qualification depending on the change scope.
• Explainability: the user-facing output must carry a minimum explainability artefact (feature-contribution chart, decision-rule trace) that a reviewer can defend to an inspector.