SCADA and DCS validation sits awkwardly between two disciplines. The automation engineers who own the system think in terms of control loops and uptime. The quality group thinks in terms of records and signatures. The validation gap usually opens exactly where those two views fail to meet: the historian.
Wonderware, Ignition, DeltaV and Experion are built for process control first and regulated record-keeping second. That is not a criticism — it is the reason they are reliable. But it means the GxP evidence has to be assembled deliberately rather than assumed from the platform.
This is how we approach SCADA / DCS validation, in the order that matters.
Decide what the regulated record actually is
This is the first question and it is frequently left implicit. A control system generates an enormous volume of data, almost none of which is a GxP record. A handful of it is: the parameters that define a critical process, the values that demonstrate the process stayed within them, the alarms that indicate it did not, and the actions taken in response.
Write that boundary down before scoping anything. Without it, teams either validate the entire control system — which is disproportionate and rarely finishes — or validate none of it and discover during an inspection that the batch temperature record has no controls around it. The boundary is a quality decision informed by engineering, and it belongs in the validation plan rather than in someone's head.
The historian is where data integrity is won or lost
Control systems were designed to keep a process running, and a historian was originally a troubleshooting tool. Treating it as a GxP record store asks something of it that was not its original purpose, and the gaps are consistent.
- Can historical values be edited? On some configurations they can, and if so the question becomes whether the original is retained and the change is attributable.
- What happens to data during a communication loss? Buffering, back-filling and the timestamp applied on recovery. A value back-filled with the recovery time rather than the acquisition time is a contemporaneous failure.
- Is the time source controlled? Multiple servers, multiple clocks and an uncontrolled time source produce a record nobody can reconstruct. Time synchronisation is a GxP control in this context.
- How long is data retained, and what happens at the boundary? Aggregation that silently replaces per-second values with averages destroys the evidence that a short excursion occurred.
That last one is worth dwelling on, because it fails quietly. If the historian compresses older data, the record of a brief deviation can disappear months after the batch was released. data integrity (ALCOA+) is where we assess this properly.
Alarms, and the difference between an alarm and a record
Alarm handling is a control-engineering discipline with a mature literature, and most of it is about preventing operator overload rather than about compliance. For GxP the question is narrower: for alarms that indicate a critical process parameter was exceeded, is the occurrence recorded, is the acknowledgement attributable, and is the response documented.
Test the awkward cases. An alarm that occurs and clears before anyone acknowledges it. An alarm acknowledged by a shared operator account. An alarm suppressed or shelved during a batch, and whether the suppression itself is recorded. Alarm suppression is legitimate and necessary in process control, and it is also the mechanism by which an excursion can become invisible, so it needs to be visible to a reviewer.
Access control in a plant environment
Shared workstations and shared accounts are the normal state of a control room, and they are incompatible with attributable records. This is usually the hardest practical problem in SCADA validation, because the clean answer — unique named accounts with individual authentication at every workstation — collides with an operator wearing gloves who needs to respond in seconds.
The workable answer is proportionate rather than absolute. Unique authentication for actions that change the process or create a record, with session design that makes that practical: short authentication for routine actions, full authentication for parameter changes and signatures. What matters for the package is that the decision is documented, risk-assessed and enforced by the system rather than by a procedure asking people to behave well.
Electronic signatures, where they exist in the control layer, need to meet FDA 21 CFR Part 11 compliance requirements on the same terms as anywhere else. Many plants resolve this by keeping signatures out of the control system entirely and applying them in the MES or the batch record, which is a legitimate design decision and usually the simpler one.
The equipment boundary
A control system controls equipment, and equipment qualification is not software validation. Annex 15 of the EU GMP guide frames installation, operational and performance qualification of the equipment itself. The control software is validated as software. The instruments feeding it — sensors, transmitters, probes — are calibrated, and their calibration status is a prerequisite for any meaningful qualification result.
In practice the most common defect we find is not in any of the three evidence sets but in the join: a qualified vessel, a validated control application, calibrated instruments, and no test demonstrating that a sensor reading out of range is handled correctly by the application. Test the failure of the boundary, because that is where the risk actually lives.
Cyber hygiene as a GxP concern
Control systems run long-lived software on long-lived hardware, and the unsupported operating system in the corner of the plant room is a genuinely common finding. This is a GxP issue rather than only an IT one, because a system that cannot be patched cannot be relied upon to protect the integrity of the records it holds.
What inspectors ask about is modest and answerable: is the control network segmented from the business network, is remote access controlled and logged, is there a documented patching position for systems that cannot be patched on a normal cycle, and are backups taken and restoration actually tested. Untested backups are the most common of these to fail, and the cheapest to fix.
A proportionate test strategy
Under the FDA's Computer Software Assurance guidance, finalised in September 2025 and reissued in February 2026, test depth follows risk per requirement. For a control system that produces a clear split.
Scripted, boundary-focused testing belongs on the functions that touch the regulated record: critical parameter enforcement, historian capture and retention, alarm recording, access control for record-affecting actions, and interface failure handling. Unscripted and exploratory testing covers the much larger surface of trending displays, operator graphics, navigation and non-critical reporting.
The engineering qualification already performed by the automation team is often strong evidence and is routinely ignored by the validation group because it is in a different document set and a different vocabulary. Reading it before planning tests usually removes duplicated work. CSA services is the practice, and the reasoning is the deliverable.
If the system is already live
Most SCADA estates are inherited rather than built. Three questions give you a fast read on where you stand: does the configuration documentation match what is running today, can the historian produce a complete per-second record for a batch released twelve months ago, and is there a current list of who has access to change critical parameters.
If the second one cannot be answered, you have a retention or compression problem that affects batches already released, and that is the one to address first. SCADA / DCS validation and audit readiness are the practices, and book a demo if you want a specific estate assessed.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.
