GAMP 5 Category 4 vs Category 5: configured vs custom software, explained

The GAMP 5 categories in one minute

GAMP 5 groups software by how much of it is unique to you. Category 1 is infrastructure such as operating systems and databases. Category 3 is software used as supplied, with only settings changed. Category 4 is a configured product. Category 5 is custom code. There is no Category 2; it covered firmware in earlier GAMP versions and was dropped. Our GAMP 5 validation guide covers all of them and the V-model behind them.

The second edition of GAMP 5, published in 2022, keeps the categories but stresses that they are a starting point for thinking about risk, not a rule that decides the testing on its own.

The second edition also puts more weight on critical thinking, involving suppliers early, iterative and agile development, and using tools and automated testing as evidence. For the Category 4 vs 5 question that matters: a well-run custom build can produce its evidence continuously, and a configured product still needs people who understand the process to decide what to test.

Category 4 vs Category 5, side by side

Neither category is “better”. A configured product reduces how much you specify and test; custom software fits the process exactly. The decision belongs to the business case, which our comparison of custom vs off-the-shelf LIMS looks at for labs.

Where configuration ends and customisation begins

The useful question is not “did we write code?” but “is this behaviour unique to us, and has anyone else’s use tested it?”

Usually Category 4 (configuration)

• Choosing options, picklists and units in admin screens.
• Defining roles, permissions and approval steps with built-in tools.
• Entering specifications, test methods and limits as master data.
• Using standard report templates with your logo and fields.

Usually Category 5 (custom), even inside a product

• Scripts or macros written in the product’s scripting language.
• Custom calculations that are not standard product functions.
• Bespoke reports built with a query or report designer.
• Interfaces to instruments, ERP or other systems built for you.

Mixed systems: assess each component

Almost every lab or quality system is a mix. A typical LIMS project might look like this:

• Database and operating system: Category 1.
• The LIMS product configured for your lab: Category 4.
• A custom stability-study module: Category 5.
• An interface to a chromatography data system: Category 5.
• A barcode printer driver used as supplied: Category 3.

Assess each component, record its category in the validation plan or risk assessment, and plan the work to match. The custom parts get functional and design specifications, code review and developer testing; the configured core gets a configuration specification and testing of your workflows. One traceability matrix then ties it together. Our GxP software validation guide walks through the full life cycle, from the validation plan to the summary report.

What each category needs documented

The documents overlap more than people expect. Both categories need a plan, requirements, risk assessment, testing and a report; the difference is the design layer and the developer evidence.

• Both: validation plan, URS, supplier assessment, risk assessment, traceability matrix, IQ/OQ/PQ or equivalent testing, summary report.
• Category 4 adds: a configuration specification that records every setting that matters, so it can be tested and kept under change control.
• Category 5 adds: functional specification, design specification, coding standards, code review records, unit and integration test evidence.
• Category 5 also needs: source code under version control, controlled builds and a documented development life cycle.

Our explainer on what goes into a validation package lists each document and who usually writes and approves it.

Leveraging the supplier

GAMP 5 encourages you to rely on good supplier work rather than repeat it. For a Category 4 product that can be most of the functional testing; for Category 5, it is the developer’s own testing and quality records. Either way, reliance needs an assessment first. Look for:

• A documented quality system and development life cycle.
• Requirements and tests that trace to each other.
• Release notes and known-issue lists for each version.
• Change control and defect management you can inspect.
• Willingness to support audits and share evidence.

When we build custom systems, we write the specifications, test evidence and traceability with the code so your QA can assess and leverage it. For systems from other suppliers, our computer system validation service prepares the validation deliverables; sign-off stays with your QA.

Common mistakes when categorising software

• Calling everything Category 4 to reduce the work, while scripts and custom reports go untested.
• Treating the category as the risk. A configured function that calculates a release result is high risk; a custom dashboard may not be.
• Not recording the rationale. An auditor will ask why a component was placed in a category; the answer should be written down.
• Forgetting infrastructure. Category 1 software still needs qualified, controlled environments and recorded versions.
• Assuming SaaS means less work. Cloud products are usually Category 4, but vendor-controlled releases need a plan for impact assessment and regression testing.
• Re-categorising nothing after changes. When a configured product gains custom scripts over time, the validation approach for those parts has to change too.

Choosing between a configured product and custom software

A few honest questions usually settle it:

1. Does a product cover most of your process with configuration alone, or would it need many scripts and workarounds?
2. How unusual are your methods, calculations, approval chains or integrations?
3. Who will maintain it, and how often will the vendor’s upgrade cycle force revalidation?
4. Do you need to own the code and the roadmap, or is a supported product more valuable?

A heavily scripted Category 4 product can end up with more custom code to validate than a well-scoped Category 5 build. Count the custom parts honestly before you decide.

Frequently asked questions