What is GAMP 5?

Read the sheet above and the rest of this page follows. GAMP 5 is a well-used manual for meeting a duty that comes from elsewhere: Part 11's § 11.10(a), the predicate rules and, in Europe, Annex 11. FDA points to it as a resource and nothing more. Everything below comes from what ISPE publishes openly and from the rules themselves; we have not paraphrased any part of the guide we have not read.

ISPE says GAMP guidance “aims to safeguard patient safety, product quality, and data integrity in the use of GxP computerized systems”, and to get systems that are “fit for intended use” and meet current regulatory requirements. It names four jobs the guidance does: it helps interpret regulatory requirements, sets a common language, promotes a system life cycle approach, and clarifies roles and responsibilities.

The second and fourth jobs are the ones a small lab feels first. When a vendor sends a validation pack, an auditor asks for your supplier assessment, or a consultant talks about configured components, they are speaking GAMP. Part 11 tells you to validate (§ 11.10(a)); it never says how. GAMP 5 is the most common answer the industry wrote down, and its terms turn up in SOPs that never cite it.

ISPE publishes the second edition's table of contents for free. The headings below are taken from it; we have not read the 404 pages behind them, so the middle column says what each part covers, not what it concludes. The right column is where each part meets the rules a lab is inspected against.

ISPE's product page says the second edition keeps “the principles and framework of the first edition”and updates how they apply: a bigger role for service providers, development that is “not inherently linear”, and more use of software tools and automation. The headings show it: Section 3.4 and Appendix M12 on critical thinking, and Appendices D8 to D11 on agile development, software tools, blockchain and AI. The operation appendices are where Part 11 and Annex 11 overlap most; the Annex 11 vs Part 11 mapping lays the two rules side by side.

GAMP's backbone is the idea that validation is not a project you finish. ISPE says GAMP “promotes a system life cycle approach based on good practice”, and one of its course descriptions has the life cycle running “from concept to retirement”. The second edition's table of contents names four phases.

1. Phase 01

   Concept

   Is this system worth building or buying, and what will it be used for?

   A small lab keeps: Intended use, the records it will hold, a first risk view, a short list of suppliers.

2. Phase 02

   Project

   Specify, configure, verify, release.

   A small lab keeps: Requirements, supplier assessment, configuration record, tests sized by risk, a validation report.

3. Phase 03

   Operation

   Keep it in a validated state while it changes.

   A small lab keeps: Change control, access reviews, backup and restore checks, incidents, periodic review.

4. Phase 04

   Retirement

   Switch it off without losing the records.

   A small lab keeps: Data migration or archive, proof the records stay readable for the retention period.

Phase names: GAMP 5 Second Edition, Chapter 4, from ISPE's open table of contents. The rest of each box is our reading, not ISPE's text.

Two ideas run through every phase, and both are in ISPE's open pages. The first is that the work is scaled, not fixed. As ISPE's 2026 article quotes the guide: “Life cycle activities need to be added, removed and scaled based on the nature of the components and the identified risks.” The risk is to patient safety, product quality and data integrity, the same three things ISPE names as GAMP's purpose. The second is that the order is flexible: the product page says the GAMP specification and verification approach “is not inherently linear but also fully supports iterative and incremental methods”. A vendor that ships every two weeks does not break GAMP; it needs a change process that keeps up.

The EU rule reads the same way. Annex 11 § 1 asks for risk management “throughout the lifecycle of the computerised system”, § 4.1 wants validation records to “cover the relevant steps of the life cycle”, and its glossary defines the life cycle as running “from initial requirements until retirement”. Part 11 has no life cycle wording, but two of its controls only make sense over one: validation (§ 11.10(a)) and protecting records so they can be retrieved “throughout the records retention period” (§ 11.10(c)), which outlives most systems.

GAMP 5 sorts software into categories by how much of it is configured or custom-built for your use. ISPE's 2026 article gives the grouping question in the guide's words: “What complexity of activity has to be done to create the component for this specific application?” Setting a parameter is a small act; writing a thousand lines of code is a large one, and the chance of a defect left in the software rises with it.

A continuum, applied to components

The second edition's biggest change in this area is what gets categorised. ISPE's article says the wording was updated “to clarify that categorization applies to the (often multiple) components or products that make up a system”, and quotes Section 12.1.1: systems are “generally made up of a combination of components from different categories; the categories should be viewed as a continuum.” A LIMS is not one category. Its database, its standard functions, your configuration and the report someone wrote for you each sit at a different point.

Where a component sits depends on two things the article names: the complexity of creating it, and its novelty. Code that has been tested and used many times in similar settings is “much less likely to have residual defects”. That is why the category is a starting point, not a verdict. The article's Table 1 shows components that all needed only configuration, yet called for different amounts of work:

Here is how the component view works on a system a small lab actually buys: a cloud LIMS for a QC lab that tests incoming materials and finished product, with an instrument feeding results in and a certificate of analysis going out. The categorisation is per component, as the second edition asks; the effort follows the risk to the result, not the label.

Two rows go against the easy reading of the categories. The signature engine is a standard component, near the less built-for-you end of the scale, yet it gets your own test, because it is where Part 11 is checked and a mistake there touches every signed record. And the custom report looks small, but it is the one thing in the system nobody else has ever run, and it prints the document your customer relies on.

If you run this exercise feature by feature, the CSA validation scope planner records the risk call and the assurance activity for each one. Vendors in this category, and what each states about its Part 11 controls, are compared on the LIMS comparison.

The regulations say validate; the guidance documents say how hard; GAMP 5 is the industry's manual for doing it. The table puts the five documents a US lab or device maker meets side by side.

Part 11: the duty GAMP helps you meet

Part 11 does not mention GAMP and does not need to. It tells anyone using a closed system for Part 11 records to validate it, and the 2003 guidance adds that the depth should follow a documented risk assessment. A GAMP-style validation pack is one way to show you did. What GAMP cannot do is carry the parts of Part 11 that are about people and paper: the written policy that holds signers accountable (§ 11.10(j)), the training records (§ 11.10(i)) and the certification letter to FDA (§ 11.100(c)). The full list is in Part 11 requirements, section by section.

CSA: FDA's version of the same idea

FDA's computer software assurance guidance and GAMP 5 point the same way: spend effort where a failure would hurt. ISPE's product page says the second edition added a “Discussion of current FDA activity on Computer Software Assurance (CSA) approaches”, and the final CSA guidance in turn lists GAMP 5 Second Edition as a resource. Neither replaces the other. CSA is written for device makers' production and quality system software and sorts features into high process risk or not; GAMP covers any GxP system and adds the component categories, the supplier roles and the operation phase. A drug or GLP lab can borrow CSA's risk logic, but its own predicate rules still govern. CSA vs CSV covers what the 2026 guidance changed.

Annex 11: the rule that reads most like GAMP

If you also supply the EU, Annex 11 will feel familiar after GAMP. It asks for risk management across the life cycle, an inventory of systems, user requirements traceable through the life cycle, an assessed supplier, change and configuration management, periodic evaluation, business continuity and archiving: much of the same ground as GAMP's chapters and appendices. The 2011 text is the one in force; a revision was consulted on in 2025. The EU Annex 11 guide goes clause by clause.

You can run GAMP-style validation from the open material and the rules themselves. These seven steps are our distillation; each one rests on a line ISPE publishes openly or on the rule text.

When the guide is worth buying

Buy it when you build or commission custom software, when you run enough systems that a shared method saves real time, or when your customers' auditors cite its appendices and you need to answer in the same terms. For lab systems specifically, ISPE also lists a “GAMP Good Practice Guide: GxP Compliant Laboratory Computerized Systems 2nd Edition”. A three-person lab with one cloud ELN and one LIMS can usually do without either and spend the money on testing its own configuration. Pre-written test steps for the project phase are in the IQ OQ PQ template.

Read 2026-10-22. ISPE pages are its open material only; the guide itself was not read. Regulation text quoted from the eCFR and EudraLex; guidance quoted from FDA. General information, not regulatory advice.

1. GAMP 5 Guide, 2nd Edition (product page), ISPEread 2026-10-22
2. ISPE GAMP 5 Guide, Second Edition: Table of Contents (PDF), ISPEread 2026-10-22
3. What is GAMP?, ISPEread 2026-10-22
4. When Is a Category Not a Category? (Pharmaceutical Engineering, January/February 2026), ISPEread 2026-10-22
5. 21 CFR Part 11, Electronic Records; Electronic Signatures, eCFRread 2026-10-22
6. Part 11, Electronic Records; Electronic Signatures — Scope and Application (2003 guidance), PDF, FDAread 2026-10-22
7. Computer Software Assurance for Production and Quality Management System Software (2026), FDAread 2026-10-22
8. Computer Software Assurance guidance, PDF (footnote 25), FDAread 2026-10-22
9. EudraLex Volume 4, Annex 11: Computerised Systems (2011), European Commissionread 2026-10-22
10. Stakeholders' consultation on EudraLex Volume 4: Chapter 4, Annex 11 and new Annex 22, European Commissionread 2026-10-22