GAMP 5Good Automated Manufacturing Practice (v5)

GAMP 5 Second Edition is ISPE’s industry standard for achieving fit-for-purpose validation of GxP computerized systems. It reconciles regulatory expectations with the realities of modern software engineering, emphasizing risk-based thinking, supplier leverage, and critical thinking over rote paperwork. The result is objective evidence that a system does what it is intended to do for its GxP use, generated in proportion to risk and complexity.

The guidance is not a regulation, but it is widely referenced by regulators and inspectorates. It clarifies how to define intended use, categorize software, plan assurance activities, and document the rationale behind testing depth and traceability. It also updates long-standing practices to reflect SaaS, configurable platforms, infrastructure as code, and continuous delivery without losing control.

Practitioners use GAMP 5 to structure validation from user requirements through testing, release, and operation. It balances rigor with speed by leveraging supplier documentation where appropriate, focusing testing on high-impact functions, and establishing lifecycle controls that support ongoing change. In short, it operationalizes good risk management for computerized systems within a broader GxP quality system.

GAMP 5 aligns with the EU GMP Annex 11 expectation that computerized systems used in GxP processes be validated during their lifecycle, and operated in a state of control. Annex 11 clause 4 on validation requires evidence that systems are fit for intended use, including appropriate testing and documentation. In the United States, 21 CFR Part 11 §11.10(a) requires controls for electronic records that include validated systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.

Beyond these anchors, other statutes and standards reinforce the duty to validate. For drugs, 21 CFR Part 211 requires controls over automated equipment used in production and quality operations. For devices, 21 CFR Part 820 requires design controls and validation of production software and automated processes consistent with product risk. Collectively, these expectations converge on the principle that validation is risk-based and commensurate with the impact of the computerized function on product quality and patient safety.

GAMP 5 is applied across pharmaceutical, biopharmaceutical, medical device, blood, tissue, and advanced therapy manufacturing, as well as supporting laboratories and distribution. Global inspectorates coordinated under PIC/S and the EMA routinely encounter GAMP-style documentation and accept it where the evidence is rational, traceable, and complete. The guidance is particularly valuable in mixed environments that combine bespoke code, configurable platforms, and qualified infrastructure.

In practice, organizations use GAMP 5 to organize requirements, hazard analysis, testing, and change control into a defensible story of intended use and verified performance. It clarifies the split of responsibilities between regulated companies and suppliers, especially for hosted services, and it promotes periodic review to ensure systems continue to perform as validated after updates.

References in this page to Annex 11 and Part 11 are foundational, but GAMP 5’s methods also support compliance under general GMP frameworks, including 21 CFR 211 for drugs and 21 CFR 820 for medical devices.

GAMP 5 Second Edition uses four software categories to right-size assurance for different technology types. Categories are not labels for their own sake; they are a shortcut for selecting risk-appropriate verification, supplier assessment, and configuration control. Correct categorization depends on the intended use in the GxP process and on how the software is built and changed.

Category 1 covers infrastructure such as operating systems, databases, networks, and virtualization. It is qualified rather than validated for specific process use, with focus on installation, configuration baselines, hardening, and patching. Category 3 covers non-configured software, typically installed commercial tools used largely as delivered. Verification emphasizes installation, basic functional checks for intended use, and supplier assurance.

Category 4 covers configurable products such as platforms and applications whose behavior is materially shaped by configuration, rules, or workflows. The bulk of assurance is placed on defining and testing the configured intended use, controlling configuration specifications, and maintaining traceability from requirements to configuration and tests. See GAMP5 Category 4 for deeper treatment of configuration records and regression strategy.

Category 5 covers bespoke or custom code, extensions, and scripts. These require full lifecycle controls appropriate to software engineering, including code reviews, unit and integration testing, and more extensive verification where risk warrants. Many modern SaaS platforms blend Category 4 configurations with targeted Category 5 extensions, which calls for clear demarcation of responsibilities and evidence. See GAMP5 Category 5 for examples of testing depth and change control.

GAMP 5’s lifecycle is traditionally illustrated as a V-model: on the left, the definition of requirements and design; on the right, verification and validation mapped back to those definitions. The model clarifies traceability: each requirement must be verified by appropriate testing or review. What has evolved in the Second Edition is the explicit recognition that agile development, DevOps, and SaaS can all produce compliant evidence without forcing documents to mimic a waterfall.

In agile contexts, user stories and acceptance criteria can serve as requirements. Definition of done, peer review, and automated tests can be structured to yield regulator-ready evidence. Supplier testing and certifications are leveraged through documented supplier assessment, while risk determines what must be verified in-house. For SaaS, the supplier’s lifecycle records are complemented by the regulated company’s intended use definition, configuration specifications, and risk-based verification.

Whether you deliver quarterly or multiple times per day, the essentials do not change: define intended use, analyze risk, verify what matters most, and maintain traceability. A quality management system must anchor this practice with change control, training, and incident management so that the system remains in a validated state as it evolves. See our primer on the role of the QMS in software lifecycle governance: What is a QMS.

To satisfy Annex 11 validation expectations and Part 11’s call for validated systems, you must generate objective, traceable evidence that the computerized system reliably supports its intended GxP use. GAMP 5 concentrates documentation on what regulators need to see and what you need to manage risk. The core is a clearly bounded intended use, a reasoned risk assessment that prioritizes critical functionality, and verification that proves those functions work for real-world scenarios.

Evidence typically includes supplier assessment, controlled configuration specifications, test records that link back to requirements and risk, and a validation report that justifies the approach. Security, access controls, data integrity, and audit trails must be designed and verified to ensure records are attributable, legible, contemporaneous, original, and accurate. Training and procedural controls complete the picture so people consistently operate the system as validated.

Where electronic records or signatures are used, capabilities and controls aligned with 21 CFR Part 11 must be enabled and verified in the context of intended use. That includes account management, unique user identification, time-synchronized audit trails, and appropriate signature manifestations. The level of depth should be proportional to risk and the software category, with special attention paid to any Category 4 configuration and Category 5 code that directly affects product quality decisions.

• Validation Plan defining scope, roles, risk strategy, and deliverables
• Documented intended use and user requirements tied to GxP processes
• Supplier assessment and service-level controls for hosted services
• Configuration specification and baseline, under change control
• Risk assessment focused on patient, product, and data impact
• Installation, operational, and performance qualification evidence as appropriate
• Traceability matrix linking requirements, risks, tests, and deviations
• Validation report concluding fitness for intended use and residual risk

GAMP 5 embeds risk management so that effort tracks with potential impact on patients, products, and data. This is consistent with the direction of international guidance, including ICH Q9/Q10 and FDA’s emphasis on Computer Software Assurance principles. The goal is to spend the most time verifying the functions that make the biggest difference, while using supplier evidence and unscripted testing where risk and maturity allow.

Practically, that means classifying requirements by criticality, choosing verification methods accordingly, and justifying the choice. Critical functions that drive batch release or patient safety call for rigorous, traceable testing and negative cases. Non-critical features can be handled through risk-based exploratory testing or supplier certificates. Deviations are treated as learning opportunities, with clear impact assessments and corrective actions captured in your quality system. Where issues surface post-release, structured deviation and change processes maintain control without defaulting to revalidation from scratch. See also Structured deviations.

CSA-style critical thinking does not eliminate documentation; it trims it to what matters. Teams use checklists to ensure coverage of data integrity, access, and security while focusing test design on real user workflows and system risks. The validation report then tells a clear story: what you intended, how you mitigated risk, what you verified, and why this is sufficient for the system’s use.

Modern validation often involves cloud platforms and SaaS applications. GAMP 5 clarifies the shared responsibility model: providers are responsible for the service lifecycle and underlying controls, while the regulated company is responsible for defining intended use, configuring safely, and verifying that the configured service supports GxP processes. This is elaborated in practice under many organizations’ cloud validation playbooks and is consistent with the guidance’s category and risk principles for GxP cloud computing.

Supplier assurance becomes central. Auditable evidence can include the provider’s quality certifications, penetration tests, vulnerability management, and change-notification processes. Your validation focuses on configuration, integration points, and business rules that affect decisions such as batch release, deviation routing, or electronic signatures. Release cadences are handled through change control that evaluates impact based on release notes, performs targeted regression, and documents rationale.

On-premises deployments remain common for certain workloads and regulated facilities. Here, you own more of the stack, including infrastructure qualification, backup and recovery tests, and patching strategy. Whether cloud or on-premises, the core GAMP 5 themes persist: categorize correctly, scale documentation by risk, and maintain traceability through change.

• Define the demarcation of responsibilities in supplier agreements and procedures
• Obtain and review supplier quality and security evidence at onboarding and periodically
• Baseline and control configuration that realizes intended use
• Assess impact for each supplier release and perform targeted regression testing
• Verify Part 11-relevant controls for accounts, audit trails, and signatures before enabling in production
• Exercise disaster recovery and data export processes in line with business continuity plans

GAMP 5 complements, rather than replaces, the regulatory frameworks that govern medicinal products and medical devices. It provides the process-and-evidence glue that demonstrates how your computerized system supports compliance with those frameworks. The guidance borrows from sound engineering practice and aligns with standards-based quality management so that validation is integrated, not bolted on.

In the EU, Annex 11 specifies lifecycle validation for computerized systems and links to broader GMP expectations under EudraLex. Annex 15 expands on qualification and validation principles across equipment and processes, which GAMP 5 operationalizes for software and infrastructure. For devices, design controls under 21 CFR Part 820 expect verification and validation of software used in design and production; GAMP 5 offers a structure to make that evidence traceable and risk-based.

In the software domain, standards such as ISO 13485 for medical devices and IEC 62304 for medical device software shape expectations for development and maintenance. While GAMP 5 does not replace those standards, it aligns with their spirit by emphasizing documented intent, traceability, and appropriate verification. Sector-specific guidance, such as sterile manufacturing expectations, may increase the emphasis on data integrity, environmental monitoring interfaces, and contamination controls that must be reflected in validation scope.

Taken together, these frameworks create a coherent picture: define what matters, manage risk, verify performance, and keep systems in control through change. GAMP 5 adds the categories and lifecycle mechanics that make this practical across a portfolio that includes configurable platforms, custom code, and qualified infrastructure. For deeper dives, see Annex 11, Annex 15, and device-focused design control topics under 21 CFR 820, as well as sterile manufacturing considerations in EU GMP Annex 1 sterile manufacturing readiness.

The most frequent GAMP 5 misstep is to equate compliance with volume. Producing large binders of templated documents does not impress inspectors if the content does not trace to real risks and intended use. Another common error is to over-test low-impact functions while skimming the critical paths where product and patient risks reside.

Misclassification of software is a close second. Treating a configurable platform as if it were non-configured can undermine configuration control, while treating SaaS as entirely out of scope ignores your responsibility for intended use and configuration. Over-reliance on vendor certificates without a documented supplier assessment and without verifying your configuration is another recurring concern.

Teams also stumble on data integrity and security controls. If user management, access, audit trails, and time synchronization are not specified and verified, validation is incomplete. Finally, failure to plan targeted regression for frequent releases leads to unnecessary rework or blind spots. A clean validation report that explains decisions and residual risk is the antidote to both extremes.

• Writing a URS that restates vendor brochures instead of defining intended use
• Classifying configurable SaaS as non-configured and skipping configuration control
• Assuming supplier testing replaces verification of your risk-critical workflows
• Over-documenting low-risk features while under-testing release-critical functions
• Ignoring Part 11-relevant controls until late in the project
• Lacking a rationale for regression scope when supplier updates are applied
• Treating deviations as paperwork rather than input to root cause and prevention
• Letting the traceability matrix drift from actual tests and configurations

V5 Ultimate operationalizes GAMP 5 by unifying intended use definitions, risk assessments, configuration specifications, testing, and traceability in one controlled workflow. Teams author user requirements and risks once, then drive risk-based test design and execution with automated trace updates and evidence capture. Supplier assessments, change control, and release impact evaluation are built into the same record so the validation story remains coherent through updates.

For electronic records and signatures, V5 provides technical and procedural controls aligned to Part 11 expectations, including identity, roles, audit trails, and time stamping. Quality and manufacturing modules integrate validation with incident management, training, and controlled distribution so systems remain in a validated state as they evolve. This creates a closed-loop between quality events, change, and verification without fragmenting documentation.

Whether you run cloud, hybrid, or on-premise deployments, V5 captures supplier evidence, configuration baselines, and targeted regression rationale per release. Validation reports are generated from live records with full traceability, making inspection readiness a continuous property, not a scramble. For governance and continuous improvement, V5’s dashboards spotlight overdue periodic reviews, open actions, and risk hotspots across your portfolio. Learn how our QMS module anchors lifecycle controls alongside validation content.