GAMP 5 — the ISPE Good Automated Manufacturing Practice guide, now in its Second Edition — provides the framework that most pharmaceutical companies use to classify their computerised systems and determine the appropriate validation approach. At the heart of GAMP 5 is the software categorisation system: five categories that describe different types of software based on their complexity and configurability. Getting the category right is important because it determines how much validation effort is appropriate — over-classify a system and you waste resources on unnecessary testing; under-classify it and you miss risks that should have been addressed. Here is what each category actually means, with real examples.
Category 1: Infrastructure Software
Category 1 covers infrastructure software — operating systems, database engines, networking software, and similar foundational tools that are widely available, used across many industries, and not configured for GxP-specific purposes. Think Windows Server, Linux, Oracle Database (the database engine itself, not an application built on it), middleware, and virtualisation platforms like VMware. The validation approach for Category 1 software is minimal: verify that the correct version is installed, confirm the installation completed successfully, and document the configuration settings. You do not need to test the software's core functionality because it has been extensively tested by the vendor and by millions of other users. What you do need to verify is that the infrastructure supports the applications running on top of it — the right patches are applied, security settings are configured correctly, and backup procedures are in place. A common mistake is over-validating Category 1 software — running functional tests on Windows or Oracle that add no value and consume resources that should be spent on the applications that actually perform GxP functions.
Category 3: Non-Configured Products
Category 3 covers commercial off-the-shelf software that is used as-is, without configuration that affects GxP functionality. Examples include scientific calculators, simple data viewers, PDF generators, and basic reporting tools. The key characteristic is that the software is used in its default state — you install it and use it without modifying its behaviour.
The validation approach for Category 3 is light: verify installation, confirm the version, and perform focused testing on the specific functions you use for GxP purposes. You do not need to test every feature of the software — only the features that generate, process, or report GxP data in your environment. For example, if you use a PDF tool to generate controlled document PDFs, you need to verify that the PDFs it produces are accurate and complete. You do not need to test its bookmark feature or its markup tools unless you use those for GxP purposes.
Category 4: Configured Products
Category 4 is where most GxP computerised systems fall — and where most validation effort is concentrated. Category 4 covers commercial software products that have been configured for your specific business processes. This includes LIMS, eQMS, MES, ERP, ELN, EDMS, and most enterprise applications used in pharmaceutical operations.
The critical distinction between Category 3 and Category 4 is configuration. When you configure a LIMS to define your sample types, test methods, specifications, and workflow rules, you are creating a system that behaves differently from any other installation of the same LIMS. That configuration needs to be validated because it is unique to your organisation. The validation approach for Category 4 focuses on the configuration: verify that your configured workflows operate correctly, your configured business rules are enforced, your configured reports produce accurate output, and your configured security settings restrict access appropriately. You can leverage the vendor's testing of the base platform (especially for GAMP 5 Second Edition, which explicitly supports leveraging vendor documentation under CSA), but you must test your specific configuration. GxP Copilot handles Category 4 validation by generating risk-scored test cases specific to your configuration, not generic tests of the base platform.
Category 5: Custom Applications
Category 5 covers software that has been developed specifically for your organisation — custom-built applications, bespoke scripts, custom-developed macros, and purpose-built tools. These require the most thorough validation because there is no vendor testing to leverage and no user community that has identified bugs through widespread use. Examples include custom laboratory calculation tools, bespoke data migration scripts, custom interfaces between systems, and in-house developed manufacturing execution tools. The validation approach for Category 5 follows the full V-model: documented user requirements, functional specifications, design specifications, and testing at each level (unit testing, integration testing, OQ, PQ). Every aspect of the software's functionality needs to be tested because you are the only user and your organisation is responsible for the entire software lifecycle. The GAMP 5 Second Edition and CSA do allow risk-based testing for Category 5 — not every function needs the same depth of testing — but the coverage should be comprehensive even if the depth varies by risk.
What happened to Category 2
You may have noticed that we skipped Category 2. In the original GAMP 5 (2008), Category 2 covered firmware — embedded software in instruments and equipment. In the GAMP 5 Second Edition (2022), Category 2 was removed as a separate category. Firmware is now treated as part of the equipment it is embedded in, and its validation is handled through equipment qualification (IQ/OQ/PQ) rather than as a separate software validation activity. This change makes practical sense: nobody validates firmware independently of the equipment it controls. When you qualify an HPLC instrument, you are implicitly validating its firmware as part of the operational qualification. The removal of Category 2 simplifies the framework without losing any practical coverage.
Getting the classification right: practical tips
- Look at what you configured, not what you could configure. A LIMS that you installed with default settings and use without modification is Category 3, not Category 4 — even though the vendor will tell you it is highly configurable. Classification is based on what you actually did, not what is possible.
- Custom reports and interfaces bump the category. If you built custom reports, custom interfaces to other systems, or custom calculations within a Category 4 product, those custom elements are Category 5. The base product remains Category 4, but your validation needs to address both categories.
- Spreadsheets are usually Category 5. A validated Excel spreadsheet with custom formulas, macros, or VBA code is Category 5 custom software. Treat it accordingly — many companies under-validate their spreadsheets because they do not think of Excel as "software."
- Cloud/SaaS does not change the category. Whether software is installed on-premises or delivered as SaaS does not affect its GAMP 5 category. A cloud LIMS with custom configuration is still Category 4. What changes is the shared responsibility model for infrastructure (Category 1) validation.
- Use the classification to drive effort, not to check a box. The whole point of GAMP 5 categories is to ensure you spend validation effort where it matters. Classification Engine in GxP Copilot automates the classification and uses it to drive the risk assessment and test generation — the category is not just a label, it is the foundation of your risk-based validation strategy.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.