GAMP 5

This topic is part of the SG Systems Global regulatory & operations guide library.

GAMP 5: risk-based validation that proves intended use, protects electronic records, and scales to real operations.

Updated Jan 2026 • gamp 5, csv, risk-based testing, supplier involvement, lifecycle validation, part 11, annex 11 • Cross-industry

GAMP 5 (Good Automated Manufacturing Practice, 5th edition) is the most commonly used industry framework for applying risk-based thinking to computer system validation (CSV). In plain terms, it is how regulated organizations prove a computerized system is fit for its intended use without wasting months “testing everything,” and how they maintain evidence that holds up during audits, investigations, deviations, and product quality events.

GAMP 5 matters because modern manufacturing runs on software. A master recipe is a configuration object. A “report” can drive a release decision. A workflow determines whether an exception is captured or silently bypassed. An access role can decide whether a person can self-approve. If those controls are weak—or if they change without change control—you don’t just risk downtime. You risk producing untrustworthy product decisions and untrustworthy records.

That is why GAMP 5 is inseparable from data integrity. The core promise of a validated system is not “the system never fails.” The promise is: when the system is used as intended, it produces reliable results and reliable evidence—supported by audit trails, controlled access, and defensible, reviewable records.

“Validation is not about proving software is perfect. It’s about proving your use of the software is controlled.”

1) What GAMP 5 actually means

At its core, GAMP 5 is a practical answer to a practical problem: computerized systems are too complex to validate by brute force. The right question is not “did we test every feature?” The right question is “did we test what we rely on, and did we prove the controls that protect quality and evidence?”

GAMP 5 reframes validation as a lifecycle discipline. Validation is not a one-time event at go-live. It begins when you define requirements and continues through configuration, testing, release, operation, and eventual retirement. That is why it pairs naturally with a Validation Master Plan (VMP): you need a defined strategy and scaling rules, not a stack of disconnected protocols and approvals.

It also treats software differently based on what it is. A standard infrastructure component is not validated the same way as a highly configured MES workflow, and neither is validated the same way as custom application code. This is the “scale effort to risk and complexity” principle, applied explicitly.

Finally, it recognizes that you rarely build everything yourself. Vendors and integrators matter. GAMP 5 encourages you to leverage supplier documentation and tests where appropriate—while making sure you still retain responsibility for intended use, risk decisions, and acceptance of the system in your environment.

2) Why GAMP 5 is non-negotiable

GAMP 5 is not popular because it is academic. It is popular because it aligns with how regulated work actually happens: systems change, integrations drift, people improvise, and evidence is scrutinized after the fact. A system can “work” operationally and still fail regulatory reality because its records are incomplete, not attributable, or not reconstructable.

Four forcing functions make a GAMP-style approach unavoidable:

Without a risk-based framework, teams usually choose one of two bad extremes: either a massive validation package that takes forever and still misses critical control paths, or a minimal package that looks fine on paper but collapses under investigation. GAMP 5 is how you avoid both extremes.

3) GAMP 5 vs CSV vs Part 11 / Annex 11

These terms get mixed up, and that confusion wastes time. Here’s a practical map:

GAMP 5 is not a regulation. It is a method that helps you satisfy regulatory expectations. You can do CSV without calling it GAMP, but if you ignore the risk-based principles, you will almost certainly end up either over-testing or under-controlling.

4) Core principles that drive the approach

GAMP 5 can be summarized into a few operating principles. When teams “get GAMP right,” they are usually doing these things consistently:

• Intended use first: define what the system is supposed to do, in your process, with your users. The URS is not marketing; it is the baseline for validation.
• Risk-based thinking: evaluate what can go wrong and where it matters; focus verification on high-impact failure modes.
• Lifecycle control: validation begins before go-live and continues through operation and retirement.
• Leverage suppliers: use vendor documentation and testing evidence, but verify what matters in your configured use.
• Traceability: show clear links from requirements to tests to results. If a requirement has no test, it is not proven. If a test has no requirement, it is noise.
• Quality system integration: connect validation to document control, revision control, and change control.

5) System categorization and what it changes

One of the most practical GAMP ideas is that you do not validate all software the same way. The “category” helps you decide how much specification and testing is appropriate, and where supplier evidence can be leveraged most.

A simple way to communicate categorization is a table of system types, examples, and typical validation posture:

Categorization is not about gaming rigor. It is about using the right evidence. For a configured system, your biggest risk is often configuration drift and misunderstood workflow behavior. For custom code, your biggest risk is hidden defects and uncontrolled changes. For infrastructure, your biggest risk is availability, security, and recoverability. The validation posture should match that reality.

6) Lifecycle deliverables and traceability

A common failure mode is to treat validation deliverables as a template checklist rather than a coherent story. GAMP 5 encourages a simple narrative: we defined what we need, we designed/configured to meet it, we tested what matters, and we control change so it stays true.

In practice, the lifecycle is supported by a small set of key artifacts. Your organization may name them differently, but the intent is consistent:

• VMP / validation strategy: high-level approach, roles, and scaling rules (VMP).
• URS: intended use and high-level requirements (URS).
• Risk assessment: what can fail and what matters; often summarized with a risk matrix.
• Configuration/design specification: how the system will be set up to meet requirements, including access model, workflows, and key calculations.
• Test strategy: what tests exist, why, and acceptance criteria; includes regression scope for future changes.
• Execution evidence: test records, deviations, resolutions, and approvals with clear accountability.
• Release and operational control: go-live decision, training evidence, SOPs for operation, backup/restore, and support.

Qualification language often helps structure evidence. Many teams align checks to IQ (installed correctly) and OQ (operates as intended), and then validate intended use with UAT or process-focused tests. The naming is less important than the intent: prove correct build, prove correct function, and prove correct use in your process.

Traceability is the glue. A practical traceability matrix does not have to be complicated. It must simply allow someone to follow: URS requirement → design/configuration element → test case → result → any deviations and their resolution. If you cannot trace, you cannot prove.

7) Risk-based testing: what to test and why

Risk-based testing is where GAMP 5 saves time and improves quality. The goal is not fewer tests. The goal is the right tests: those that prove the system controls the process and protects evidence.

A practical strategy focuses on “control paths.” Control paths are the workflows that, if wrong, would create bad product or bad records. Examples include: release decisions, exception handling, critical calculations, security role enforcement, and audit trail capture.

To make “risk-based” real (instead of a slogan), tie the assessment to the process. Start with the regulated decisions the system supports: release, hold, disposition, calculations, and the creation or modification of controlled records. Then ask three blunt questions: (1) if this fails, what is the impact to product quality or patient/customer safety, (2) would we detect the failure before product leaves control, and (3) can we reconstruct what happened from the system’s records alone? The answers drive test depth far better than guessing based on module names.

When teams struggle, it is usually because the risk assessment is disconnected from evidence controls. A simple control-objective table keeps it grounded and makes it obvious which tests you must not skip:

The detail expands with risk. If the system creates electronic batch records (EBR) or device records like eDHR, you must test the record lifecycle and review workflow, not just “data entry.” If the system supports disposition, you must test the disposition controls. If a report is used for release or compliance decisions, you must test report logic, filters, and change controls (including who can edit parameters and how edits are tracked).

8) Supplier involvement without losing control

Supplier involvement is a GAMP 5 strength, but it is also a common misinterpretation. Leveraging supplier evidence does not mean outsourcing responsibility. Your organization remains accountable for intended use, configuration decisions, and acceptance of the system in your regulated context.

Practical supplier leverage includes:

• Supplier assessment: evaluate the vendor’s development and quality practices; scale depth to risk.
• Documentation use: use vendor specs, release notes, and test summaries as supporting evidence.
• Supplier testing: leverage factory testing where applicable; don’t re-run identical low-risk tests.
• Contract clarity: define responsibilities for defects, support, security, and notice of changes.

Supplier evidence becomes especially important for SaaS and hosted systems, where you may not control the underlying infrastructure. In those cases, the right control is usually: supplier qualification + contractual commitments + your own intended-use verification + strong change communication pathways. If the vendor can update production without your knowledge, your validated state is not stable.

9) Managing patches, upgrades, and configuration drift

Validation is not finished at go-live. Real life includes patches, security fixes, workflow tweaks, new reports, and integration changes. A GAMP 5 program survives reality by treating change as part of the lifecycle, not as an exception.

Three controls keep validated state stable:

• Change control: changes are assessed, approved, tested, and documented before implementation.
• Revision control: baselines of configuration, scripts, and key specifications are versioned and retrievable.
• Regression strategy: every change has defined regression scope; “we didn’t think it would affect that” is not a defense.

A simple rule set helps: if a change touches regulated workflow, critical calculations, access roles, audit trail settings, interfaces, or reporting used for release, treat it as revalidation-triggering. If it is purely cosmetic or non-GxP, document rationale and limit testing accordingly based on risk.

For systems like MES and connected operations, patching and cybersecurity updates are necessary. But a patching program without validation discipline becomes a churn machine: updates go live, unexpected regressions appear, and the floor loses trust. A mature program links patching to risk-based regression, integrates with environment management, and keeps an evidence pack that can be shown quickly during audits.

10) Data integrity, audit trails, and e-signatures

Risk-based validation fails if it ignores evidence controls. In regulated environments, the system’s primary “product” may be the record. That is why GAMP 5 validation should explicitly check data integrity attributes and electronic records controls.

High-value integrity checks include:

• Attribution: actions are linked to unique users; shared accounts are prohibited or tightly controlled.
• Audit trail completeness: the system records critical create/modify/delete events and can produce them on demand (audit trails).
• Time controls: timestamps are consistent and protected; time changes are controlled and logged.
• Signature meaning: electronic signatures bind to actions and retain meaning over time.
• Record retention and retrieval: records remain accessible and readable for required retention periods.
• Data export integrity: exported data is complete and not selectively filtered without traceability.

These controls support expectations commonly associated with 21 CFR Part 11 and Annex 11, but the point is larger than compliance. The point is: when something goes wrong, you can reconstruct truth without relying on memory or informal spreadsheets.

Most organizations also anchor integrity thinking in principles like ALCOA. If the system undermines “attributable,” “contemporaneous,” or “original,” it may be operational and still not defensible.

11) Agile, cloud, SaaS, and modern delivery models

GAMP 5 is sometimes mischaracterized as “waterfall validation.” That is a misunderstanding. The framework is compatible with agile and modern delivery if you keep the principles intact: defined requirements, risk-based testing, controlled releases, and traceable evidence.

Practical adaptations that work:

• Iterative URS: define intended use early and refine with controlled revisions; keep the baseline under revision control.
• Continuous testing evidence: use automated test evidence where it is reliable, but ensure it is reviewable and linked to requirements.
• Release-based validation: treat each release as a controlled change; run risk-based regression before promotion.
• Cloud responsibility mapping: define what the vendor controls vs what you control; validate the parts you rely on.

For low-code tools and spreadsheets, the risk is not the technology—it is the absence of controls. A spreadsheet used to calculate release results is a regulated system in practice, even if IT never approved it. Apply the same GAMP logic: intended use, risk assessment, version control, access controls, and verification of formulas. If you cannot control it, you should not rely on it for decisions.

12) Interfaces and integration risks

Interfaces are where validated systems often fail quietly. The core application may be validated, but the integration layer duplicates transactions, drops messages, or reorders events in ways that corrupt truth. In connected operations, the interface is part of the validated function.

Common high-risk integrations include:

• ERP: orders, confirmations, inventory movements, batch status, and financial postings.
• LIMS: results, specifications, COA links, and disposition drivers.
• eQMS: deviations, investigations, approvals, CAPA tasks, and change workflows.
• MES and shop floor connectivity: integration gateways, PLC links, and message brokers that drive execution behavior.

Interface validation should explicitly test: duplicate protection (idempotency), sequencing and timing assumptions, reconciliation counts across systems, and auditability of interface actions. If you can’t reconcile, you can’t prove record completeness.

13) Retirement, migration, and retention

GAMP 5 is lifecycle validation, which includes the end of life. Decommissioning is a high-risk event because it often breaks record access. If you retire a system and later cannot retrieve records for an investigation, you have created a compliance failure after the fact.

Decommissioning should be governed like a change: define what records must be retained, how they will be accessed, and how you will prove completeness. This connects to data archiving and data retention practices. The right outcome is not “the old system is off.” The right outcome is “records remain accessible, readable, and traceable for the full retention period, with the same meaning they had when created.”

For migrations, treat data mapping and transformation as part of the validated scope. Migration is not just copying tables; it is preserving meaning. If a record changes form, you must show that meaning and auditability were preserved, and that the migration itself was controlled through change governance.

14) KPIs and operating cadence

A GAMP 5 program should be measurable. If it is not measurable, it tends to drift into either bureaucracy or neglect. A small KPI set helps keep the program honest.

Cadence matters. High-change environments should review validation health more frequently than stable environments. The point is to detect when validation is not keeping up with reality—because reality will not wait for your next annual review.

15) The GAMP 5 “block test” checklist

If you want a fast, ruthless check on whether your program is real, use a block test. It focuses on the behaviors that cause most validation failures: uncontrolled change, weak traceability, and ignored evidence controls.

If this checklist fails, treat it as a governance failure. Validation is a control. Controls that don’t operate as intended are quality issues.

16) Common failure patterns

• Testing the UI instead of the controls: hundreds of screen checks, but no audit trail or role tests.
• URS written after configuration: requirements become a justification document, not a baseline.
• Supplier evidence is ignored: teams re-test low-risk functions and run out of time for high-risk ones.
• Supplier evidence is worshiped: teams accept vendor testing without verifying intended use and configuration.
• Change control is weak: “small tweaks” accumulate until the validated baseline is fiction.
• Interfaces are treated as IT plumbing: integration failures corrupt records and reconciliation.
• Retirement is unmanaged: systems are turned off and record access disappears.

17) Cross-industry examples

GAMP 5 is used wherever software contributes to regulated evidence. The details vary, but the control intent is stable: prove intended use and protect record integrity.

• Pharmaceutical manufacturing: MES/EBR and lab systems must preserve audit trails and release evidence; validation must survive frequent change and investigations (see GMP and ICH Q10 context).
• Medical devices: production and quality systems support traceability across lifecycle artifacts like DMR and DHR; changes intersect with DHF and quality system controls such as ISO 13485 practices and risk management alignment.
• Food and consumer products: high-volume operations need fast changes; risk-based validation prevents “speed” from turning into uncontrolled drift (see HACCP style thinking where applicable).
• Highly automated plants: integration layers and execution logic must be validated as part of intended use, not as an afterthought; that includes data flows that drive decisions and hold/release status.

The shared lesson: a validated system is only as trustworthy as the controls around it—especially change control and evidence integrity.

18) Extended FAQ

Q1. What is GAMP 5?
GAMP 5 is a risk-based framework for validating computerized systems across their lifecycle, commonly used to execute CSV efficiently and defensibly.

Q2. Is GAMP 5 a regulation?
No. It is industry guidance. Regulators expect validated systems; GAMP 5 is a practical method many organizations use to meet those expectations with risk-based rigor.

Q3. What does “risk-based” mean in validation?
It means you focus your specification and testing on functions whose failure could harm product quality, patient/customer safety, or record integrity. Low-risk functions get lighter evidence; high-risk functions get deeper testing and review.

Q4. Do we need to test every feature?
No. You need to test what supports intended use and what protects evidence. Over-testing low-risk features often causes teams to under-test the actual control paths.

Q5. Can we rely on vendor testing?
You can leverage supplier evidence, but you still must verify your intended use, your configuration, and your risk controls—especially around audit trails, security, and interfaces.

Q6. How does GAMP 5 relate to Part 11 and Annex 11?
GAMP 5 is a validation method; Part 11 and Annex 11 are electronic records expectations. A strong GAMP 5 approach includes verifying audit trails, access controls, e-signatures, and record retention to protect trust in electronic evidence.

Q7. What is the biggest GAMP 5 failure mode?
Treating validation as a document set instead of a control. If change control is weak, configuration drifts, and evidence controls are not tested, the “validated state” becomes fiction.

Related Reading
• Validation Core: CSV | VMP | URS | IQ | OQ | UAT
• Governance: Change Control | MOC | Document Control | Revision Control
• Integrity + Evidence: Data Integrity | ALCOA | Audit Trail (GxP) | Electronic Signatures
• Electronic Records Context: 21 CFR Part 11 | Annex 11 | Predicate Rule
• Systems Context: MES | EBR | LIMS | eQMS