The Three Change Types
Not all post-go-live PLC changes carry the same regulatory weight. The change management framework for validated systems defines three types, each with a distinct approval path and evidence requirement. The critical decision — made at the beginning of every change — is correctly classifying the change type. A Type 1 change handled as Type 2 is a GMP deviation regardless of how well the technical work was done.
| Type | Definition | PLC Examples | Approval Required |
|---|---|---|---|
| Type 1 — Major | Affects validated state, GMP functionality, data integrity, security, or software version | PLC logic change, alarm setpoint modification outside validated range, new I/O module, interlock modification | Full impact assessment + QA Manager approval + re-test before implementation |
| Type 2 — Minor | No GMP impact — cosmetic or non-critical change | HMI label correction with no logic change, adding a non-GMP historian tag, comment update in code | Impact assessment confirming no GMP impact + QA acceptance. No re-test required. |
| Type 3 — Emergency | Urgent — required to restore availability or prevent safety risk | Critical hardware failure replacement, security vulnerability patch requiring immediate application | Verbal QA approval + implementation + retrospective full CCR documentation within 24 hours |
The most common misclassification is calling an alarm setpoint change Type 2 when it is Type 1. An alarm setpoint that falls within the validated operating range does not require re-test — but changing a setpoint outside the validated range is a Type 1 change even if the technical magnitude is small. The validated range was defined in the OQ acceptance criteria. Changing a setpoint beyond that range changes what was validated. A new test — even a single OQ test case executed as a standalone verification — is required before the new setpoint can be used in GMP production.
The Seven-Stage Change Control Process
Every Type 1 and Type 2 change follows a seven-stage process. The stages are not optional, and they are not interchangeable in sequence — implementation before approval is an unauthorised change regardless of the technical justification.
Stage 3 — The Impact Assessment
The impact assessment is the technical core of the change control process. It is where the automation engineer determines the full scope of what the change touches — and therefore what evidence needs to be produced. The CCR impact assessment checklist covers ten areas that must each be evaluated:
- Does the change affect any GMP-critical functionality? (If yes → Type 1)
- Does the change affect the audit trail — either which events are captured or the data recorded per event?
- Does the change affect access control — user roles, permission levels, or authentication behaviour?
- Does the change modify any alarm setpoints, and if so, are the new setpoints within the validated operating range?
- Does the change modify any interlock logic, thresholds, or safe-state outputs?
- What re-test is required? List specific test cases from the original OQ that must be re-executed.
- Does the PLC software version (and SHA-256 hash) change? Even cosmetic changes in the programme create a new hash.
- Does the Traceability Matrix require updating to reflect new or modified requirements?
- Does the Engineering Lists workbook require updating (new tags, modified I/O addresses, alarm changes)?
- Does any affected function require operator retraining before the change goes live?
The most important output of the impact assessment is the re-test scope. For most Type 1 PLC changes, full re-qualification is not required — only the specific functions affected by the change need to be re-tested. A change to the conductivity alarm setpoint requires re-testing the conductivity alarm test cases from the OQ. It does not require re-running the temperature control tests, the access control tests, or the backup and recovery verification. The impact assessment defines this boundary explicitly, and QA approves the boundary before implementation.
Version Control Evidence — What Must Be Produced
Every Type 1 and Type 2 change that touches the PLC programme produces a new software version, regardless of the magnitude of the change. The version control requirements for post-go-live changes are identical to those during the initial validation: tag before loading, not after.
The SHA-256 hash is calculated from the compiled PLC project archive. It is the cryptographic fingerprint that proves the code in the controller matches the approved version in the archive. For post-go-live changes, the new hash is recorded in the CCR implementation record and in the Engineering Lists hash log. The three-point hash chain from FAT through every subsequent CCR must remain intact — any break in the chain (a missing hash entry, a hash that doesn't match the archive) is treated as a deviation.
Risk-Based Re-Test Scope
The risk assessment for a post-go-live change is a scaled version of the original GAMP 5 risk assessment — the same scoring methodology applied to the specific change. A change with high severity impact (affects GMP-critical data or patient safety) and high probability of introducing an error (complex logic change in a function with many dependencies) requires a broader re-test scope than a change with low severity and low probability.
The re-test evidence does not need to be a new, standalone protocol. For straightforward Type 1 changes, the re-test can be documented as a protocol amendment — a controlled addendum to the OQ that lists the specific test cases being re-executed, references the CCR, and captures the results. The amendment is approved by QA before execution and signed by the tester and QA witness after completion. This approach is proportionate and does not require the overhead of a full re-qualification package.
Emergency Changes — The 24-Hour Rule
Type 3 Emergency changes are the highest-risk category from a compliance perspective because the pressure to fix first and document later is highest exactly when you can least afford a documentation shortcut. The emergency change procedure is designed to allow rapid response while maintaining a defensible audit trail.
The non-negotiable elements of a Type 3 change are: verbal QA approval before implementation (name of QA contact, time, and date recorded on a paper log), real-time documentation of every action taken during implementation (also on the paper log), and completion of a full CCR within 24 hours that includes transcription of the paper log, the verbal approval record, post-change verification results, and written QA sign-off. The 24-hour window is absolute — a Type 3 change that is not documented within 24 hours becomes an undocumented system change, which is a significantly more serious finding.
The temptation to implement a fix under production pressure and deal with the paperwork later is well-documented in FDA warning letters. The retrospective documentation problem is not just that QA has to sign off on something that already happened — it is that the documentation cannot accurately reflect what was assessed before the change when it is written after. The impact assessment signed after the fact is an opinion on what the engineer thinks they considered at the time. The one signed before implementation is evidence of what was actually evaluated. Regulators understand the difference.
The SOP-CM-SYS-001 Change Management SOP defines the three change types with worked examples, the 7-stage process flowchart with stage-by-stage actions, and the 10-item impact assessment checklist in Stage 3. Section 4 documents the software version control requirements: the version tag format ([System ID]_[Version]_[YYYYMMDD]_[CCR-XXX]), the SHA-256 hash recalculation requirement, the validated archive update procedure, and the three-point hash chain maintenance rule. The CCR-SYS-001 template provides the impact assessment form (Section 3), implementation record with version tag and hash fields (Section 5), and the approval and closure signatures (Section 6). Together these two documents contain everything required to execute and close a post-go-live change correctly.