GAMP 5 Categories Explained for People Who Actually Build Things

You already do risk-based engineering. You do not put the same effort into verifying a limit switch that you put into verifying a custom motion profile, because one is a known quantity and the other is logic you wrote from scratch. You lean on a vendor's tested function block where you can, and you scrutinize the code you authored yourself. That instinct, applied to software in a regulated environment, is most of what GAMP 5 is.

The problem is that almost every GAMP 5 explainer is written for quality assurance, so the people who actually configure the SCADA system, write the ladder logic, and stand up the historian bounce off it. The categories get presented as a compliance taxonomy instead of what they really are: a way to decide how much validation work a given piece of software earns, based on how much of it you built versus how much someone else already tested.

This guide is for the engineer doing the building. It covers what GAMP 5 is and where it sits relative to the regulations, what each category actually means with real build examples, the part nobody tells you up front (most real systems span several categories at once), how the category drives validation effort under the current Second Edition and the FDA's CSA thinking, a worked walkthrough on a packaging line control system, and the mistakes that flag during inspections.

What GAMP 5 actually is

GAMP 5 is a guide published by ISPE, the International Society for Pharmaceutical Engineering. Its full title is "GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems." The First Edition came out in 2008 and the Second Edition was published in July 2022. The acronym stands for Good Automated Manufacturing Practice, and the document describes a framework for validating computerized systems in regulated industries: pharma, biotech, and medical device manufacturing.

The first thing to be clear about, because it changes how you should treat it, is that GAMP 5 is guidance, not law. No regulation says "thou shalt follow GAMP." What the regulations require is that computerized systems used in regulated processes are fit for purpose and under control. GAMP 5 is the framework commonly used to demonstrate that, and one auditors are generally familiar with, but it is an industry consensus document rather than a statute.

The regulations it helps you satisfy are the ones that do carry legal force. EU GMP Annex 11 governs computerised systems used in GMP activities and expects a risk-based validation approach. 21 CFR Part 11 governs electronic records and electronic signatures that you maintain or submit electronically to satisfy an FDA predicate-rule requirement. For medical device manufacturers, the FDA Quality Management System Regulation took effect February 2, 2026 and incorporates ISO 13485:2016 by reference. ISO 13485:2016 spreads the software-validation expectation across three clauses: clause 4.1.6 covers software used in the quality management system, clause 7.5.6 covers software used in production and service provision where the output cannot be fully verified by later inspection, and clause 7.6 covers software used to monitor and measure. You validate each to a degree proportionate to its risk. The pre-QMSR Quality System Regulation expressed similar expectations at 21 CFR 820.70(i) for automated process software, and teams whose documentation predates the transition will still reference it.

GAMP 5 also rests on a software category system, and that category system is the practical heart of the guide for anyone who builds. The category you assign to a piece of software sets the baseline for how much validation rigor it needs and how much of the supplier's own testing you are allowed to lean on. Intended use and risk to product quality then adjust that baseline. Get the category right and the validation scope starts to fall out of it. Get it wrong and you either drown a simple component in paperwork or leave a custom one dangerously under-tested.

The categories, with build examples

GAMP 5 defines four software categories. They are numbered 1, 3, 4, and 5. There is no Category 2, and that is the first question every engineer asks, so it is worth answering directly: Category 2 covered firmware in the older GAMP 4 framework and was retired when GAMP 5 was published in 2008. Firmware now gets categorized by what it actually is, usually Category 3 for a non-configured instrument or Category 1 as part of infrastructure. If a colleague refers to a "Category 2" system, they are working from a pre-2008 mental model.

The categories are not a maturity scale or a quality ranking. A Category 5 system is not better or worse than a Category 3 system. The number tells you one thing: how much of the software was built or configured specifically for you, which is the same as telling you how much validation evidence you are responsible for generating yourself versus inheriting from a supplier who already tested it.

Category 1: Infrastructure software

Category 1 is the layer everything else runs on. Operating systems, database engines, middleware, network management software, antivirus tools, programming languages and their runtimes, virtualization platforms. You do not configure business logic into these. You install them, you record the versions, and you rely on the fact that they are commercially established and widely used.

For a build engineer, the historian's underlying SQL database is Category 1. The Windows or Linux OS the SCADA server runs on is Category 1. The PLC's vendor runtime that executes your program is generally treated as Category 1 infrastructure. The validation burden here is light: confirm correct installation, record the version under configuration control, and manage it through your IT infrastructure qualification rather than through a system-specific validation protocol. You are not testing whether the database engine can store a row. You are confirming it is installed correctly and kept current.

Category 3: Non-configured products

Category 3 is commercial off-the-shelf software used as it ships, without configuring the business logic. You might set a few run-time parameters, a measurement range, an alarm limit, a unit of measure, but you are not building process logic into it. It does what the vendor designed it to do, and you use it for that.

In a plant, the embedded software in a standalone benchtop instrument you use exactly as delivered is Category 3. The firmware in a standard sensor or transmitter used as-is is Category 3. A boxed software package installed with default functionality and used straight is Category 3. The category applies to the software layer, not the whole hardware assembly. The validation approach is risk-based functional testing: verify that the functions you actually rely on do what you need them to do, against your requirements, and lean on the supplier's documentation, quality system evidence, and service history. You do not review the source code. You confirm the product performs the job you bought it for in your environment.

Category 4: Configured products

Category 4 is where most plant-floor automation lives, and it is the category build engineers most often get wrong. A Category 4 product is a commercial platform that you configure to your specific process using the configuration tools the vendor built in, but without writing custom code. The platform was tested by the supplier. Your configuration was not, and that is what you are on the hook to validate.

A SCADA system configured with your tags, screens, alarms, and trends is Category 4. A PLC program assembled from the vendor's standard, tested function blocks and configured to your process is Category 4. A LIMS, an MES, a DCS, a chromatography data system, an ERP module, each configured to your workflows using built-in configuration rather than bespoke code, is Category 4. The validation focus is the configuration itself: does your specific setup, your alarm limits, your interlock configuration, your calculated fields, your report templates, behave correctly and meet your requirements. You leverage the supplier's testing of the underlying platform, and you concentrate your own effort on the parts you configured. A supplier assessment or audit is often warranted at this level to justify how much you lean on their lifecycle.

Category 5: Custom applications

Category 5 is software built to your specific requirements that did not exist before you commissioned it. Custom code. Bespoke applications. Nobody else has tested it because nobody else has it.

Custom PLC logic written from scratch in ladder or structured text to meet a process requirement, rather than assembled from standard function blocks, is Category 5. A custom MES module developed for your line is Category 5. Custom interface code between two systems is Category 5. A spreadsheet with macros or scripted calculations driving a regulated decision is Category 5. So is a custom script in your SCADA system that does something the standard configuration tools cannot. The validation burden is the heaviest here because you own the entire lifecycle: requirements traceability, design review, often source code review, structural and functional testing, the full chain of evidence. Even when an integrator or vendor writes the custom code, no off-the-shelf product testing covers it, so the lifecycle evidence for that bespoke layer is yours to own and assess. The flip side is that the rigor is proportionate to genuine risk, because custom code is exactly where novel, untested failure modes live.

The part nobody tells you: real systems are several categories at once

Here is the insight that trips up smart engineers, and it is the single most useful thing in this guide. You do not categorize a system. You categorize the components and functions inside it. A real control system is almost never one clean category.

Take a single SCADA-and-PLC system on a packaging line. The server's operating system and the historian's database are Category 1. A boxed vision-inspection unit that you use exactly as it ships is Category 3. The SCADA application, configured with your tags, screens, alarms, and standard reports, is Category 4. The PLC program, where you used vendor function blocks for the conveyor and motor control but wrote custom structured text for a bespoke reject-and-reconcile routine, is partly Category 4 and partly Category 5. One physical system, four categories living inside it simultaneously.

This matters because the validation effort follows the category of each part, not the system as a whole. If you categorize the entire system as Category 4 because "it is mostly configured SCADA," you will under-validate the custom reject routine that is actually your highest-risk software. If you categorize the whole thing as Category 5 because "there is some custom code in there," you will waste weeks generating bespoke-level evidence for a database engine that needed a version record. The discipline GAMP 5 actually asks for is decomposition: break the system into its functional building blocks, categorize each one, and let the validation scope for each part follow from its category and its risk.

How the category drives validation effort

The category is not the whole story. GAMP 5 is risk-based, which means the category sets the baseline rigor and the risk to product quality and patient safety adjusts it. A Category 5 component that cannot affect product quality or data integrity does not need the same scrutiny as a Category 4 component that controls a critical process parameter. Category times risk, not category alone.

With that caveat, the category gives you the starting point for how much you do and how much you inherit:

For Category 1 infrastructure, you verify installation and version, and you manage it through infrastructure qualification rather than a dedicated validation protocol. You inherit essentially everything from the established, commercial nature of the software.

For Category 3 non-configured products, you perform risk-based functional testing of the functions you use, against your requirements, and you lean on supplier documentation. You inherit the product's internal design and the supplier's development testing. You do not write or review code.

For Category 4 configured products, you test your configuration against your requirements, you keep the configuration under change control, and you typically assess the supplier to justify leveraging their platform lifecycle. You inherit the tested platform. You own the validation of everything you configured on top of it.

For Category 5 custom applications, you run the full lifecycle: requirements, functional and design specifications, traceability, design review, often code review, structural and functional testing, and the complete evidence chain. There is no off-the-shelf platform testing to inherit for the bespoke logic. When an integrator builds it, you assess their development and testing rather than lean on a tested product, and the evidence for the custom layer still has to exist and be yours to defend.

The Second Edition of GAMP 5, published in 2022, sharpened one theme that build engineers should take seriously: critical thinking over rote documentation. The guide explicitly pushes teams to apply judgment about where risk actually lives, to leverage supplier involvement and supplier testing rather than re-proving what the vendor already proved, and to scale effort to risk rather than producing the same thick binder for every component regardless of what it does. It added guidance on iterative and Agile development, on software tools, and on emerging areas including artificial intelligence and machine learning.

That direction lines up with the FDA's Computer Software Assurance approach. The FDA issued CSA as draft guidance in September 2022, finalized it on September 24, 2025 as "Computer Software Assurance for Production and Quality Management System Software," and revised it on February 3, 2026 to align with the QMSR. CSA promotes a risk-based, least-burdensome model for the software used in production and the quality management system. It tells teams to determine the process risk of each software feature, function, or operation, to concentrate assurance on the high-risk ones whose failure could also pose a medical device risk, to use unscripted and ad-hoc testing where the risk is low rather than defaulting to exhaustive scripted protocols for everything, and to leverage vendor activities. CSA does not replace GAMP 5. It is complementary, and it reinforces the same instinct: spend your validation effort where the risk is, and stop spending it where it is not.

A worked walkthrough: a packaging line control system

Concrete beats abstract, so here is the decomposition for a realistic system. The line fills, caps, labels, inspects, and cartons a finished product. The control system is a PLC handling the machine logic, a SCADA application for the operator interface and supervisory control, a vision unit checking label placement, and a historian capturing batch data. Walk it component by component.

The SCADA server's operating system and the historian's database engine are Category 1. Validation activity: record the versions under configuration control, confirm correct installation, and cover them under the site's infrastructure qualification. No system-specific protocol.

The vision inspection unit, used exactly as the vendor ships it with only the inspection thresholds set as run-time parameters, is Category 3. Validation activity: functional testing that it correctly passes good labels and rejects bad ones across the conditions you care about, leveraging the vendor's documentation. No code review.

The SCADA application, configured with your tags, mimics, alarms, user roles, and standard trend and batch reports, is Category 4. Validation activity: test the configured functions against your requirements, with particular attention to alarms, access control, and any configured calculations or reports, and keep the configuration under change control. You lean on the SCADA vendor's platform testing, justified by a supplier assessment.

The PLC program is the interesting one because it is split. The conveyor sequencing, motor control, and standard interlocks, built from the vendor's tested function block library and configured to your line, are Category 4. The custom reject-and-reconcile routine, written in structured text specifically for this line to count rejects, reconcile them against the batch count, and hold the batch if reconciliation fails, is Category 5. Validation activity: for the Category 4 portion, test the configured logic against requirements and leverage the function block library's pedigree. For the Category 5 routine, run the full custom lifecycle, with design review, traceable requirements, and targeted structural testing, because this is bespoke logic that gates batch disposition and therefore carries real product-quality risk.

Notice what the decomposition gave you. The validation effort is concentrated on the custom reject routine and the alarm and access configuration, the two places where untested logic meets product quality and data integrity. The database engine and the off-the-shelf vision unit got proportionate, light treatment. That is the category system doing its job: routing your effort to where the risk actually is. The output of this exercise feeds directly into the IQ, OQ, and PQ scope for the system, which is why the validation master plan should reference the categorization, and why a software change that touches the Category 5 routine triggers a different revalidation assessment than a change to a Category 1 component.

Common mistakes build engineers make

The first and most common mistake is treating the whole system as a single category. It feels tidier to call the packaging line "a Category 4 SCADA system," but that tidiness is exactly what buries the custom routine that needed the most attention. Decompose first, categorize the parts, then scope.

The second is over-validating Category 3 components. Generating bespoke-level test protocols, requesting source code, and building full traceability for a boxed instrument used as-is is wasted effort that runs against the risk-based direction of both the GAMP 5 Second Edition and CSA. Functional verification of the functions you use, plus supplier documentation, is the proportionate answer.

The third, and the dangerous one, is under-validating Category 5 custom logic. Custom ladder, structured text written from scratch, scripted SCADA logic, and spreadsheet macros that drive regulated decisions are exactly where novel failure modes hide, and they are the components no supplier tested for you. When a custom routine gets folded into a "mostly configured" system and inherits that system's lighter validation treatment, the result is untested bespoke code controlling a regulated process, exactly the kind of gap an inspection is designed to surface.

The fourth is ignoring supplier documentation you are entitled to lean on. The whole point of the category system is that higher-category effort buys you the right to inherit lower-category work from a competent supplier. Teams that re-prove a vendor's tested platform from scratch are spending Category 5 effort on a Category 4 problem. A supplier assessment that justifies the leverage is the lighter and more defensible path.

The fifth is letting the categorization go stale. The category of a component changes the moment you add custom code to a previously configured system, or replace a custom module with a configured one. A SCADA system that was cleanly Category 4 becomes a mixed Category 4 and 5 system the day someone adds a custom script, and the validation scope has to follow. Categorization is part of the living configuration record, not a one-time exercise at commissioning.

Where this leaves the build engineer

GAMP 5 categories are not a compliance vocabulary to memorize. They are a routing system for your own effort. The number you assign to each component answers one question: how much of this did someone competent already test, and how much is on me. Category 1 and 3 components carry light, supplier-leveraged validation. Category 4 concentrates effort on what you configured. Category 5 puts the full lifecycle on the bespoke code you wrote, because that is where genuinely untested behavior lives.

The mechanics are not complicated. Decompose the system into functional components. Categorize each one by how much was built or configured for you. Set the baseline rigor from the category and adjust it for risk to product quality and data integrity. Leverage supplier testing wherever a category and a supplier assessment let you. Concentrate your own evidence on the configured and custom parts that can actually hurt the product. And update the categorization whenever the software changes, because a single custom script can move a component from one category to another and pull the validation scope with it.

That is the same risk-based judgment you already apply when you decide how hard to test a limit switch versus a custom motion profile. GAMP 5 is that judgment, written down, with the regulators reading over your shoulder.

---

Valiqa is an AI-powered validation lifecycle platform for regulated manufacturing. Learn more at valiqa.io