EN-GUIDE-07 · PHARMACEUTICAL AUTOMATION CHANGE
Pharma Automation Change Control: Impact, Validation, Rollback & Quality Release Evidence
A PLC download, SCADA edit, recipe revision, alarm adjustment or server change can alter product, batch, facility, record and recovery behavior at the same time. Fix the operating identity first, assess the full boundary, preserve the approved baseline, execute only the authorized scope and return to use only after objective verification, deviation review and named quality release.
DECISION SUMMARY
A successful download is not a validated or released change.
OBSERVABLE TRIGGERS
Conditions that require a controlled change boundary
- A PLC, HMI, SCADA, historian, MES interface, recipe, alarm, network, account, server or infrastructure revision is proposed.
- A production fault is being “fixed” online while an affected batch, room, utility or record boundary remains unclear.
- The running application, source project, backup, approved version and as-built field state do not match.
- A vendor package or cybersecurity update changes services, ports, time, identity, authentication, logging, backup or recovery behavior.
- The change test proves one intended function but not interlocks, alarms, records, failure behavior, restart or rollback.
- Implementation completes while deviations, temporary modes, open items or quality release remain outside the handover.
STOP-WORK CONDITIONS
Hold implementation or return to service when any critical boundary is uncontrolled.
Product, batch, material, room, equipment, utility, recipe, process step or quality owner cannot be fixed.
Energy, contamination control, interlock, permit, access, automatic action or affected personnel is unresolved.
Approved source, running version, parameters, data, licenses, certificates, credentials, backup or restore proof is missing.
Product, process, facility, utilities, records, interfaces, security, alarm, batch or validation impact is omitted.
Original audit trail, electronic record, event, trend, configuration or time provenance may be overwritten or obscured.
Deviation, failed test, temporary state, rollback decision or named quality approval remains open.
Maintain the authorized hold, protect raw records and configuration evidence, and return the next decision to the named site authority. This guide does not authorize online edits, access, bypass, energization, contamination-control changes, validation approval or batch release.
DATA TO COLLECT
Make the change traceable to one operating identity and one approved boundary.
| Evidence group | Minimum record | Decision supported |
|---|---|---|
| Operating identity | Site, product, batch, room, equipment, utility, PLC/HMI/SCADA/MES, recipe, mode, status, time source and owners | Fixes the exact operating and quality boundary. |
| Change request | Problem, intended outcome, requirement, reason, urgency, affected assets, exclusions and approvals | Prevents an undefined “small edit.” |
| As-found baseline | Running and source versions, checksums, hardware/firmware, settings, accounts, network, field state, backups and restore proof | Establishes what can be compared and recovered. |
| Impact and risk | Product/batch, CPP/CQA, facility/utility, safety, records, alarm, interface, security, maintenance, training and regulatory impact | Defines review depth and evidence owners. |
| Implementation plan | Authorized files, commands, sequence, access, outage, prerequisites, hold points, witnesses, abort and rollback | Bounds execution before the first change. |
| Verification plan | Requirement traceability, normal/abnormal/restart tests, data capture, expected results, acceptance source and witnesses | Separates evidence from assumption. |
| Actual execution | Who/when/where, files and checksums used, commands, observed responses, deviations and original records | Shows what actually changed. |
| As-left and release | Final versions/settings, backup/restore, open items, temporary states, restrictions, monitoring, batch impact, quality decision and owners | Defines the exact state returned to use. |
SIX EVIDENCE GATES
Keep implementation success separate from GMP release.
| Gate | Required evidence | Named output |
|---|---|---|
| 1. Identity | Product/batch/room/equipment/utility/system/recipe/status/time and decision owners agree. | One fixed operating boundary. |
| 2. Impact | Product, process, facility, safety, records, interface, security, validation and batch effects are reviewed. | Approved scope, exclusions and review depth. |
| 3. Baseline & rollback | As-found state, approved source, backups, restore method, dependencies, abort triggers and rollback tests are available. | Recoverable approved starting state. |
| 4. Controlled implementation | Authorized files, people, access, sequence, hold points, actual actions and independent witnesses are recorded. | Traceable executed change. |
| 5. Verification & deviation | Requirements, normal/abnormal/restart behavior, alarms, records, interfaces, data integrity and failures are objectively reviewed. | Test result plus resolved or controlled deviations. |
| 6. Quality release & as-left | Final configuration, restore proof, batch/product impact, restrictions, monitoring, open items and named approvals are accepted. | Released scope, residual controls and ownership. |
EIGHT-STEP CHANGE PROCEDURE
Build a reviewable evidence chain before touching the system.
- Fix the operating and batch identity.
Name the product/batch, process step, room, equipment, utilities, automation layers, recipe, mode, event window and decision owners.
- Preserve the as-found state and raw records.
Capture running and source versions, checksums, settings, network/interfaces, accounts, audit trails, alarms, events, trends and field conditions.
- Translate the request into approved requirements.
State the intended outcome, affected functions, exclusions, acceptance-source references and evidence owners without inventing universal criteria.
- Assess cross-system and GMP impact.
Review product, batch, process, facility, utilities, safety, contamination control, records, data integrity, security, training and validation status.
- Prove rollback before implementation.
Verify backups, restore dependencies, licenses/certificates/credentials, data compatibility, abort triggers, safe state and authority to decide rollback.
- Execute only the authorized scope.
Use the approved files and sequence, record actual people/actions/times, stop at hold points and preserve unexpected evidence.
- Verify requirements, failure behavior and records.
Test normal, abnormal, alarm, interlock, interface, restart and recovery paths; compare expected and actual results and control every deviation.
- Release and hand over the as-left state.
Reconcile final versions/settings, restore proof, open items, temporary states, monitoring, batch impact and accountable engineering/CSV/quality acceptance.
EXPERT REVIEW
Questions before a technically successful change becomes operating authority
- Does the live system, approved source, as-found evidence and change request describe the same equipment and revision?
- Can the site explain the product, batch, process, facility, data and validation impact of every changed object?
- Are audit trails, electronic records and time provenance preserved before any reset, migration or restore?
- Does rollback include data, interfaces, licenses, certificates, accounts and field state rather than only a project file?
- Were abnormal, restart, alarm, interlock, interface and record behaviors tested as required by the approved plan?
- Are deviations, temporary modes, restrictions, monitoring and owners visible to the quality release decision?
AS-LEFT HANDOVER
Transfer the operating state that actually exists.
Change ID, product/batch, room/equipment/utility, system/recipe, event window, roles and approvals.
As-found/as-left versions, checksums, backups, settings, audit trails, records, interfaces and physical state.
Requirement traceability, actual tests, failures, deviations, batch/product review and validation status.
Temporary states, restrictions, monitoring, open items, rollback readiness, next review and accountable owners.
The PDF preserves the gates, collection table, procedure, sources and application limits.
OFFICIAL PRIMARY SOURCES
Use each source within its published scope and jurisdiction.
- eCFR 21 CFR Part 211 — U.S. current good manufacturing practice for finished pharmaceuticals
- FDA — Process Validation: General Principles and Practices
- FDA — Data Integrity and Compliance With Drug CGMP: Questions and Answers
- European Commission — EudraLex Volume 4, including Annex 11 and Annex 15
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security
FDA guidance and eCFR describe United States regulatory or guidance scope; EudraLex Volume 4 describes European Union GMP legislation and guidance; NIST SP 800-82 is OT security guidance. They are not interchangeable national rules, site validation protocols, universal alarm or process values, or batch-release authority. Confirm current country and product requirements, marketing authorization, pharmacopoeia, AHJ, site quality system, approved SOPs, validation/qualification strategy, permits, OEM requirements, qualified personnel and named quality authority.
RELATED SCOPE