GAMP 5 software validation, explained: from URS to validation summary report

What GAMP 5 is — and isn’t

GAMP stands for Good Automated Manufacturing Practice. GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems is published by ISPE, the International Society for Pharmaceutical Engineering. The first edition came out in 2008; the second edition, published in 2022, updated it for agile development, cloud services and a stronger focus on critical thinking.

GAMP 5 is guidance, not law. Regulations such as 21 CFR Part 11 in the US and EU Annex 11 say computerised systems must be validated; GAMP 5 is the widely recognised way of doing it. Regulators and auditors know it, which is why following it makes inspections smoother.

Its core principles are simple:

• Product and process understanding — know what the system does and why it matters.
• A life-cycle approach — from concept to retirement, not only a test phase before go-live.
• Scalable, risk-based effort — focus on what can affect patient safety, product quality and data integrity.
• Leveraging supplier work — reuse a good supplier’s testing and documentation instead of repeating it.

The software categories decide the effort

GAMP 5 sorts software into categories. The higher the category, the more of the system is unique to you — and the more you have to specify and test yourself.

There is no Category 2: it covered firmware in earlier versions and was removed in GAMP 5. Most real systems mix categories — a configured LIMS (4) with a custom instrument integration (5) running on a validated database (1). Each part gets the treatment its category needs.

The V-model and the documents that matter

GAMP 5 describes validation with a V-model. The left side of the V is specification, going from “what we need” to “how it’s built”. The right side is verification, proving each level on the left was met.

Planning

• Validation plan (VP) — scope, approach, roles, deliverables and acceptance criteria.
• Supplier assessment — how far you can rely on the vendor’s quality system and testing.

Specification (left side)

• User requirements specification (URS) — what the business needs, in testable statements.
• Functional specification (FS) — how the system will meet each requirement.
• Design or configuration specification (DS/CS) — the technical build, or the exact configuration of a product.

Verification (right side)

• Installation qualification (IQ) — it is installed correctly, in the right environment, at the right versions.
• Operational qualification (OQ) — each function works as specified, including edge cases and error handling.
• Performance qualification (PQ) — it works for your real process, with real users and realistic data.

Closing

• Traceability matrix (RTM) — links every requirement to its risk, specification and tests.
• Validation summary report (VSR) — what was done, deviations and how they were resolved, and the release decision.

Risk assessment: test more where it matters

Risk assessment is what turns validation from “test everything the same way” into focused, defensible work. A practical approach:

1. List the system’s functions from the URS.
2. For each, ask whether it can affect patient safety, product quality or data integrity. A function that calculates an assay result is critical; one that changes the colour of a dashboard is not.
3. For critical functions, rate the severity of a failure, how likely it is, and how likely it is to be detected before it causes harm — the familiar FMEA-style method.
4. Decide the controls and the depth of testing for each risk level.

High-risk functions get detailed, scripted tests with documented evidence. Low-risk functions can rely on supplier testing or lighter, unscripted checks. This is the same thinking behind the FDA’s Computer Software Assurance (CSA) approach, first published as draft guidance in 2022. It was written for medical-device production and quality-system software, but its message — use critical thinking, and don’t generate evidence that adds no assurance — is shaping validation practice across life sciences.

Validating software that is built in sprints

Custom (Category 5) software is rarely built in one waterfall pass today. GAMP 5’s second edition explicitly supports agile delivery, as long as control is kept. What works in practice:

• Treat the URS as a controlled, living backlog — each user story traces to a requirement ID.
• Define “done” to include updated specifications and passing tests, not only working code.
• Use automated tests as validation evidence where they cover a requirement, with results kept as records.
• Run formal verification on a release candidate in a controlled environment, then release under change control.

Done this way, validation evidence builds up sprint by sprint instead of arriving as a three-month documentation project at the end.

Common validation mistakes

• Writing the URS after the system is built — requirements copied from the finished screens prove nothing.
• Testing everything equally — hundreds of screenshots of low-risk screens, and thin tests on the calculations that matter.
• Untestable requirements — “the system shall be user-friendly” can’t be verified. “A reviewer can approve a result in no more than three clicks” can.
• No traceability — without a matrix, nobody can show that every requirement was tested.
• Validate once, then forget — patches, configuration changes and new integrations go live without impact assessment.
• Ignoring data integrity — the audit trail, access control and backup/restore are functions too, and need testing like any other. See our Part 11 checklist.

After go-live: staying validated

A system is only validated as long as it stays under control. The operational phase needs:

• Change control — every change assessed for impact, tested as needed and approved before release.
• Incident and problem management — failures recorded, investigated and fixed.
• Periodic review — a scheduled check that the system is still fit for use and still compliant.
• Backup, restore and business continuity — tested, not assumed.
• Retirement — a plan to migrate or archive records so they stay readable for the retention period.

At Bright Infonet we build LIMS, drug-safety and other GxP platforms with the validation pack produced alongside the code: URS, risk assessment, specifications, IQ/OQ/PQ scripts, traceability matrix and summary report. If you are planning a regulated build or need to bring an existing system into a validated state, tell us about it.