What "Validated State" Means and Why It Matters for Upgrades
A SCADA system in a validated state is a system whose configuration, functionality, and performance have been documented, tested, and approved — and where the current operational configuration matches the approved baseline exactly. The validation is not a one-time event that permanently certifies the system. It certifies the system as it was at the point of validation. Any change that moves the operational configuration away from that baseline potentially invalidates the certification — which is why every change to a validated SCADA system must go through change control.
The phrase "potentially invalidates" is important. Not every change breaks the validated state. A cosmetic label correction on an HMI screen does not affect any GMP function. Adding a non-GMP historian tag does not affect any validated parameter. These changes are still subject to change control — because change control is how you prove the change was assessed, not because every change actually impacts validation. The change control process is the mechanism that documents the assessment and its conclusion, regardless of what that conclusion is.
The distinction between a change that impacts the validated state and one that doesn't is determined by the impact assessment — not by the engineer's intuition, and not by the size of the change. A one-line PLC logic modification that changes the alarm output behaviour of a GMP-critical function is a major change. A complete redesign of a non-GMP maintenance screen is a minor change. Size does not equal impact.
The Three-Type Classification
Most GMP change management systems for validated SCADA use a three-type classification. The types determine the approval authority, the documentation requirements, and the re-test scope. They are not a hierarchy of effort — they are a hierarchy of GMP impact.
The critical design feature of this classification is that the type is determined by impact, not by urgency or convenience. A security patch that corrects a critical vulnerability in the SCADA OS is typically a Type 3 emergency change because the risk of not patching immediately outweighs the process of waiting for full Type 1 documentation. But it is still classified as Type 1 for GMP impact purposes — the retrospective documentation must address all the Type 1 requirements: full impact assessment, re-test scope, hash update, and closure sign-off by QA Manager. The "emergency" designation affects the timing of documentation and approval, not the thoroughness of it.
The Impact Assessment — What It Must Cover
The impact assessment is Section 3 of the Change Control Request form (CCR-SYS-001). It is the technical core of every change control — the document that justifies the type classification and defines the re-test scope. A poorly written impact assessment is the most common reason change controls fail QA review. The impact assessment must answer seven questions, all of which must be explicitly addressed — not left blank or answered with "N/A" without justification.
- Which system components are affected? PLC, SCADA application, historian, network, HMI, security configuration, external interfaces — listed explicitly. "SCADA" as a single item is not sufficient.
- Does the change affect any GMP-critical function? Cross-referenced against the FDS functional descriptions. If FUNC-COND-001 (conductivity monitoring) is potentially affected, that must be stated.
- Does the change affect data integrity? This covers historian tag configuration, audit trail configuration, report generation, and certified copy function. Any change that touches the data pipeline from sensor to historian record must address this question.
- Does the change affect security? User account management, password policy, RBAC configuration, network firewall rules, remote access controls. A software version upgrade that patches a security vulnerability must address whether the new version changes any security behaviour.
- What re-test is required? The specific OQ test cases that must be re-executed — not "some OQ tests" — referenced by OQ test case ID. The impact assessment must identify which test cases are affected by the change scope. An upgrade that changes the SCADA historian component requires re-execution of the historian-related OQ tests. An upgrade that changes only the HMI rendering engine requires re-execution of HMI display tests, not historian tests.
- Does the software hash need to be recalculated? For any PLC code change, yes. The SHA-256 hash of the PLC project file must be recalculated and documented in the CCR implementation record and in the Engineering Lists hash log.
- Does the Traceability Matrix need to be updated? If the change adds, modifies, or removes a functional requirement, the TM must be updated before the change is closed.
SCADA Platform Version Upgrade — The Specific Considerations
A SCADA platform version upgrade (for example, moving from one major version to the next on Ignition, WinCC, InTouch, or FactoryTalk) is always a Type 1 change. The platform is a GAMP Category 4 component — a configured COTS product. Upgrading the platform version means the validated software configuration has changed. The GAMP 5 principle is that changes to Category 4 components require re-qualification of the affected functions, with the extent of re-qualification proportional to the scope of the vendor's changes.
The vendor release notes are the primary input to the impact assessment for a platform version upgrade. The assessment must identify which vendor changes affect GMP-relevant functions and which do not. A version upgrade that fixes a known bug in the historian compression algorithm is a direct impact on GMP data integrity — it requires re-execution of the historian completeness tests. A version upgrade that adds a new dashboard widget type is not a GMP impact — it does not affect any validated function.
Platform upgrades should be tested in a test environment before deployment to production. Where a dedicated test environment exists, the test environment runs the upgrade first, the GMP-relevant OQ test cases are executed in the test environment, results are reviewed and approved, and then the production upgrade proceeds. This is not re-running the full OQ on the test environment — it is running the specific test cases identified in the impact assessment, in an environment that mirrors production, to generate evidence before production is touched.
A vendor security patch is not a validation-free update just because the vendor issued it. Every vendor-supplied update to a validated SCADA platform — hotfix, security patch, service pack, or major version — is a Type 1 or Type 3 change that requires a CCR. Applying a vendor patch without a change control is a GMP deviation. The practical approach for routine security patches that have low GMP impact is to write a standing CCR template that covers the specific patch scope and type, reducing the documentation burden per patch while maintaining the change control record. QA and the system owner must agree on the standing CCR scope before the first patch is applied under it.
Keeping Production Running During an Upgrade
The question of how to upgrade a validated SCADA without stopping production has a straightforward structural answer: separate the upgrade window from the production window. In most continuous process environments, there is a maintenance window — typically a weekend or overnight period where production is paused for scheduled maintenance. Major SCADA upgrades should be planned to coincide with these windows. The change control timeline is built around the maintenance window: CCR raised and approved before the window, implementation during the window, re-test verification immediately after implementation and before the restart of production.
The sequence matters. Production must not restart after a Type 1 change until the re-test steps defined in the CCR have been completed and the results reviewed. Running a partial re-test and allowing production to restart "subject to completing the remaining tests tomorrow" is not a compliant approach. The re-test defines the acceptance evidence that the validated state has been restored — production is not authorised to run on an unverified validated state.
For systems that run continuously with no maintenance window (which is uncommon but exists for critical utilities), the approach is to perform the upgrade on a redundant system in a standby configuration, verify it fully, then switch over. This requires the system architecture to support redundancy — which must be a design consideration from initial commissioning, not retrofitted during the first upgrade project.
The Seven-Stage Change Process
The change management SOP defines a seven-stage process. Each stage has defined inputs, outputs, and responsible parties. No stage can be skipped for a Type 1 or Type 2 change — only the timing and formality differ for Type 3 emergency changes.
- Stage 1 — Initiation: Raise CCR-SYS-001 with the change description, proposed scope, and urgency. Assign a CCR reference number from the Change Control Log (CCL-SYS-001). Submit to Technical Reviewer.
- Stage 2 — Technical Review: Automation Engineer completes the technical assessment. Determines change type. Identifies all affected components. Estimates re-test scope and documents in Section 3 of the CCR.
- Stage 3 — Impact Assessment: Complete all seven impact assessment questions. Determine validation impact, re-test scope, hash update requirement, TM update requirement, and training requirement.
- Stage 4 — QA Review and Approval: QA reviews the impact assessment. Approves Type 2 changes directly. Escalates Type 1 to QA Manager. For Type 3: verbal QA approval is acceptable — document the QA contact name, time, and date in the CCR.
- Stage 5 — Implementation: Implement the change only after approval. Document all implementation steps in CCR Section 5. Update the software version tag per the SDS naming convention. Update the validated configuration archive — never overwrite the previous version.
- Stage 6 — Verification: Execute the re-test steps defined in the approved CCR. Document results. If any re-test step fails, raise a deviation in the Master Deviation Ledger (MDL-SYS-001) and do not close the CCR until the deviation is resolved.
- Stage 7 — Closure: Complete CCR Sections 5 and 6. Update the Change Control Log. Update Engineering Lists if tag, BOM, or network register changes were made. Update the Traceability Matrix if required. Recalculate and record the new SHA-256 hash. QA signs CCR closure. Production restart authorised.
The SOP-CM-SYS-001 documents the full seven-stage change management process, the three-type classification with definitions and examples, the impact assessment requirements (seven questions in Section 3 of CCR-SYS-001), the version tag format ([SYS]_[Version]_[YYYYMMDD]_[CCR-XXX]), the SHA-256 hash chain maintenance requirement (three-point chain from FAT through each CCR), and the emergency change handling procedure (verbal approval, 24-hour retrospective documentation, QA Manager written approval). The CCR-SYS-001 form provides the structured template for all three change types — with pre-defined sections for impact assessment, implementation steps, re-test results, and closure sign-offs. The CCL-SYS-001 Excel workbook is the change control register — sequential CCR numbering, status tracking, and open/closed summary view. The MDL-SYS-001 Master Deviation Ledger captures any deviations raised during re-test execution, with the CCR cross-reference required for closure. The change control system ties directly to the SDS-SYS-001 version control approach: every Type 1 change increments the software version tag, and the new hash is recorded as a new row in the Engineering Lists hash log — never modifying the previous row.