GAMP 5 PLC validation is the risk-based process of showing that a PLC-controlled system in a regulated pharmaceutical plant does what it is supposed to do, every time, and that records it creates are trustworthy. It follows ISPE's GAMP 5 guide: specify what the system must do, assess risk, configure or code it, test against the specifications in proportion to the risk, and keep it in a validated state through controlled change. For the controls engineer, that changes the paperwork more than the code.
What GAMP 5 Second Edition changed
ISPE published the GAMP 5 Guide Second Edition in July 2022. It puts more weight on critical thinking by subject-matter experts, supports iterative and incremental development, and discusses FDA's computer software assurance work, with new appendices on topics such as AI and machine learning, cloud and open source (ISPE GAMP 5 Second Edition). The direction is clear: less testing for its own sake, more effort where patient risk and product quality are affected.
GAMP庐 5 Guide, 2nd Edition: Why It's Needed
ISPE
This video is hosted on YouTube. Playing it loads content from Google, which may set cookies.
Watch on YouTubeWhere a PLC fits in GAMP software categories
| Category | Example in a PLC system | Validation effort |
|---|---|---|
| Category 1: infrastructure | Operating systems, network software | Record and control versions |
| Category 3: non-configured | Firmware, standard instrument software | Verify it works as intended |
| Category 4: configured | SCADA configured with standard objects | Verify configuration against specs |
| Category 5: custom | Application PLC code written for the process | Full lifecycle: specs, review, testing |
Most PLC application code written for a specific process is treated as custom software, so it gets the most attention: a design specification, code review against standards, and structured testing. Using a tested library of device objects, for example a validated in-house library or Rockwell's PlantPAx library, reduces the custom part and therefore the testing burden. We cover library choices in Studio 5000 programming standards.
21 CFR Part 11 and Part 211: what touches the controls design
If the system creates electronic records that are used for GMP decisions, 21 CFR Part 11 applies. Section 11.10 requires, among other controls, validation, limited system access, secure computer-generated time-stamped audit trails, operational and authority checks, and training (eCFR 21 CFR 11.10). For drug manufacturing equipment, 21 CFR 211.68 requires automatic and electronic equipment to be routinely calibrated, inspected or checked under a written program, changes to be made only by authorized personnel, and backups to be maintained (eCFR 21 CFR 211.68).
- User accounts and roles on HMI and SCADA, no shared logins for GMP actions.
- Audit trails for setpoint changes, recipe edits and alarm acknowledgments, stored where they cannot be edited.
- Time synchronization across PLC, HMI and historian so records line up.
- Controlled access to the PLC program, with change management and backups.
- Batch records that come from the system, not from retyped values.
The documents a controls engineer actually writes
- User requirements (URS): written by the client, reviewed by us for testable wording.
- Functional specification: what the system does, mode by mode, including alarms and interlocks.
- Design specification: architecture, I/O, software structure, library objects, network.
- Code review record: code checked against the design and the coding standard.
- Test protocols: FAT, SAT and the verification steps that support IQ and OQ.
- Traceability matrix: each requirement linked to design and test.
For batch processes, structure the code and specifications around ISA-88 from the start. Its model of procedures, unit procedures, operations and phases maps cleanly onto both the code and the test cases (ISA-88). A phase that is specified, coded and tested as one unit is much easier to validate than logic spread across routines.
Common mistakes on pharma controls projects
- Specifications written after the code. The traceability matrix then documents what was built, not what was required, and auditors notice.
- Untestable requirements. Phrases like "the system shall be user friendly" cannot be tested. Every requirement needs a measurable pass criterion.
- Shared HMI logins. Convenient during commissioning, but they break attributable records and are hard to remove later.
- Late alarm design. Alarm lists finalized during SAT lead to protocol changes and deviations. Freeze them with the functional spec.
- Unplanned firmware updates. A controller or HMI firmware change after validation is a change like any other, and needs assessment.
None of these is a code quality problem. They are planning problems, and they are cheapest to fix in the first weeks of the project, when the specifications are still being written.
How simulation reduces validation effort
Running the PLC code against a simulated process before FAT turns the formal test into a confirmation rather than a debugging session. Failed test steps during executed protocols create deviations, and deviations create paperwork and delay. With a model, we dry-run every protocol step, fix the code and the protocol wording, and only then execute formally. The model itself is not part of the validated system, but it makes the validated tests cleaner. Our guide to virtual factory acceptance testing shows the method.
Our controls engineering team writes GAMP-aligned specifications and code for pharma skids and lines, and our virtual commissioning service dry-runs the test protocols before FAT. Validation strategy and approval remain with your QA team. To discuss a project, contact us.
