GAMP 5 Principles for Computerized System Validation

GAMP 5 provides a practical, risk-based framework for establishing and maintaining confidence in computerized systems used in regulated pharmaceutical, biotechnology, and medical-device operations. It connects regulatory expectations with lifecycle activities such as intended-use definition, requirements, specification, supplier assessment, configuration, verification, release, change control, periodic review, and retirement.

GAMP means Good Automated Manufacturing Practice. GAMP 5 is published by the International Society for Pharmaceutical Engineering (ISPE). It is an industry good-practice guide—not a law, regulation, regulatory standard, or mandatory validation method.

Organizations may use GAMP 5 to support compliance, but citing the guide does not demonstrate that a system is validated. Compliance depends on whether the computerized system is fit for its intended use, meets applicable regulatory requirements, protects its records, controls identified risks, and remains in a validated state throughout its operational life.

The framework should therefore be applied with judgment. Its purpose is not to create a fixed collection of documents or force every system through the same Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) structure. Its purpose is to direct assurance effort toward the functions, data, records, interfaces, configurations, and failure modes that can affect patient safety, product quality, or data integrity.

Regulatory Status of GAMP 5

GAMP 5 should be described accurately in validation plans, procedures, reports, and training materials. It is:

• a voluntary industry framework;
• a recognized source of good practices;
• a risk-based computerized-system lifecycle model;
• a method for interpreting and implementing regulatory expectations;
• adaptable to different technologies and regulated uses; and
• intended to support—not replace—organizational judgment and quality-system controls.

It is not:

• a regulation;
• legally binding by itself;
• an FDA-issued guidance document;
• a certification standard;
• a universal validation checklist;
• a requirement to generate every document shown in a model; or
• evidence that a specific system complies with applicable requirements.

Regulatory obligations arise from the laws and regulations applicable to the product, process, records, and jurisdiction.

For US drug manufacturing, 21 CFR 211.68 establishes requirements for automatic, mechanical, electronic, computer, and related systems used in drug manufacturing. When electronic records or electronic signatures are used to satisfy applicable regulatory requirements, 21 CFR Part 11 may also apply.

FDA guidance documents are themselves generally nonbinding recommendations, but they communicate the Agency’s current thinking. GAMP 5 is further removed from regulation because it is produced by industry rather than by a regulatory authority. Nevertheless, its lifecycle, risk-management, supplier, and verification principles can provide a defensible structure for meeting regulatory expectations.

The FDA Part 11—Scope and Application guidance expressly recognizes the importance of a justified, risk-based approach to validation. FDA’s Data Integrity and Compliance With Drug CGMP guidance further emphasizes controls over complete data, metadata, system access, audit trails, backup, and record review.

An organization may follow GAMP 5 and still be noncompliant if it fails to address its actual intended use, configuration, data flows, users, or regulated records. Conversely, an organization is not required to reproduce GAMP terminology exactly if its own lifecycle achieves equivalent and adequately documented control.

The Primary Assurance Objectives

GAMP 5 places three related objectives at the center of the computerized-system lifecycle:

• patient safety;
• product quality; and
• data integrity.

These objectives should guide decisions about requirements, risks, controls, supplier evidence, testing, release, change management, and periodic review.

Patient Safety

A computerized system can affect patient safety directly or indirectly.

Potential effects include:

• incorrect formulation or processing parameters;
• failure to detect an adverse process condition;
• incorrect laboratory calculations;
• inappropriate acceptance or release decisions;
• incorrect product labeling;
• loss of traceability;
• failure to communicate a safety-related event;
• compromised sterility or contamination controls; and
• incomplete information used during an investigation or recall.

The analysis should identify credible effects of failure rather than simply assigning the whole application a generic risk rating.

Product Quality

Computerized systems can affect identity, strength, quality, purity, and other established product attributes by controlling or supporting:

• manufacturing sequences;
• recipes;
• critical process parameters;
• material identity and status;
• laboratory methods;
• specifications;
• calculations;
• environmental conditions;
• equipment status;
• electronic batch records;
• inspection and rejection functions; and
• product-disposition decisions.

Product-quality risk can also arise from interfaces, infrastructure, master data, configuration, or user access even when the application does not directly control manufacturing equipment.

Data Integrity

Data integrity concerns the completeness, consistency, accuracy, attribution, protection, retention, and availability of regulated data throughout its lifecycle.

Relevant controls may include:

• unique user identities;
• role-based access;
• audit trails;
• electronic signatures;
• controlled system time;
• metadata retention;
• validated calculations;
• protected configuration;
• interface monitoring;
• backup and restoration;
• record retention;
• data migration controls; and
• review of changes and exceptions.

The ALCOA+ Data-Integrity Principles and System Controls article addresses these controls in greater detail.

Patient safety, product quality, and data integrity should not be treated as three isolated classifications. A single failure can affect all three. For example, an unauthorized change to a laboratory calculation may compromise the electronic record, produce an incorrect result, and contribute to release of unsuitable product.

Five Core GAMP 5 Concepts

The GAMP 5 framework is commonly expressed through five interdependent concepts:

1. product and process understanding;
2. lifecycle approach within a quality management system;
3. scalable lifecycle activities;
4. science-based quality risk management; and
5. leveraging supplier involvement.

These concepts should operate together. Scaling documentation without understanding risk can weaken control. Supplier leverage without supplier assessment can create unsupported assumptions. Testing without understanding the business process can produce extensive evidence that does not demonstrate fitness for intended use.

Product and Process Understanding

Effective validation begins with understanding the regulated process—not with selecting protocol templates.

The organization should understand:

• the business process supported by the system;
• the product or operation affected;
• the system’s intended use;
• regulated decisions supported by the system;
• critical functions;
• critical data and metadata;
• authoritative record sources;
• process inputs and outputs;
• calculations and transformations;
• workflows and status transitions;
• user roles;
• interfaces;
• exceptional conditions;
• available independent controls; and
• credible consequences of failure.

Technical complexity alone does not establish risk. A small spreadsheet that performs a release calculation may require more focused assurance than a large application used only for noncritical scheduling.

Product and process understanding should be documented sufficiently to support requirements, risk assessment, system boundaries, test objectives, release decisions, and lifecycle controls.

The preceding Computerized System Types, Intended Use, and GxP Classification article explains how business process, intended use, system boundaries, regulated records, and failure consequences establish the foundation for validation.

Lifecycle Approach Within the Quality System

Validation is not an event completed by approving a final report. It is a lifecycle beginning before selection or implementation and continuing until the system and its regulated records are appropriately retired.

A typical lifecycle includes:

• concept and business-process definition;
• intended-use definition;
• GxP and Part 11 assessments;
• system boundary and architecture;
• supplier and product evaluation;
• validation planning;
• requirements;
• risk assessment;
• specifications;
• design and configuration;
• implementation;
• installation and environment verification;
• functional and control testing;
• data migration;
• end-to-end or user-acceptance testing;
• deviation and defect resolution;
• release;
• operation;
• monitoring;
• change control;
• periodic review;
• revalidation when justified;
• archival or migration;
• decommissioning; and
• retirement.

The lifecycle should operate within the organization’s pharmaceutical quality system. Relevant controls include:

• document management;
• change control;
• deviation and corrective-action management;
• training;
• supplier management;
• access management;
• configuration management;
• incident management;
• backup and recovery;
• security;
• periodic review;
• records retention; and
• quality oversight.

Scalable Lifecycle Activities

GAMP 5 supports scaling lifecycle activities and evidence according to the system’s intended use and risk.

Scaling does not mean removing necessary control merely because a system appears simple. It means selecting an appropriate level of formality, detail, independence, documentation, and verification.

The validation approach should reflect:

• intended GxP use;
• patient and product impact;
• data criticality;
• novelty;
• technical and process complexity;
• software type;
• extent of configuration;
• extent of custom code;
• number and criticality of interfaces;
• use of calculations or algorithms;
• infrastructure and hosting model;
• supplier capability;
• quality of available supplier evidence;
• migration complexity;
• cybersecurity exposure;
• operational experience; and
• ability of independent controls to detect failure.

Examples of Appropriate Scaling

A simple commercial application with limited configuration may use:

• a concise validation plan;
• focused requirements;
• an approved configuration record;
• supplier documentation;
• risk-based functional testing;
• controlled release; and
• proportionate operational procedures.

A configured enterprise platform supporting several critical workflows may require:

• a detailed system architecture;
• module and interface boundaries;
• comprehensive requirements;
• configuration and security specifications;
• supplier assessment;
• risk analyses by function or process;
• data-migration plans;
• end-to-end testing;
• detailed traceability;
• formal release readiness review; and
• continuing lifecycle monitoring.

A custom application may require greater design and development evidence, including:

• software architecture;
• detailed design;
• source-code controls;
• coding standards;
• code review;
• unit and integration testing;
• defect management;
• build and deployment controls;
• version control; and
• maintenance responsibilities.

A critical calculation in an otherwise simple application may require narrow but rigorous verification of formulas, units, precision, rounding, boundary values, abnormal inputs, error handling, and independent expected results.

The amount of paper is not a reliable measure of assurance. Documentation should be sufficient to support decisions, demonstrate control, permit review, reproduce critical evidence, and maintain the validated state.

Science-Based Quality Risk Management

Risk management directs attention toward what can affect the patient, product, process, or regulated record. The assessment should connect:

1. intended use;
2. process step or requirement;
3. system function or data;
4. credible failure;
5. potential effect;
6. existing prevention or detection controls;
7. required additional control;
8. verification objective; and
9. residual-risk acceptance.

Science-based risk management should use relevant process knowledge, technical knowledge, historical evidence, supplier information, operational experience, and understanding of failure mechanisms.

It should not depend solely on numerical scoring.

A numerical score may help prioritize work, but it can conceal important failure scenarios. A low combined score should not justify excluding verification when the failure could compromise a critical calculation, security control, audit trail, interface, or regulated decision.

Risk assessment should influence:

• requirements detail;
• specification depth;
• supplier evaluation;
• configuration review;
• test coverage;
• positive and negative testing;
• boundary-value testing;
• interface testing;
• security testing;
• data-migration verification;
• regression scope;
• deviation resolution;
• release conditions;
• operational monitoring; and
• periodic-review focus.

Risk management should be updated when knowledge changes. New defects, incidents, supplier notices, cybersecurity vulnerabilities, process changes, adverse trends, or expanded intended use may invalidate earlier assumptions.

Critical Thinking

Critical thinking is necessary to apply the GAMP 5 framework without turning it into a checklist.

Critical thinking means using informed judgment to determine:

• what the system is relied upon to do;
• what evidence already exists;
• whether that evidence is credible and applicable;
• what can fail;
• how failure would be detected;
• which controls are independent;
• what requires direct verification;
• where unscripted testing may be useful;
• which documentation provides value;
• and what evidence is sufficient for release.

Examples include:

• testing the configured workflow instead of retesting every unused supplier feature;
• independently verifying a critical calculation rather than accepting a supplier’s general test summary;
• reviewing audit-trail behavior for actual regulated record changes;
• concentrating interface testing on mapping, status, units, precision, rejection, duplicates, and recovery;
• using supplier installation evidence when it is applicable and controlled;
• avoiding repetitive site tests that add no meaningful assurance;
• increasing verification when configuration is novel or supplier evidence is weak; and
• challenging assumptions that an apparently standard function cannot fail in a site-specific configuration.

Critical thinking does not mean undocumented discretion. Important decisions, assumptions, exclusions, and acceptance rationales should remain reviewable and traceable.

Supplier Involvement and Evidence Leverage

Modern computerized systems depend heavily on suppliers, service providers, cloud providers, integrators, and subcontractors.

Suppliers may perform or provide:

• software development;
• design;
• product testing;
• infrastructure management;
• hosting;
• cybersecurity;
• configuration;
• implementation;
• data migration;
• technical support;
• patching;
• backup;
• disaster recovery;
• release management; and
• regulated-record services.

GAMP 5 supports appropriate use of supplier knowledge and evidence. The regulated organization should not reproduce reliable supplier work without a risk-based reason. However, supplier evidence should be assessed before acceptance.

The assessment should consider:

• supplier experience;
• quality-management system;
• development lifecycle;
• testing practices;
• configuration management;
• defect management;
• cybersecurity program;
• personnel competence;
• subcontractor controls;
• product history;
• release practices;
• support capability;
• change notification;
• business continuity;
• data export;
• regulatory support; and
• continued product support.

Supplier documentation may include:

• product descriptions;
• architecture;
• specifications;
• design records;
• development procedures;
• test summaries;
• installation instructions;
• configuration guides;
• release notes;
• known-error lists;
• security documentation;
• service reports;
• certificates; and
• audit reports.

Supplier evidence should be assessed for:

• authenticity;
• completeness;
• relevance;
• version applicability;
• traceability;
• approval status;
• test-environment comparability;
• test-result clarity;
• unresolved defects; and
• suitability for the site’s intended use.

Supplier testing cannot replace site-specific verification of:

• intended use;
• configured workflows;
• business rules;
• user roles;
• permissions;
• critical calculations;
• reports;
• interfaces;
• migrated data;
• site infrastructure;
• operating procedures;
• exceptional workflows; and
• end-to-end business processes.

The validation plan should state which supplier evidence will be accepted, which evidence will be supplemented, and which functions require direct site verification. Additional detail is provided in Computerized System Supplier Assessment and Evidence Leverage.

Intended Use Drives Validation

The intended-use statement defines what the organization relies on the computerized system to accomplish. It should identify:

• the regulated business process;
• principal users;
• functions relied upon;
• records created or maintained;
• calculations and decisions supported;
• critical interfaces;
• operating environment;
• relevant products or operations; and
• important exclusions.

Intended use establishes the basis for requirements, risk assessment, supplier strategy, verification, release, and change control.

The same software product may require different validation approaches at different sites because the intended use, configuration, records, integrations, and operational controls differ.

Validation effort should increase when intended use involves:

• critical process control;
• batch release;
• product disposition;
• critical laboratory calculations;
• product or material status;
• automated inspection or rejection;
• electronic signatures;
• complex interfaces;
• significant data transformation;
• critical master data;
• sole retention of regulated records; or
• failure modes that are difficult to detect independently.

Validation effort should not be reduced merely because the product is commercially available or widely used.

Requirements and Specifications

Requirements define what the system must do to support its intended use and applicable controls.

Requirements may address:

• business processes;
• functions;
• workflows;
• data;
• metadata;
• calculations;
• security;
• audit trails;
• electronic signatures;
• interfaces;
• reporting;
• performance;
• availability;
• backup;
• restoration;
• retention;
• migration;
• infrastructure;
• regulatory controls; and
• operational support.

Requirements should be:

• uniquely identified;
• clear;
• necessary;
• testable;
• traceable;
• approved by appropriate owners; and
• maintained under change control.

Specifications explain how requirements will be implemented. Depending on the system, they may include:

• functional specifications;
• design specifications;
• configuration specifications;
• interface specifications;
• data specifications;
• report specifications;
• calculation specifications;
• infrastructure designs; and
• security configurations.

Not every system requires separate documents for every specification type. Information may be combined when the resulting record remains clear, approved, controlled, and usable for verification and maintenance.

The required detail depends on novelty, complexity, configuration, custom development, supplier evidence, and risk. A configuration workbook may adequately document a simple commercial application. A custom or highly integrated system may require detailed design and interface documentation.

Configuration Management

Configuration determines how a configurable software product behaves in the regulated environment.

Controlled configuration may include:

• enabled modules;
• workflows;
• status transitions;
• business rules;
• calculations;
• code tables;
• master data;
• specifications;
• methods;
• recipes;
• reports;
• audit-trail settings;
• electronic-signature settings;
• roles and permissions;
• interface mappings;
• alarm settings;
• system parameters;
• retention settings; and
• infrastructure components.

The approved configuration baseline should identify what was released into production. It should be sufficiently detailed to:

• reproduce the approved state;
• identify unauthorized changes;
• assess proposed changes;
• support regression testing;
• investigate incidents;
• compare environments;
• and support recovery or replacement.

Configuration management should control movement between development, test, validation, and production environments. Direct unapproved changes in production undermine the validated state even when the resulting function appears to operate correctly.

Verification and Objective Evidence

Verification provides objective evidence that requirements, specifications, risk controls, configurations, and business processes operate as intended.

Verification may include:

• document review;
• supplier-evidence review;
• configuration review;
• code review;
• automated testing;
• scripted testing;
• unscripted or exploratory testing;
• calculation verification;
• interface testing;
• security testing;
• data-migration reconciliation;
• backup and restoration testing;
• disaster-recovery exercises;
• and representative end-to-end testing.

The test method should fit the objective.

Scripted tests are useful when:

• exact steps and results must be demonstrated;
• regulated workflows require reproducibility;
• calculations or boundaries require precise comparison;
• evidence must support traceability;
• or execution requires formal preapproval.

Unscripted or exploratory testing can be useful when knowledgeable testers need to challenge:

• unusual sequences;
• unexpected user behavior;
• error handling;
• workflow combinations;
• configuration interactions;
• and conditions not efficiently represented by fixed scripts.

Unscripted testing should still have a defined objective, qualified tester, documented observations, retained evidence, and controlled handling of discovered defects.

Testing should include appropriate challenges of:

• normal operation;
• invalid inputs;
• boundary values;
• unauthorized actions;
• interrupted processes;
• interface failures;
• duplicate or missing transactions;
• calculation precision;
• error messages;
• recovery;
• and record integrity.

Passing tests does not compensate for unclear requirements, uncontrolled configuration, inadequate supplier evidence, or unresolved significant defects.

Traceability

Traceability demonstrates how validation evidence supports intended use and identified controls.

Traceability may connect:

• intended use;
• requirements;
• risks;
• specifications;
• configuration records;
• supplier evidence;
• tests;
• deviations;
• defects;
• procedures;
• training;
• migration evidence;
• release conditions;
• and residual-risk acceptance.

A requirements traceability matrix is one method, but traceability should not be reduced to a table of requirement and test numbers. The evidence should show whether each relevant requirement and risk control was implemented, verified, and accepted.

Traceability should be maintained when requirements, configuration, tests, or controls change. Removed, deferred, partially tested, or failed requirements should remain visible and appropriately resolved.

Release and Operational Readiness

Release should confirm that the computerized system is suitable for its intended use and ready for controlled operation.

Release readiness should address, as applicable:

• approved intended use;
• completed GxP and Part 11 assessments;
• approved requirements and specifications;
• accepted supplier evidence;
• approved configuration baseline;
• completed verification;
• requirements and risk-control coverage;
• resolved deviations and defects;
• accepted residual risk;
• successful migration;
• interface readiness;
• authorized user access;
• approved procedures;
• completed training;
• backup and restoration readiness;
• business-continuity arrangements;
• support responsibilities;
• monitoring;
• and Quality approval.

Conditional release may be appropriate when unresolved items do not create unacceptable risk and are subject to documented limitations, compensating controls, ownership, due dates, and follow-up.

Release approval is not the end of validation. It transfers the system into controlled operation.

Change Control and Maintaining the Validated State

The validated state is maintained when the system continues to perform its approved intended use under controlled conditions.

Relevant operational controls include:

• incident management;
• problem management;
• access administration;
• audit-trail review;
• backup monitoring;
• restoration testing;
• performance monitoring;
• supplier management;
• vulnerability management;
• patch assessment;
• configuration control;
• change control;
• regression testing;
• training;
• periodic review; and
• record retention.

Changes requiring assessment may include:

• application upgrades;
• patches and hotfixes;
• cybersecurity changes;
• configuration changes;
• workflow changes;
• report changes;
• calculation changes;
• interface changes;
• master-data structures;
• database changes;
• infrastructure changes;
• identity-service changes;
• cloud-provider changes;
• supplier changes;
• new intended uses; and
• retirement of connected systems.

The change assessment should determine:

• reason for the change;
• affected requirements and risks;
• regulated records affected;
• configuration impact;
• interface impact;
• migration needs;
• testing and regression scope;
• procedure and training changes;
• rollback arrangements;
• release requirements;
• and whether broader revalidation is necessary.

Not every change requires full revalidation. The required work should be based on the affected functions, data, controls, integrations, and failure consequences.

Emergency changes should still be authorized, documented, verified to the extent practicable, and subjected to timely retrospective review.

Periodic Review

Periodic review provides documented confirmation that the system remains suitable, supported, controlled, and in a validated state.

Review inputs may include:

• current intended use;
• system inventory information;
• configuration baseline;
• changes;
• incidents;
• deviations;
• unresolved defects;
• access reviews;
• privileged activity;
• audit-trail review;
• interface failures;
• backup and restoration results;
• performance and capacity;
• security events;
• vulnerabilities and patches;
• supplier notices;
• support status;
• service performance;
• training;
• procedures;
• data retention;
• regulatory changes;
• obsolescence; and
• prior review commitments.

The review should determine whether:

• validation evidence remains adequate;
• controls remain effective;
• risk assumptions remain valid;
• remediation is needed;
• targeted or broader revalidation is justified;
• continued use remains acceptable;
• or retirement planning should begin.

Review frequency should reflect risk, rate of change, operational history, supplier release cadence, technology stability, and applicable procedures.

Retirement

Retirement is part of the validation lifecycle. The retirement strategy should address:

• approved decommissioning;
• final data reconciliation;
• record ownership;
• retention requirements;
• metadata;
• audit trails;
• electronic signatures;
• readable retrieval;
• archival format;
• migration;
• access after retirement;
• infrastructure disposition;
• interface shutdown;
• backup disposition;
• supplier termination;
• licenses;
• security;
• procedures;
• and destruction authorization.

A system may stop processing transactions while remaining GxP-relevant because it retains regulated records. Record availability, readability, integrity, and retrieval should therefore be maintained for the required retention period.

What GAMP 5 Does Not Require

GAMP 5 should not be interpreted as requiring:

• identical deliverables for every system;
• a fixed IQ/OQ/PQ package;
• testing of every available software feature;
• complete repetition of acceptable supplier testing;
• numerical risk scoring;
• separate documents when combined records are adequate;
• exhaustive scripted testing as the only acceptable method;
• elimination of professional judgment;
• or validation based solely on software category.

GAMP software categories help characterize the nature of software components and inform the development, specification, configuration, supplier, and verification strategy. They do not determine GxP impact or automatically prescribe a validation package.

That distinction is addressed in GAMP 5 Software Categories and Validation Strategy.

Practical Application of GAMP 5

A defensible application of GAMP 5 should produce clear answers to the following questions:

• What regulated process does the system support?
• What is the approved intended use?
• Where is the system boundary?
• Which functions, records, data, and interfaces are critical?
• What can fail?
• How could failure affect patient safety, product quality, or data integrity?
• Which controls prevent or detect those failures?
• What supplier evidence is credible and applicable?
• What must the regulated organization verify directly?
• How is the approved configuration identified?
• What evidence supports release?
• How will changes be assessed?
• How will continued control be reviewed?
• How will records and responsibilities be managed at retirement?

GAMP 5 provides the framework for answering these questions. The validated state depends on how effectively the organization applies that framework to the actual system, process, configuration, data, users, suppliers, and operating environment.