Why the Category Decision Matters So Much
In GAMP 5, the software category is not a label — it is the input that determines your entire validation document scope. Get it wrong and you either over-document (wasting weeks on an SDS that was never needed) or under-document (missing a qualification step that a regulator will flag).
The classification is applied at the component level, not the system level. A typical PLC/SCADA system contains components of several different categories. The Validation Plan must classify each one independently and state the rationale. An inspector's first question is often: "What was the basis for your category assignment?"
The current categories under GAMP 5, 2nd Edition (2022) are 1, 3, 4, and 5. Category 2 was retired in the 2022 edition — if your documentation references it, update it.
A system running TIA Portal PLC logic (Cat 4), a configured Ignition SCADA (Cat 4), and Windows Server OS (Cat 1) is not "a Category 4 system." It is a mixed-category system. Each component is classified and documented independently. The QLean Validation Plan template (VP-SYS-001) has a per-component classification table for exactly this purpose.
The Five Questions
Work through these questions for each software component in your system. They resolve every classification edge case, including the ones that trip up experienced engineers.
GMP function means the software is involved in controlling, monitoring, or recording a process that affects product quality, patient safety, or regulatory compliance. Ask: if this software failed or behaved incorrectly, could a GMP batch record be wrong, could a safety interlock fail, or could out-of-spec product reach a patient?
Stop here → not in scope. Document the exclusion rationale in your VP scope boundaries. Examples: office suite software, project management tools, CAD packages on engineering workstations.
Continue to Q2. This component must be classified and its validation requirements determined.
Infrastructure software provides foundational computing services that other software runs on top of. It is not configured or modified for the GMP application — it is installed and maintained per vendor specifications. The key test: does your engineering team configure this software for GMP purposes, or does the GMP software simply run on top of it?
Category 1. OS, database engines, network OS, firmware on PLCs/switches. IQ record only — version, patch level, installation verification. No functional testing.
Continue to Q3. The software is a GMP application, not just a platform.
The critical word is configuration. True Category 3 means the software performs its GMP function without any project-specific setup beyond basic installation parameters. No custom screens, no configured tags, no application scripts, no sequences, no alarm definitions created for this project. In practice this is rare in GMP process control — almost any meaningful use of a SCADA or historian platform involves configuration.
Category 3. Used without project-specific configuration. Qualification based on vendor documentation and testing. Examples in pharma: a standard barcode reader used without configuration; a validated laboratory instrument with standard software.
Continue to Q4. Configuration for the specific GMP application has occurred.
This is the question that separates Category 4 from Category 5. Category 4 means you have used a commercial platform (TIA Portal, Studio 5000, Ignition, WinCC, iFIX, FactoryTalk) and configured it for the specific application using that platform's intended configuration environment. You have written PLC logic in IEC 61131-3 function blocks or ladder, built SCADA screens in the vendor's editor, configured historian tags. You have not written software outside of the platform's standard boundaries.
Category 4. The most common classification for PLC/SCADA systems. Requires FDS. Configuration testing in FAT and OQ. Vendor documentation leveraged where applicable.
Continue to Q5. Custom development has occurred beyond the standard platform boundaries.
Category 5 applies when software has been purpose-written for the GMP application — Python scripts, C# applications, custom middleware, or heavily modified COTS where the modifications go beyond configuration into custom code development. It also applies when a standard platform has been extended with custom-developed add-ons, drivers, or modules that weren't part of the original commercial product.
Category 5. Maximum validation scope. Requires SDS in addition to FDS. Full software development lifecycle documentation. Code review before FAT. Unit testing evidence expected.
Re-examine Q4. Most ambiguous cases resolve back to Cat 4 with a strong written rationale. Document the reasoning thoroughly in VP Section 3.2 — the inspector will ask.
What Each Category Demands
The category determines the document set. Here is what each classification commits you to in a PLC/SCADA context:
Applied to a Real System
Here is how a typical purified water PLC/SCADA system classifies across all its software components, as it would appear in VP-SYS-001 Section 3.2:
| Component | Category | Classification Rationale | Validation Implication |
|---|---|---|---|
| PLC application (TIA Portal V18) | Cat. 4 | Standard IEC 61131-3 application written in TIA Portal's native environment using FB, FC, and DB blocks. Not bespoke code outside the platform. | FDS required. FAT + OQ test coverage. No SDS mandatory, but recommended for complex sequences. |
| SCADA application (Ignition 8.1) | Cat. 4 | Configured commercial SCADA platform — project-specific screens, tags, alarm definitions, scripts, and report templates built within Ignition's standard designer environment. | FDS required. Configuration testing in FAT and OQ. Vendor documentation for Ignition platform leveraged per VP Section 7. |
| Process historian (Ignition Tag Historian) | Cat. 4 | Configured standard historian module — project-specific tag configuration and retention settings. No bespoke development. | IQ and OQ testing for GMP-critical functions (data recording, retention, gap detection). Vendor documentation leveraged. |
| Windows Server 2022 (OS) | Cat. 1 | Standard commercial OS. Not configured for GMP purposes — installed per vendor spec. The SCADA application runs on top of it; the OS itself performs no GMP function. | IQ record only — OS version, patch level, installation verification. No functional testing. |
| SQL Server 2019 (database engine) | Cat. 1 | Infrastructure database engine used as-supplied by the historian. The historian application (Cat 4) is tested for all data recording and retention functions. | IQ record only. Historian application testing covers all GMP-relevant database behaviour. |
| Custom Python integration script (LIMS interface) | Cat. 5 | Purpose-written Python script transmitting QC results from SCADA historian to LIMS. Not part of any commercial platform — bespoke code developed for this project. | SDS required covering script logic and data mapping. Code review before FAT. Unit testing of transformation logic. OQ testing of end-to-end data transmission and error handling. |
The Three Misclassifications That Cost the Most
Claiming a configured Ignition, WinCC, or iFIX application is Category 3 to reduce document scope. If you have created screens, configured tags, written scripts, or defined alarms — it is Category 4. A regulator will ask to see what was configured and how it was tested. Cat 3 cannot support that scope and the inspection finding will be worse than the documentation you avoided.
Classifying all PLC application code as Category 5 because "we wrote it ourselves." Writing application logic in TIA Portal's standard FBD/LAD/ST/SCL environment is Category 4 configuration, not Category 5 bespoke development. Cat 5 applies when you have written code outside the standard platform boundary — Python, C#, custom extensions. Over-classifying as Cat 5 inflates the document scope with an SDS you may not need and triggers a code review requirement that may not be warranted.
Declaring the entire system "a Category 4 system" and applying that label to every component including the OS, database engine, and any custom scripts. Classification must be per component. An inspector reviewing your VP and seeing "System category: 4" with no component breakdown will have follow-up questions.
VP-SYS-001 Section 3.2 includes a pre-formatted per-component classification table with columns for Component, GAMP Category, Classification Rationale, and Validation Implication. The five examples in that table cover exactly the PLC/SCADA/Historian/OS/DB engine mix shown above. You fill in your specific product names and rationale — the structure and the inspector-facing format are already there.