Change Control for
Validated PLC/SCADA
Systems: The Complete Guide

Why Change Control Exists — and Why It Catches Engineers Off-Guard

Once a system is validated, it exists in a controlled state. Every document, every software version, every hardware component has been verified and recorded. Any change to that state — however small — must be formally assessed before it's made. This is change control, and it is one of the most common areas where automation engineers on pharma projects make costly mistakes.

The surprise isn't that change control exists. It's the scope of what triggers it. Engineers accustomed to modifying PLC programs in response to operational feedback find that in a validated GMP environment, even a comment change in a function block requires a documented impact assessment and may require re-qualification testing before the system can be released back to production.

What Triggers a Change Control

The first question engineers always ask is: what changes actually require a formal change control? The answer depends on the system's validation status and the nature of the change. As a practical guide:

The Change Control Request Process

Every change starts with a Change Control Request (CCR) — a formal document that describes the proposed change, the reason for it, and the initial impact assessment. The CCR is reviewed and approved before any work begins. The process:

• Initiate — Engineer raises CCR describing the proposed change and its business justification
• Impact assessment — Engineering and QA assess which validated documents are affected (URS, FDS, risk assessment, test protocols) and whether requalification testing is needed
• Approve or reject — QA approves the CCR and the defined scope of requalification before work starts
• Implement — Change is made exactly as described in the approved CCR. Deviations from the CCR require a new CCR
• Test — Requalification testing is executed and documented per the approved scope
• Close — CCR is closed with references to test evidence. Updated documents are re-approved

Writing a Useful Impact Assessment

The impact assessment is the core of the CCR. It answers three questions: which validated documents does this change affect? Does the change require requalification testing? If so, what is the minimum test scope that demonstrates the change is safe?

For a PLC logic change, the impact assessment should identify the affected function blocks, the URS requirements they implement, the OQ test cases that tested those requirements, and whether those test cases need to be re-executed. A change that adds a new interlocking condition to an existing alarm function might only need the three specific OQ test cases covering that alarm — not a full regression of the entire OQ.

Version Control is Part of Change Control

Every approved change must be reflected in updated document versions. The PLC program that runs the validated system must have a version number that matches the version recorded in the IQ. The SCADA application must match. If an inspector finds a discrepancy between the deployed software version and the validated version record, the entire validation is called into question.

This means maintaining a Change Control Log — a register of every CCR raised, approved, and closed — with references to the resulting document version numbers. The log is the audit trail of how the system evolved from its validated baseline.