Why Your Category Decision Matters More Than You Think
In GAMP 5, your software category isn't a label — it's a decision that cascades through your entire validation project. The category you assign to your PLC/SCADA system determines which documents you need to produce, how much testing evidence is required, and how much design documentation must be approved before you start writing test cases.
Most automation engineers entering pharma either don't know this decision exists, or they guess. Both are expensive mistakes — either you spend weeks producing documents nobody required, or you arrive at a QA review with a scope gap that stops the project.
GAMP 5 2nd Edition (2022) retired Category 2. The current categories are 1, 3, 4, and 5. If you're working from older reference material that mentions Category 2, it's out of date.
The Four Categories at a Glance
Each category represents a different type of software and attracts a different level of validation effort. The underlying principle is risk-based: the more configurable or custom the software, the more evidence the regulator requires.
Category 1 — Infrastructure Software
Category 1 covers software not intended for direct GMP use — operating systems, network utilities, standard office applications, and database engines used purely as underlying infrastructure. These are not validated in the GMP sense; instead, the organisation manages them through IT controls and vendor support processes.
For most automation engineers, Category 1 items appear in the background of your project — the Windows Server running your SCADA historian, or the network switches in the control room. They need to be inventoried in your IQ, but they don't attract their own qualification protocols.
Category 3 — Non-Configured COTS
Category 3 applies to commercial off-the-shelf software used essentially as supplied, with minimal or no configuration. The key question is: has the software been modified beyond standard parameterisation? If the answer is no, Category 3 applies.
In automation practice, a standard SCADA or HMI platform used purely to display data from a PLC — with no custom scripting, no configured sequences, no application logic — might qualify as Category 3. In practice this is rare for GMP process control; most SCADA implementations involve enough configuration to push into Category 4.
Engineers frequently try to classify their configured Ignition or WinCC system as Category 3 to reduce document scope. If you've created screens, configured tags, written scripts, or built sequences — it's Category 4. The regulator will ask to see evidence of what was configured and how it was tested. Category 3 won't support that scope.
Category 4 — Configured COTS (Most PLC/SCADA Projects)
Category 4 is where the majority of industrial automation projects in pharma sit. It applies to standard commercial platforms that have been configured for specific GMP use — PLC programs written in TIA Portal or Studio 5000, SCADA applications built in Ignition or iFIX, HMI applications developed in WinCC or FactoryTalk View.
The configuration itself — your ladder logic, your function blocks, your SCADA screens, your alarm setpoints — is what attracts the validation effort. The regulator wants evidence that what you configured was designed correctly, implemented correctly, tested correctly, and performs correctly under real conditions.
Category 4 requires the full document lifecycle:
- User Requirements Specification (URS)
- Functional Design Specification (FDS)
- Hardware Design Specification (HDS)
- Factory Acceptance Test (FAT)
- Installation Qualification (IQ)
- Operational Qualification (OQ)
- Performance Qualification (PQ)
- Validation Summary Report (VSR)
Category 5 — Custom / Bespoke Software
Category 5 applies when software has been developed from scratch specifically for the GMP application — purpose-written code, custom applications, or significantly modified COTS where the modifications go beyond configuration. It attracts the maximum validation effort because the regulator cannot rely on the vendor's own testing of a standard product.
For most PLC/SCADA engineers, Category 5 means a Software Design Specification (SDS) is required in addition to the FDS, a formal software development lifecycle must be followed and documented, and unit testing evidence at the code level is expected. The scope is significantly larger than Category 4.
If you're programming in a standard IEC 61131-3 environment (TIA Portal, RSLogix, Studio 5000) and writing application logic for a specific process — that's Category 4. If you're writing Python, C#, or custom application code to run GMP processes — that's Category 5.
How to Classify Your System in Practice
The classification decision should be made at the start of the project — ideally documented in the Validation Plan — and agreed with the client's QA team before any documentation work begins. Changing category mid-project can mean scrapping or restructuring significant amounts of work.
The practical classification questions to ask:
- Is this standard commercial software used as-supplied with no modification? → Category 3
- Is this a standard platform (TIA Portal, Ignition, WinCC) that we have configured for this specific application? → Category 4
- Have we written custom code outside the standard platform environment? → Category 5
- Is this infrastructure software (OS, database engine, network tools) with no direct GMP function? → Category 1
Most systems have multiple components at different categories. A typical Siemens TIA Portal project might have: Windows Server (Cat 1), WinCC SCADA platform (Cat 3 base), configured WinCC application (Cat 4), and any custom VBScript or C# scripting (Cat 5). Each layer attracts its own validation scope.
The Validation Plan template includes a Software Categorisation section that walks through this decision systematically and produces a documented rationale. The Traceability Matrix is pre-structured to map each component category to its required document scope — automatically flagging any gaps.