GAMP 5 Categories Explained

What Is GAMP 5?

GAMP — Good Automated Manufacturing Practice — is an ISPE guidance framework for achieving compliant GxP computerised systems. GAMP 5 (Second Edition) is the current industry reference for risk-based validation of software used in regulated manufacturing, laboratory, clinical, and distribution environments.

GAMP is a framework, not a regulation. It does not replace EU GMP Annex 11, 21 CFR Part 11, or FDA validation guidance — it helps teams interpret those expectations into scalable lifecycle activities. Industry adoption is broad because GAMP translates regulatory principles into practical planning: what to validate, how deeply, and where supplier documentation can be leveraged.

The purpose of GAMP, as stated in the guidance, is to ensure computerised systems are fit for intended use, compliant with applicable regulations (GMP, GCP, GLP, GDP, and medical device requirements where relevant), and protective of patient safety, product quality, and data integrity — while also delivering business benefit. That dual aim — compliance and efficiency — is why categorisation and risk-based scaling exist.

Why Software Categorisation Matters

Not all software carries the same GxP risk. An operating system patch and a custom batch release algorithm do not warrant identical validation depth. Not all software requires the same documentation volume, test rigour, or supplier scrutiny.

GAMP categorisation helps determine testing effort, supplier leverage, documentation depth, and verification activities before a validation plan is drafted. A Category 1 database engine may need installation verification and version control; a Category 5 custom integration may need full design review, structural testing, and source code review.

This is scalable validation — aligning effort with system impact, complexity, novelty, and supplier capability. GAMP's planning stage explicitly states activities should be scaled according to risk assessment (impact on patient safety, product quality, and data integrity), system complexity and novelty (architecture and categorisation), and supplier assessment outcomes.

The GAMP 5 Lifecycle Approach

GAMP organises validation within a quality management system across four lifecycle phases. Categorisation influences how deeply each phase is executed — but the lifecycle structure applies to every system regardless of category.

Concept

The concept phase establishes why a system is needed before project work begins: strategic planning, need identification, business justification, compliance justification, migration need, technical feasibility, management commitment, user requirement initiation, and project initiation.

At concept, categorisation thinking starts early — is the proposed solution likely to be configured COTS (Category 4) or custom-built (Category 5)? That decision shapes budget, timeline, and supplier strategy before specifications are written.

Project

The project phase delivers the validated system through four stages: Planning; Specification, Configuration, and Coding; Verification; and Reporting and Release.

Planning requires a clear understanding of user requirements and scales activities by risk, complexity, and supplier capability. Specification enables development and verification against the user's risk profile. Configuration and coding follow controlled, repeatable processes with configuration management as an intrinsic discipline.

Verification confirms specifications are met through design reviews and testing — with test strategy based on risk, complexity, and novelty. Supplier documentation should be assessed and used where suitable. Reporting and Release produces a validation summary, documents deviations and corrective actions, and obtains approval from process owner, system owner, and quality representatives before operational handover.

Operation

Operation maintains validated state through change management, configuration management, periodic review, incident handling, and continued risk assessment. Category influences ongoing burden: Category 4 systems require robust configuration control because business process changes re-open validation scope; Category 5 custom code changes trigger full regression analysis.

Well-managed handover from project to operations is a prerequisite for maintaining compliance — a principle that applies whether the system is Category 3 firmware or a Category 4 MES.

Retirement

Retirement is the controlled decommissioning of a system — preserving records for retention periods, migrating data where required, assessing impact on dependent systems, and documenting that GxP activities can continue without the retired system. Retirement planning should begin during operation, not when hardware fails.

Supporting Processes Inside GAMP 5

GAMP embeds supporting processes throughout the lifecycle — not as optional extras but as the mechanisms that make validation defensible.

Risk management scales activities to patient safety, product quality, and data integrity impact. Change and configuration management ensure modifications are assessed, approved, and verified before affecting GxP state. Design reviews evaluate whether lifecycle outputs meet requirements before proceeding — especially critical before design commitment.

Document control maintains approved versions of specifications, protocols, and reports. Traceability links requirements through design to verification evidence — the same principle GXPLearn Module 10 practises across the V-model.

These processes support validation because they answer auditor questions: How did you know the change was safe? Who approved it? What evidence proves the system still works? Without them, categorisation alone cannot defend fitness for intended use.

Overview of GAMP 5 Software Categories

GAMP 5 defines four primary software categories used in modern validation discussions: Category 1 (Infrastructure), Category 3 (Non-Configured Products), Category 4 (Configured Products), and Category 5 (Custom Applications). Category 2 (firmware treated as a distinct class in earlier editions) is generally subsumed into Category 3 in contemporary practice — firmware-based applications are assessed as non-configured products with abbreviated lifecycle approaches.

Categorisation is per software component, not per entire site. A manufacturing execution environment may include Category 1 operating systems, Category 4 MES application software, and Category 5 custom integrations — each with proportionate validation effort.

Category 1: Infrastructure Software

Category 1 covers established or commercially available layered software and infrastructure tools: operating systems, database engines, middleware, programming languages, statistical packages, spreadsheet applications, network monitoring tools, scheduling tools, and version control tools.

The typical GAMP approach is proportionate: record the version number and verify correct installation by following approved installation procedures. Supplier reliance is high — the regulated company does not re-validate the operating system kernel, but does confirm the installed baseline matches approved specifications.

Version control and change management remain essential. An OS or database upgrade can invalidate application-layer validation if interfaces, drivers, or security settings change. Category 1 components appear in every computerised system and must be included in the validation boundary — especially network architecture, which GAMP and Annex 11 both treat as part of the validated system scope.

Category 3: Non-Configured Products

Category 3 covers commercial off-the-shelf (COTS) software that cannot be configured to suit business processes, or is configurable but only the default configuration is used. Run-time parameters may be entered and stored, but the software behaviour is essentially fixed.

Examples include firmware-based applications, standard instrument software, and COTS products used without meaningful business configuration. GAMP recommends an abbreviated lifecycle: user requirements specification (URS), risk-based supplier assessment, recording version numbers, installation verification, and risk-based testing against requirements as dictated by use.

Procedures for maintaining compliance and fitness for intended use during operation are still required. A Category 3 balance or chromatography data system may appear low-complexity, but if it generates GMP release data, data integrity controls — audit trails, access control, backup — remain in scope regardless of category.

Category 4: Configured Products

Category 4 is where most pharmaceutical manufacturing systems live — complex commercial software configured to meet specific business processes without altering supplier source code. GAMP examples include LIMS, data acquisition systems, SCADA, ERP, MES, DCS, EDMS, BMS, clinical trial monitoring, ADR reporting, CRM, and simple HMIs.

In biopharma manufacturing, a DCS such as DeltaV-style batch automation is archetypal Category 4: the supplier provides standard phase logic, recipe structures, and control modules; the site configures unit procedures, equipment modules, recipes, and alarms for products like MAb-A on BR-201. ISA-88 recipe hierarchy, batch executive orchestration, and electronic batch records are configured — not custom-coded — but the validation scope is substantial because business process configuration directly affects product quality.

GAMP's Category 4 approach includes: full lifecycle execution; risk-based supplier assessment with demonstration that the supplier has an adequate quality management system; retention of some lifecycle documentation at the supplier (for example design specifications); installation verification; risk-based testing demonstrating the application works as designed in a test environment; and risk-based testing demonstrating the application works within the business process.

Configuration management is critical. Recipe parameter changes, alarm limit edits, role permission updates, and MES workflow changes are configuration events — each requiring change control impact assessment. Data integrity expectations apply throughout: attributable operator actions, audit trails on recipe and setpoint changes, and historian records that support batch record review.

GXPLearn's foundation modules build Category 4 literacy — architecture mapping from field through controllers to MES and historian (Module 02), ISA-88 recipe structure and batch evidence (Module 03), and CSV scope thinking for access control, interfaces, and backup (Module 09) — without requiring learners to code custom applications.

Category 5: Custom Applications

Category 5 covers software designed and coded to suit specific business processes. Examples include internally and externally developed IT applications, custom process control applications, custom ladder logic, custom firmware, and macro-driven spreadsheets.

GAMP expects everything required for Category 4, plus: more rigorous supplier assessment with possible supplier audit; possession of full lifecycle documentation (functional specification, design specification, structural testing); and design and source code review.

Category 5 carries the highest validation burden because the regulated company owns the full development lifecycle. Traceability from requirements through design to code to test must be demonstrable. Structural testing, code review, and regression analysis after changes are expected — not optional.

Macro-driven spreadsheets are a common Category 5 trap: a 'simple' Excel tool used for calculations or batch tracking may be custom application software requiring full validation if it supports GxP decisions. The category is defined by customisation and ownership, not by apparent simplicity.

How GAMP Categories Influence Validation Effort

More customisation increases validation burden; higher GxP impact increases scrutiny regardless of category. The table below compares how Categories 1, 3, 4, and 5 typically differ across key validation dimensions.

GAMP 5 and Computer System Validation

Computer System Validation (CSV) is the GMP discipline of demonstrating fitness for intended use through documented lifecycle activity. GAMP supports CSV by providing the lifecycle structure, categorisation logic, and supporting processes that CSV teams implement.

GAMP answers practical CSV questions: How much testing is enough? What can the supplier provide? Which specifications are needed? How should traceability be organised? The What is CSV? guide explains the regulatory baseline; GAMP explains how to scale the work.

Validation lifecycle planning under GAMP aligns with the V-model thinking in Validation lifecycle explained — requirements and design on the left, verification and qualification on the right. Risk-based validation means a Category 4 DCS with high process impact receives deeper OQ and PQ evidence than a Category 1 middleware layer — see IQ, OQ & PQ explained for qualification detail.

Supplier leverage is a core GAMP efficiency principle: use supplier documentation, test evidence, and quality system certifications where assessed as suitable — then supplement with site-specific configuration and business process testing.

GAMP 5 and Computer Software Assurance (CSA)

GAMP and CSA solve different questions — and work best together. GAMP asks: What type of software do I have? CSA asks: How much assurance is appropriate based on risk?

GAMP categorisation establishes the baseline lifecycle and documentation expectations. CSA critical thinking then proportions assurance activities within that structure — especially for Category 4 systems where configuration depth varies enormously. A high-risk alarm priority change in a DCS loop warrants more rigorous evidence than a non-GxP tooltip text change, regardless of both being Category 4.

FDA's CSA guidance emphasises process risk, intended use, and objective evidence over uniform documentation depth. GAMP provides the category and lifecycle scaffold; CSA provides the risk-based lens for choosing testing methods — scripted, exploratory, or supplier-leveraged.

Documentation reduction under CSA is not documentation elimination. Category 5 custom code still needs design and test traceability; Category 1 infrastructure still needs installation baselines. See What is CSA? and CSV vs CSA comparison for how assurance strategy complements GAMP categorisation.

GAMP 5 Across the Validation Lifecycle

Software categorisation influences every lifecycle stage — not only testing.

URS: Category drives specificity — Category 4 URS must capture business process configuration; Category 5 URS must capture custom functional requirements. Risk assessment: Impact and complexity modifiers apply on top of category. Design review: Mandatory before commitment; deeper for Category 5.

IQ, OQ, PQ: Installation verification scales from Category 1 baselines to full qualification for Category 4/5 GMP-critical functions. Traceability: Required across categories when GxP data is affected; most extensive for Category 5. Change control: Configuration changes dominate Category 4 operations; code changes dominate Category 5.

Periodic review confirms maintained validated state — reassessing category assumptions if the system has been extended with custom integrations or new modules. Data integrity expectations from What is data integrity in GxP? apply across all categories where GMP records are created or modified.

The Validation lifecycle explained and IQ, OQ & PQ explained guides expand each phase; GAMP categorisation is the lens that determines how deeply each applies to your specific system.

How GXPLearn Teaches GAMP Thinking

GXPLearn does not replicate a GAMP document — it practises the decisions GAMP describes. Module 09 (CSV Validation) grounds learners in Annex 11, Part 11, and GAMP 5 references while scoping validation evidence for access control, interfaces, backup, and audit trails.

Module 10 (V-Model) builds traceability across specification and test layers — the same traceability GAMP lists as a supporting process. Module 11 (CSA) practises risk-based assurance sizing through the Assurance Chain: intended use, failure concern, risk rationale, assurance activity, and objective evidence.

Module 03 (ISA-88 Recipes) and Module 02 (Architecture) provide Category 4 context — how configured batch systems, recipes, historians, and MES records connect. Module 24's Validation Digital Twin capstone practises change-to-closure with configuration impact assessment and regression thinking.

Explore CSV & CSA training for the guided path, or Resources hub for the full validation knowledge cluster including CSV, CSA, lifecycle, IQ/OQ/PQ, and data integrity guides.