Software Validation GxP | GAMP 5 Category 5

Our services for GAMP 5 Category 5 validation

From validation plan to authority inspection: structured along GAMP 5 and your SDLC – with evidence QA and auditors can rely on.

Complete document package

VP, URS, FS, DS, TM, test protocols (IQ/OQ/PQ) and validation report – structured for audit and release.

Risk-based test planning

Risk classification and FMEA-based test depth planning per GAMP 5 (2nd Edition).

Code reviews & coding standards

GxP-compliant reviews, coding guidelines and traceable sign-off of implementation.

Traceability matrix

Setup and ongoing maintenance of the TM – requirements, design and test evidence linked end to end.

Change control in operation

Support for formal changes after system release including impact assessment and re-test.

Re-validation

Re-validation for major changes – without losing the validated operational state.

Inspection readiness

Preparation for FDA and authority inspections with structured, reliable evidence.

Training & enablement

Training for your developers and validation staff for sustainable GxP operation.

Clarify scope?

Book an intro call

Category 5 guide

Where is your custom software?

Choose the starting point for GAMP 5 category 5 software with full SDLC evidence.

Validate custom software from the start

Specification, code, tests and release grow in one SDLC – ideally with our software development.

Discuss project Contact us

Our approach in GxP projects: from planning through release – each step delivers evidence you can present in QA review and audit. View GxP consulting in five steps

GAMP 5: What Does Category 5 Mean?

The Good Automated Manufacturing Practice (GAMP 5) framework from ISPE classifies software into four categories based on their risk level and validation effort. Category 5 covers bespoke software: individually developed or heavily customised systems created specifically for the GxP environment in question.

Typical examples of GAMP 5 Category 5 include: internally developed LIMS, custom reporting and analysis tools, GxP data migration software, individual laboratory automation applications and data converters for regulated systems.

Category	Description	Examples	Validation Effort
Cat. 1	Infrastructure Software	Operating systems, middleware, databases	Minimal
Cat. 3	Non-configurable COTS	Standard office software	Low
Cat. 4	Configurable COTS	ERP, LIMS (standard), EDMS	Medium
Cat. 5	Bespoke / individually developed	Custom developments, heavily customised systems, data migration tools	Comprehensive: full SDLC

Important: GAMP 5 (2nd edition, 2022) explicitly emphasises the risk-based approach. Not every function of a Category 5 software needs to be validated with equal effort: the focus is on functions with direct impact on product quality or patient safety.

The Software Lifecycle per V-Model

For GAMP 5 Category 5, the Software Development Life Cycle (SDLC) per V-model is the regulatorily recognised standard. Each specification level on the left side is verified by a corresponding test level on the right.

Specification 1

User Requirements Specification (URS)

What must the system do? Describes all requirements from the user's perspective: functional, regulatory, safety-relevant.

Test 1

Performance Qualification (PQ)

Verifies fulfilment of user requirements under real operating conditions: the "acceptance test" from the customer's perspective.

Specification 2

Functional Specification (FS)

How does the system behave? Defines system behaviour, process flows, interfaces and data flows.

Test 2

Operational Qualification (OQ)

Verifies all functional requirements of the FS, including limits, error cases and edge cases.

Specification 3

Design Specification (DS)

How is the system built? Describes architecture, database structure, algorithms and technical implementation.

Test 3

Installation Qualification (IQ)

Confirms correct installation and configuration per Design Specification and manufacturer specifications.

Specification 4

Code & Review

Implementation per coding standards, code review and unit tests. Full version control and change tracking.

Test 4

Unit & Integration Tests

Automated or manual tests at module and system level, documented and traceable to the DS.

Document Package for GAMP 5 Category 5

GAMP 5 Category 5 requires a complete CSV framework across the software lifecycle – but not the same level of detail for every artefact. Instead of a rigid mandatory list: complete chain of evidence, risk-based depth. GAMP 5 (2022) and the FDA CSA approach emphasise critical thinking – less paperwork where risk allows, full depth for patient safety and data integrity.

We group the package into four logical blocks: the core provides the audit-ready frame, specification and qualification follow the V-model, and SDLC evidence demonstrates controlled development. For targeted ways to cut test planning and protocol effort without losing evidence depth, see Cutting Validation Costs with CSA & AI.

Group 1

Core – validation framework

Always required

Planning, risk, traceability and closure – without this core, a Category 5 validation is not audit-ready.

Validation Plan

VP: Scope, roles, strategy, risk approach

Risk Analysis

FMEA / risk assessment – rationale for test depth

Traceability

TM: URS → FS → DS → test – content practically mandatory

Validation Report

VR: Summary, deviations, system release

Group 2

Specification – V-model left side

Scope by system

The specification hierarchy describes intended use, behaviour and technical implementation – the basis for design, development and testing.

User Requirements Spec.

URS: Requirements from user perspective

Functional Specification

FS: System behaviour & functions

Design Specification

DS: Architecture, modules, interfaces

Group 3

Qualification – IQ / OQ / PQ

Risk-based depth

Test plans and test protocols at system level – scope and level of detail follow the risk analysis, not blanket full coverage of every helper function.

IQ Protocol

Installation, environment, configuration baseline

OQ Protocol

Functional verification of FS – test plan & protocol where needed

PQ Protocol

Acceptance under real operating conditions / URS

Group 4

SDLC evidence – controlled development

Cat. 5 · required

What distinguishes Category 5 from configuration: evidence that source code was developed, reviewed and tested under control – in addition to IQ/OQ/PQ, not instead of it.

Code review records

Peer review, findings, implementation release

Unit & integration tests

Developer evidence, traceable to DS

Version control & build

CM: branch, tag, reproducible release artefacts

Note: Not every document needs the same depth. GAMP 5 (2022) expects a complete chain of evidence and justified test depth – not checklist-style equal treatment of every function. OQ test protocols and developer tests complement each other; we deliberately avoid duplicate coverage.

Traceability Matrix: the Backbone of Validation

In the core framework above, the Traceability Matrix links every URS requirement seamlessly with the functional specification, design and test protocols. Traceability content is practically indispensable – the TM is the established, audit-ready tool for delivering it.

At cube one, we maintain the Traceability Matrix as a living document: it is updated with every change control and thus remains permanently valid.

Risk-Based Test Depth per GAMP 5 (2nd Edition 2022)

The 2022 updated GAMP 5 2nd Edition further strengthens the risk-based approach: the intensity of test documentation is guided by the critical impact on product quality and patient safety. Not every function needs to be tested and documented with equal effort.

Low GxP impact High GxP impact · maximum test depth

Low risk

Auxiliary functions and UI elements without GxP relevance: simplified tests, reduced documentation – justified by critical thinking.

Test depth · reduced
Medium risk

Configuration, reporting, user management: appropriate tests and documentation proportional to risk.

Test depth · medium
High risk

Functions with direct GxP impact (audit trail, ERES, batch release): full test documentation, triple review.

Test depth · maximum

GAMP 5 (2022) core principle

Critical thinking

GAMP 5 calls for structured critical thinking rather than blindly following checklists – the foundation for every risk tier above.

Test planning and protocols: secure the minimum, cut the effort

For GAMP 5 Category 5, teams often ask: how formal must test plans be, and how detailed the test protocols? This refers to qualification documentation in IQ, OQ and PQ – the test plan defines what is checked; the test protocol records execution and results. Not the application source code itself, which is covered by the SDLC, code reviews and developer testing. The key is risk-based critical thinking: the same audit readiness, less paperwork where the risk allows it.

Typical flow: First the approved test plan (test cases, inputs, expected results, pass/fail criteria), then execution in the test protocol (actual result, tester, date, environment). Assess automated regression and GxP-relevant helper programs (ETL, batch, reporting) separately – not everything needs the same depth.

Audit-ready minimum

What you cannot skip

Risk rationale in the VP/VMP: formal test plan vs. focused testing with protocol – documented and approved
Traceability to the requirement (URS/FS), even for short test cases
Test logic in the plan: input, expected result, unambiguous pass/fail criteria
Approved version of test plan and protocol template (version control / change control)
Test protocol with actual result, tester, date and test environment
Deviation path on fail (deviation, impact, CAPA if needed) – defined before execution

Lean in practice

How to reduce effort

Only GxP-critical functions with full test plan and detailed protocol; helper UI with lean plan and execution record
CSA / critical thinking: shorter test plans when risk is low and evidence exists elsewhere
Reusable test libraries and parameterised data instead of hundreds of one-off test plans
Automation with an approved baseline run – manual repetition drops away
Developer evidence (unit/integration) used sensibly, not duplicated in OQ
Templates and test design standards – consistent structure, faster reviews
Impact-based re-testing after changes instead of blanket full regression

Test depth scales with risk – not “document everything to the max” by default

Lean plan + protocol
(low risk) Hybrid / focused
(medium risk) Full test plan + formal protocol
(data integrity, release, audit trail)

FAQ: Software Validation per GAMP 5 Category 5

What distinguishes GAMP 5 Category 4 from Category 5?

Category 4 covers configurable COTS software (e.g. standard LIMS, ERP), where only the configuration is validated. Category 5 applies to software specifically developed for the customer or so heavily customised that the source code is changed. Here, a complete SDLC with source code review and comprehensive specification hierarchy is required.

Must every function of a Category 5 software be validated with equal effort?

No. GAMP 5 (2nd edition 2022) explicitly emphasises the risk-based approach. Functions with direct impact on product quality or patient safety require more comprehensive tests and documentation than GxP-non-critical auxiliary functions. The key is a traceable, documented risk classification.

How is agile development reconciled with GAMP 5 Category 5?

Agile methods are compatible with GAMP 5 but require structured adaptations: user stories must be traceable to URS requirements, test automation and sprint-closing test protocols replace classical phase documents. GAMP 5 (2022) explicitly supports agile approaches when critical thinking and traceability are ensured.

What happens after release: change control and periodic review?

After system release, every change to software or configuration must go through a formal change control process: impact assessment, risk evaluation, approval, implementation, testing and documentation update. Additionally, GAMP 5 recommends regular periodic reviews, typically annually, to confirm the ongoing validity of the system.

Is the Traceability Matrix mandatory?

It is not explicitly prescribed in every regulatory text, but is considered best-practice standard and is routinely requested by FDA and EMA inspectors. Without complete traceability from requirements to test evidence, a positive audit result is barely achievable. cube one recommends the TM as a central mandatory document for every Category 5 validation.

Does every OQ test need a formal test plan?

No. GAMP 5 (2022) and the CSA approach allow focused testing with an execution protocol when risk is low. For functions with direct impact on product quality, data integrity or patient safety – such as releases, calculations or audit trail – a full test plan and formal test protocol remain the standard. What matters is the documented risk rationale in the validation plan, not a blanket requirement for maximum test planning effort.

Software Validation in the GxP Environment per GAMP 5 Category 5