GAMP 5Good Automated Manufacturing Practice (v5)
GAMP 5 Second Edition — ISPE's industry framework for validating GxP computerised systems. What the four (was five) software categories mean, how the V-model maps to agile and SaaS, and how to use GAMP 5 to satisfy Annex 11 clause 4 and 21 CFR Part 11 §11.10(a) without burying the project in paper.
01What GAMP 5 actually is
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.
02What changed in GAMP 5 Second Edition
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.
03The four software categories
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.
| Category | Description | Validation focus | Examples |
|---|---|---|---|
| 1 | Infrastructure software — operating systems, database engines, network stack, virtualisation. | Vendor-supplied installation evidence; record of versions; verify under risk-based review. | Linux, Postgres, Kubernetes. |
| 3 | Non-configured products — used as supplied without modification. | Vendor IQ/OQ leveraged; PQ in customer workflows. | Standard instruments, simple desktop tools. |
| 4 | Configured products — COTS configured to the customer's process via parameters, business rules, templates. | Risk-based PQ on configuration; user requirements traced to configuration; change control on configuration parameters. | MES, LIMS, eBMR, ERP. |
| 5 | Custom applications — developed specifically for the customer. | Full lifecycle: URS, FS, DS, IQ/OQ/PQ, code review, unit test, integration test, traceability matrix. | Bespoke integrations, custom data-acquisition apps. |
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.
04The V-model, agile and continuous delivery
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.
05The GAMP 5 lifecycle
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.
06Critical thinking and risk-based validation
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.
07GAMP 5, CSA and the FDA's modern direction
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.
08Supplier-leveraged validation and SaaS
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.
09Ten ways GAMP 5 projects fail
- Mis-categorising the system — treating a configured platform as category 3 and skipping configuration risk.
- Templated PQ that covers easy paths and skims the high-risk ones — critical thinking failure.
- URS that lists every feature the platform supports rather than the requirements specific to the regulated user's process — turns into untestable scope.
- Traceability matrix exists but does not actually trace — entries point at the wrong test or to deleted tests.
- Supplier audit pack is older than the deployed version — leveraged evidence does not cover the in-use software.
- Periodic review skipped because 'nothing has changed' — change control was incomplete, things changed.
- Change control treats configuration as out of scope — configuration changes affect GxP behaviour and need the same control as code changes.
- Validation Summary Report glosses over open risks instead of accepting them with documented rationale.
- Retirement plan written at retirement — no migration evidence, archive cannot be queried.
- Validation evidence stored only as printed signed paper — when the platform is upgraded the evidence is not searchable.
10How V5 Ultimate supports GAMP 5 in practice
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.
11Frequently asked questions
See below for regulator-grade answers to the questions buyers ask most often about GAMP 5.
Frequently asked questions
Q.Is GAMP 5 a regulation?+
No. GAMP 5 is industry guidance published by ISPE. Inspectors do not cite GAMP 5 as a predicate, they cite Annex 11 clause 4 or 21 CFR Part 11 §11.10(a). But GAMP 5 is the framework everyone — including inspectors — expects to see referenced as the operational answer to 'how did you validate?'
Q.What changed in GAMP 5 Second Edition (2022)?+
Three substantial changes. First, critical thinking became a first-class principle — validation effort scaled to risk and value, not template-driven. Second, agile, iterative and continuous-delivery methodologies were formally accepted as compatible with GxP validation. Third, SaaS, cloud, IT service management, machine learning and supplier-leveraged validation were explicitly addressed. The category system was also clarified (category 2 retired).
Q.How do I categorise a SaaS eQMS like V5?+
Almost always category 4 (configured products). The platform is COTS, configured to your workflows via formulas, documents, roles, and templates. Custom-coded extensions, if any, are category 5 and need deeper evidence. Infrastructure (Postgres, Cloudflare, the runtime) is category 1 and is evidenced by the supplier audit pack.
Q.Can agile and continuous delivery satisfy GAMP 5?+
Yes, explicitly per second edition. The principles do not change — every release still needs requirements, design, test evidence, and traceability — but the cadence shrinks. A two-week sprint delivers a tested increment with the same evidence, just smaller in scope. Continuous delivery often satisfies the regulator better than waterfall because every change is traced and tested, not bundled into a year-end release.
Q.What is supplier-leveraged validation?+
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. Second edition formalised this; it is now the standard model for validated-SaaS eQMS delivery.
Q.How is GAMP 5 different from FDA CSA?+
GAMP 5 is the broader industry framework (validation lifecycle, categories, supplier model). CSA is the FDA's 2022 draft guidance for production and quality-system software, specifically calling for risk-based, value-driven validation and accepting unscripted exploratory testing. The two are aligned — second-edition GAMP 5 was written with the same critical-thinking, risk-based intent. A modern programme uses GAMP 5 as the framework and CSA as the FDA's explicit blessing of the risk-based approach.
Primary sources
Further reading
- EU GMP Annex 11The European rule GAMP 5 helps satisfy.
- 21 CFR Part 11The US sibling rule.
- CSV — Computer System ValidationThe discipline GAMP 5 codifies.
- CSA — Computer Software AssuranceFDA's 2022 lighter-touch successor approach.
- IQ / OQ / PQThe validation phases GAMP 5 prescribes.
- How V5 Ultimate ships GAMP 5 evidenceValidated builds, traceability, change control.
V5 Ultimate ships with the GAMP 5 controls already wired in — audit trail, e-signatures, validation evidence. Free trial, no credit card, onboard in days, not months.
