What Cat 4 Means for Documentation
A GAMP 5 Category 4 system is a configured product — commercial off-the-shelf software that is configured (not custom coded) to meet the intended use. Common examples in pharmaceutical automation include SCADA platforms (Ignition, WinCC, FactoryTalk), DCS systems, historian software, and building management systems. The key characteristic is that the vendor has already validated the base product; what needs to be validated is how it has been configured for your specific application.
This distinction matters for documentation because Cat 4 sits between the lighter Category 3 approach (infrastructure software, essentially no custom configuration to validate) and the heavier Category 5 approach (custom software, full code review and software design specification required). For Cat 4, the required document set is substantial but focused: you need to document what was configured and why, verify the configuration works as intended, and maintain evidence that the validated configuration is what is running in production.
Category 5 requires a Software Design Specification documenting the custom code architecture, a code review, and version control of the custom programme. Category 4 does not — the vendor's code is not your responsibility to document or review. What you document for Cat 4 is the configuration: tag databases, alarm setpoints, user roles, screen layouts, historian settings, report definitions. The FDS and URS still apply to both. The SDS is Cat 5 only.
The Full Document Set
The table below is the complete validation document pack for a Cat 4 system covering both EU GMP Annex 11 and 21 CFR Part 11 environments. Documents marked as core are required on every Cat 4 project. Context-dependent documents apply based on the specific system, site requirements, and regulatory jurisdiction.
Phase 1 — Planning Documents
These are produced before design begins. Nothing else can start until these are approved.
Project Quality Plan (PQP)
The PQP defines the quality framework for the validation project — the regulatory approach, the document matrix, the RACI, the phase gate criteria, and the non-conformance handling procedure. It is the master document that tells everyone on the project what the rules are. QA approves the PQP before the URS can be drafted. On smaller projects the PQP is sometimes scoped down significantly or folded into the Validation Plan, but on any project with significant QA involvement it is a standalone document.
Validation Plan (VP)
The Validation Plan describes the specific strategy for this system — the GAMP 5 category justification, the validation scope, the V-model phase structure, the test approach, the roles and responsibilities, and the success criteria. The VP references the PQP for the overarching quality framework and adds the system-specific strategy. It must be approved by QA before design documents are issued for review.
Risk Management Plan (RMP)
The RMP defines the risk methodology — scoring scales, acceptance criteria, the risk register structure, and how risk assessment outputs feed into test coverage. The RMP is the companion document to the Risk Assessment (RA) workbook. Together they determine which functions get tested, at what depth, and with what acceptance criteria.
Phase 2 — Design Documents
Produced after planning is approved, before any testing begins. The qualification protocols are written against these documents.
User Requirements Specification (URS)
The URS is the anchor document for the entire validation — every test case in every protocol must trace back to a URS requirement. It defines what the system must do from the user's perspective, in measurable, testable terms. For Cat 4, the URS covers process control requirements, alarm management, data management, user access control, interface requirements, and applicable regulatory requirements. It does not describe how the system implements these — that is the FDS.
Functional Design Specification (FDS)
The FDS translates URS requirements into specific configured functions — the control logic, the alarm table with setpoints and classifications, the HMI screen architecture, the user role access matrix, the historian tag configuration, and the data integrity mechanisms. For Cat 4, the FDS describes the configured behaviour of the SCADA platform, not the underlying application code. Every FDS function references its URS requirement. The FDS is the primary design document that FAT test cases are written against.
Hardware Design Specification (HDS)
The HDS documents the physical infrastructure — PLC hardware, server hardware, network topology, instrumentation, panels, and the validated configuration baseline. For Cat 4 systems with significant hardware (a SCADA with multiple servers, a complex network, or a large panel), the HDS is a substantial document. For simpler systems it may be abbreviated, but the validated hardware configuration must be documented somewhere.
Supplier Assessment Questionnaire and Report (SAQ / SAR)
For Cat 4 systems, GAMP 5 requires a supplier assessment proportionate to the risk of the configured product. The SAQ is sent to the SCADA vendor; the SAR summarises the findings and risk assessment. The supplier assessment outcome feeds into how much reliance you can place on the vendor's own testing and documentation versus how much independent verification you need to perform during IQ and OQ.
Lifecycle Registers — Active Throughout All Phases
These are not phase-specific — they are maintained from project kick-off through to periodic review and referenced continuously across all phases.
| Register | What It Tracks | When It Closes |
|---|---|---|
| RA Workbook (RASYS001) | Risk assessment — function-level FMEA with RPN scoring, risk-based test coverage | Updated at each lifecycle phase; never truly closed |
| Traceability Matrix (TMSYS001) | URS req → FDS function → test case → result. Confirms every requirement is tested. | Complete at VSR sign-off; gaps must be resolved or risk-accepted |
| Master Deviation Ledger (MDLSYS001) | All protocol deviations — category, root cause, resolution, re-test reference | All open deviations closed before VSR can be signed |
| Change Control Log (CCLSYS001) | All change control records post-baseline — CCR reference, type, status | Ongoing throughout operational life |
| Engineering Lists (ELSYS001) | Instrument list, I/O list, historian tag list, alarm list, network register, BOM, calibration register | Updated at each design change; source of truth for all tag cross-references |
Phase 3 — Qualification Protocols
Written against the approved design documents, executed in sequence, with each protocol requiring its predecessor to be complete and all open deviations resolved before execution begins.
- FAT Protocol — executed at the supplier facility using simulated I/O. Tests all functional requirements with forced or injected signals. Includes Force Log and Force Audit. Leveraged by the OQ to avoid repeating all tests on site.
- SAT Protocol — executed on site after installation. Tests hardware connectivity with live field instruments. Verifies the FAT-baseline software hash. Does not re-run the full functional suite — focused on what could only be verified with live connections.
- IQ Protocol — documents what was installed: hardware configuration, module firmware, software version, network configuration, calibration certificates, OS hardening. The IQ is about evidence of the installed state, not functional testing.
- OQ Protocol — functional verification on the installed system. Boundary testing, negative testing, alarm verification, audit trail integrity, access control. Leverages FAT evidence for tests that are not site-specific. This is the core validation activity.
- PQ Protocol — performance qualification, if applicable. For process monitoring systems, this is the extended performance monitoring period demonstrating the system performs consistently in actual operational conditions.
Phase 4 — Closure and Operations
Validation Summary Report (VSR)
The VSR closes the validation lifecycle. It summarises the results of all qualification phases, confirms all deviations are resolved, confirms the traceability matrix is complete, records the validated configuration baseline, and authorises the system for GMP use. The VSR cannot be signed until the TM is closed, the MDL is cleared of open deviations, and the VSR author has confirmed the system configuration matches the qualified baseline.
SOPs and Training Records
The system cannot be handed over to operations without approved SOPs covering system operation, alarm response, change control, and periodic review. The training record (TRF) documents that all users who will operate the system in GMP production have completed training against these SOPs and have been assessed as competent. Training completion is a prerequisite for OQ execution — not an afterthought.
The QLean Automation GAMP 5 Validation Framework Pack includes all 29 documents in this pack — PQP, VP, RMP, URS, FDS, HDS, SAQ, SAR, FAT, SAT, IQ, OQ, PQ, VSR, SOP-CM, SOP-ADMIN, SOP-OPS, SOP-PR, RBP, CCR, TRF, PRR, plus the five Excel registers (RA workbook, Traceability Matrix, MDL, Engineering Lists, Change Control Log). Every template is pre-structured with the sections, appendices, and worked examples described in this article — adapted for a configurable SCADA system in a pharmaceutical environment.