GAMP 5 Software Categories for Bought In Skids and Control Systems
GAMP 5 software categories 1, 3, 4 and 5 in plain words, mapped to the skids, instruments and control systems a buyer actually orders, with what to ask suppliers for.

GAMP 5 is the International Society for Pharmaceutical Engineering's (ISPE) guidance on a risk based approach to compliant GxP computerised systems, now in its second edition. It sorts software into categories: category 1, infrastructure such as operating systems and networks; category 3, standard software used as supplied; category 4, standard software configured for your process; and category 5, custom code written for you. For a buyer of skids, instruments and control systems, the category of each software element sets what documents and tests to ask the supplier for, and how much effort qualification will take.
GAMP 5 is guidance, not law. The legal requirements come from rules such as EU GMP Annex 11; GAMP 5 is the most widely used way of meeting them.
Why this matters now
Regulators are moving towards risk based assurance and closer attention to suppliers. FDA finalised its guidance on computer software assurance for production and quality system software in September 2025: effort should match risk, unscripted testing can suit lower risk features, and vendor assessments and system records can replace much paper evidence [1]. In Europe, the draft revision of Annex 11, put out for consultation in July 2025 [2], grows from 5 to 19 pages and includes a section on supplier and service management [3].
The second edition of GAMP 5 points the same way. It keeps the original framework but stresses critical thinking by subject matter experts, gives more weight to IT service providers including cloud providers, and fully supports iterative, agile development [4].
Join ChemCapital to streamline sourcing and connect with verified partners
Whether you're buying or supplying, ChemCapital gives you the tools to manage the complete procurement cycle in one platform.
The categories in plain words
| Category | What it is | Typical examples | Evidence effort |
|---|---|---|---|
| 1, infrastructure | Software that the application runs on | Operating systems, firewalls, antivirus [5] | Record and control versions |
| 3, used as supplied | Standard software with no configuration of its own | Simple data acquisition tools, control panel viewers [5] | Show it meets the requirement |
| 4, configured | Standard software set up for your process | LIMS, ERP, process control systems such as PLCs, spreadsheets with linked formulas [5] | Specify and test the configuration |
| 5, custom | Code written for you | Add ons to standard software, VBA macros, bespoke systems [5] | Design, review and test fully, with traceability |
Category 2, which covered firmware, was dropped when GAMP 5 replaced GAMP 4; firmware now falls into category 3, 4 or 5 depending on what it does [5]. The numbering was kept, which is why there is no category 2.
The second edition: a continuum, not boxes
The second edition treats categories 3 to 5 as a continuum rather than separate boxes, and makes the category only one factor in deciding effort, alongside the system's impact on product quality and patient safety, its complexity and its novelty [4]. A configured system that controls sterilisation deserves more attention than a custom report that nobody uses for release decisions.
That matters when you buy equipment, because one skid can contain several categories at once.

Mapping categories to what you buy
A skid with a PLC and HMI. The PLC and HMI platforms are standard products. Their parameters, screens, alarms and recipes are configured, which points to category 4. Application logic written for your process, such as cleaning sequences or interlocks, is usually treated as custom, category 5. Classify each element separately.
Instruments with firmware. A transmitter used as supplied is usually category 3. If you configure its ranges and alarms, record the configuration as part of the qualification.
SCADA, historians and batch systems. Standard packages configured for your plant are category 4; scripts and custom reports added to them are category 5.
Cloud services. The second edition adds guidance on assessing cloud service providers [4], so treat the provider as a supplier to be assessed, not just a hosting choice.
What to ask the supplier for in the RFQ
Put these in the RFQ so they are priced, rather than discovered after the order. Annex 11 expects formal agreements with third parties that supply or support computerised systems and says the need for a supplier audit should follow a risk assessment [6].
| Request | Why |
|---|---|
| Supplier quality system and willingness to be assessed or audited | Basis of supplier assessment |
| Software item list with category, version and licence | Lets you classify and control each element |
| Functional specification answering your user requirement specification | Shows how each requirement is met |
| Configuration specification for category 4 elements | The record of what was set up |
| Design specification and code review for category 5 elements | Evidence that custom code was built with control |
| Test plans and records for factory and site tests | Reusable in qualification |
| Traceability from requirements to tests | Shows nothing was missed |
| Audit trail, user management and backup features | Data integrity of the delivered system |
| Change control and release notes | Control after delivery |
| Security information, including patching and a software bill of materials where available | Vendor assessment, as FDA suggests [1] |
Well specified supplier documents can feed directly into IQ, OQ and PQ, which is where most of the cost of poor documents shows up.
Who does what
Classification is a team job. The engineer who owns the system lists the software elements and proposes a category for each. Quality assurance agrees the categories and the level of evidence, based on risk. The buyer puts the resulting document and testing requirements into the RFQ, checks that each bid prices them, and makes them conditions of payment where it matters. The supplier delivers the evidence and keeps it under change control. When these roles are blurred, documents arrive late or not at all, and qualification waits.
Common mistakes
- Classifying the whole skid as one category. A skid is a collection of software elements, and each needs its own place.
- Leaving documents out of the RFQ. Specifications and test records requested after the order are expensive, slow and sometimes refused.
- Treating "validated" as a product feature. Suppliers can provide evidence and support, but validation is done by the regulated company for its intended use.
- Testing everything to the same depth. Risk based assurance, as both GAMP 5 and FDA describe it, means more effort where failure would harm product or patient, and less where it would not [1, 4].
Practical example
In this illustrative example, a buyer orders a cleaning in place skid with a PLC and an HMI computer. The supplier's software item list shows seven elements.
| Software element | Category | Evidence requested |
|---|---|---|
| Operating system on the HMI computer | 1 | Version and patch policy |
| HMI runtime software | 3 | Version, licence |
| HMI screens, alarms and recipes | 4 | Configuration specification and tests |
| PLC firmware | 3 | Version |
| PLC cleaning sequences and interlocks | 5 | Design specification, code review, full testing |
| Conductivity transmitter firmware | 3 | Version and configured ranges |
| Custom batch report script | 5 | Specification and testing |
Two of the seven elements are custom, and one of them, the cleaning sequences, has direct product quality impact. That is where the buyer concentrates review effort and insists on full, traceable testing at the factory. The report script is also custom, but if the report is not used for release decisions, a lighter level of testing may be justified, recorded with its reasoning.
Where ChemCapital fits
ChemCapital's RFQs carry structured line items and attachments, so your URS, software document list and testing expectations go to every bidder and are priced up front. ChemCapital is also open about its own position: its Trust Centre says it has reviewed the GAMP 5 second edition against its architecture, classes itself as category 5, marks its configured and custom software area as partial, and states that it is not "GAMP 5 certified" because no such certificate exists. Its validation pack is partly live, with formal specifications and IQ, OQ and PQ evidence on its roadmap.
Ready to put the right software questions into every equipment RFQ? Start free with ChemCapital.
Frequently asked questions
What are the GAMP 5 software categories?
Category 1 is infrastructure software such as operating systems and networks; category 3 is standard software used as supplied; category 4 is standard software configured for your process; and category 5 is custom code written for you. Category 2, firmware, was dropped when GAMP 5 replaced GAMP 4, with firmware now placed in category 3, 4 or 5.
Is a PLC category 4 or category 5?
Often both. The PLC platform and its standard function blocks are configured, which points to category 4, while application logic written for your process is usually treated as custom, category 5. Classify each software element separately and scale the evidence to risk.
Is GAMP 5 a legal requirement?
No. GAMP 5 is ISPE guidance on a risk based approach to compliant GxP computerised systems. The legal requirements come from regulations such as EU GMP Annex 11, and GAMP 5 is a widely used way of meeting them.
Continue reading
Informational only, not procurement or legal advice. Cited names, frameworks, and statistics belong to their respective owners.
Join ChemCapital to streamline sourcing and connect with verified partners
Whether you're buying or supplying, ChemCapital gives you the tools to manage the complete procurement cycle in one platform.
Get started freeRelated articles

Commissioning and Qualification: ASTM E2500 vs Traditional IQ OQ PQ
How the science and risk based ASTM E2500 approach differs from traditional IQ, OQ and PQ, who does what, how vendor tests can be reused, and what to put in the RFQ.

Audit Trail Requirements in GMP: What a Compliant Record Must Capture
What EU Annex 11, 21 CFR Part 11 and MHRA guidance require of an audit trail, what audit trail review means in practice, and worked entries for a procurement record.

21 CFR Part 11 and Electronic Signatures on Procurement Records
A plain guide to 21 CFR Part 11 for buyers at GMP sites: which purchasing and vendor records fall in scope, what electronic signatures must show, and what to check in a tool.