Automation, SCADA and Data Integrity in Pharmaceutical Water Systems

At twenty to four in the morning the WFI loop return logs a conductivity excursion that lasts a few minutes and clears on its own. Nobody notices: the alarm is set to low priority and the screen resets at shift handover. Two weeks later, during an investigation into an atypical microbiological result, QA asks for the raw data from that night. The historian returns a value averaged over the logging interval: the peak no longer exists. The compression setting was defined by the integrator during start-up, appears in no configuration specification, and no audit trail records it.

This is not an instrumentation problem: the transmitters were calibrated. It is a computerised system problem — what is acquired and at what resolution, who can change its configuration, where the value becomes a GMP record and for how long it stays reconstructable. In pharmaceutical water systems this part almost always arrives with the skid, configured by an integrator and accepted as "working". The Annex 11 and Part 11 boundary is not inherited from the supplier: it must be defined, justified and documented by the site.

Where the data is born and where it becomes a record

A water system has four layers. The instruments generate the signal: conductivity, temperature, TOC, flow, pressure, residual ozone. The PLC runs the logic: control, interlocks, sanitisation sequences, comparison against thresholds. The HMI displays and commands in the field. The SCADA supervises alarms, user accounts, recipes and trends; the historian keeps the time series and makes it interrogable.

The first deliverable of a GMP automation project is not a software specification: it is the data flow map. For each critical parameter it must state where the data originates, where it is processed, where it is made durable, which copy is the record of reference, and who can change it at each layer. It answers the two questions that matter during an inspection: what is the original data, and who can change it without leaving a trace. Two situations must be addressed there: if the durable record sits in the historian, the chain that generates it — sampling interval, filters, compression — determines what that record will be able to demonstrate; and TOC analysers with their own memory, user accounts and audit trail are computerised systems in their own right, not components implicitly absorbed into the SCADA boundary.

Which data is critical, and for which decision

The question that unlocks the boundary is not "is the system subject to Part 11?", but: what GMP decision does someone make while looking at this data? If nobody decides anything, it is process data. If someone releases a use, closes an investigation or justifies a limit, it is a GMP record and it brings the controls with it.

Annex 1 of EudraLex Volume 4 makes this map non-negotiable on three points. Clause 6.15 requires WFI systems to include continuous monitoring, such as TOC and conductivity: this is precisely the data the computerised system must acquire and preserve intact. Clause 6.13 establishes that alert levels derive from initial qualification data and are reviewed through requalification, routine monitoring and investigations: thresholds are therefore configuration parameters that change over time, and must change under control. Clause 6.14 requires alert excursions to be documented, reviewed and investigated, distinguishing an isolated event from an adverse trend: a distinction that is only possible if the time series is complete and legible. The metrological aspects are covered in the article on on-line TOC and conductivity monitoring.

The regulatory framework: what is actually in force

EudraLex Volume 4, Annex 11 (Computerised Systems). The version in force is the one of January 2011, operational since 30 June 2011: it is the text you are inspected against today. Its themes cover risk management, personnel, suppliers and service providers, validation, data, accuracy checks, data storage, printouts, audit trails, change and configuration management, periodic evaluation, security, incident management, electronic signature, business continuity and archiving.

21 CFR Part 11 is in force (62 FR 13464 of 20 March 1997, amended by 86 FR 68830 of 2021 and 88 FR 13018 of 2023). The FDA guidance Part 11 – Scope and Application of September 2003 adopts a narrow interpretation and exercises enforcement discretion in some areas, but states explicitly that "part 11 remains in effect". The operational consequence is clear: the applicability of Part 11 to a given water system must be determined and documented — which records are required by a predicate rule, which are maintained electronically, whether and where electronic signatures are used — not assumed, and not excluded out of habit.

Annex 15 (2015 revision, operational since 1 October 2015) governs qualification of the water system, of which the computerised part is a component and not a parallel project. ASTM E2500-25 provides the science- and risk-based approach that derives verifications from critical aspects; ICH Q9(R1) (Step 4 on 18 January 2023) provides the method used to justify the extent of controls. The PIC/S Aide-Memoire PI 009-4 "Inspection of Utilities", rev. 4 in force since 1 January 2021, is the document inspectors use to frame their examination of utilities.

None of these texts sets backup frequencies, log retention periods or evaluation intervals: those are parameters the site derives from risk and justifies.

The draft revision of Annex 11: not text in force

This has to be said explicitly, because it is currently the main source of confusion in specifications. A draft revision of Annex 11, together with the revision of Chapter 4 and a new Annex 22 on artificial intelligence, was subject to public consultation from 7 July 2025 to 7 October 2025. It has not been adopted and no application date has been published. Its content is not reproduced here: it may change before adoption, and citing it as a requirement would be incorrect. The operating rule admits no nuance: the draft is not cited in a URS as a requirement, does not justify a deviation, and does not appear in a dossier as a regulatory basis. What applies during an inspection is the 2011 text.

Ignoring it at purchase stage would nevertheless be questionable, for a purely engineering reason: a water system lives for decades, while the software infrastructure is bought once. The capabilities that make a system robust against any regulatory evolution — an audit trail that is interrogable and exportable in an open format, raw data export without the supplier, native named accounts and segregated roles, centralised time synchronisation, verifiable restore, remote session logging, a declared support and patching policy — cost little when requested before the order and become expensive as a retrofit. They must, however, be written into the water system URS for what they are: user requirements motivated by the life cycle, not regulatory requirements.

The controls that hold up in an inspection

Audit trail

Annex 11 requires, based on a risk assessment, that the system generate a record of GMP-relevant changes and deletions, available in an intelligible form and regularly reviewed. On a water system the minimum content is derived from the data flow map: alert and action thresholds, sanitisation cycle parameters, interlock overrides, disabling of an alarm or a measuring point, acquisition configuration, calibration coefficients, alarm acknowledgements, logins, restores from backup.

The most frequent error is one of boundary: the trail exists in the SCADA, but the parameter is actually changeable at PLC level through the programming software, where it leaves no trace. The audit trail must cover the layer at which the parameter is genuinely changeable; where that is not possible, access to that layer must be blocked by design and the change routed through the traced layer. The second error is one of legibility: a trail exportable only in a proprietary format, or interpretable only by the supplier's technician, does not work when it is needed.

On audit trail review, no text in force sets a universal frequency. It must be defined and justified by the site according to the criticality of the parameter, typically combining an event-driven review — every excursion investigation checks what was changed and by whom — with a planned periodic review. The inspector does not check the number: they check the rationale and the evidence that the review was actually performed.

Access management

Named accounts, never shared: the shop-floor HMI with a generic "operator" account remains the easiest observation to write and the hardest to defend, because it makes attributing any action impossible. The role/permission matrix is a qualified deliverable, not a factory setting: it is defined in the URS, verified in OQ by proving that each role can do what it must and cannot do the rest, and maintained under change control. Three principles hold it together. Segregation: whoever administers accounts neither generates nor approves critical data. Account life cycle: assignment, change and revocation tied to onboarding, role change and departure — active accounts belonging to people who have left the site are the most recurrent finding in internal audits. Supplier accounts: disabled by default, enabled on approved request and for the duration of the intervention, with the session logged.

Time synchronisation

PLC, SCADA, historian, analysers with their own memory and LIMS must all refer to a common time source. Without it, the correlation between excursion, alarm, sample, laboratory result and action taken cannot be demonstrated, and the investigation required by Annex 1 6.14 stops before it starts. Time zone and daylight saving must be handled explicitly — the change generates duplicate or missing records if it is not anticipated — along with the timestamp format across the chain and the permission, restricted and logged, to change the system clock. Verification belongs to qualification and is rechecked at periodic evaluation.

Alarms

A water system SCADA easily handles hundreds of tags. The problem is not generating alarms: it is that they should be manageable and that each one should lead to an action. The first separation is between process and maintenance alarms and quality alarms, those tied to alert and action levels on conductivity, TOC, temperature, flow and residual ozone; mixing them produces an undifferentiated stream in which the operator learns to ignore everything. The configuration is a formal deliverable: tag, threshold, priority, text, recipient, expected action and reference to the procedure. The system must distinguish alert from action, store the whole life cycle of the event — activation, acknowledgement, return to normal, outcome — and allow thresholds to be changed under change control with audit trail evidence, because Annex 1 6.13 requires those levels to be reviewed. Temporary alarm suppression must be a controlled, logged and time-limited function, not a construction-phase habit.

Backup and restore

What must be saved: the PLC program, the SCADA configuration, the user database, the time series, the audit trail, recipes and cycle parameters. The question that matters is not whether backups are performed, but whether the restore has been tested: a restore that has never been tested is declared continuity, not demonstrated continuity. The test belongs to qualification and is repeated at periodic evaluation and after substantial changes.

Backup frequency, number of generations kept and retention duration are not fixed by any universal numerical requirement: they are established on the basis of data criticality, the maximum data loss acceptable for the decisions that data supports, and the retention requirements applicable to the site, and they are documented in the system rationale. The distinction between backup, for operational recovery, and archiving, for the legibility of the record over time, remains firm: on a system that will live as long as the loop, obsolescence of the format and of the reading software is a risk to be assessed when the platform is chosen.

Interfaces to other systems

A water system is rarely isolated: it exchanges data with the LIMS (offline chemical and microbiological results), with MES or ERP, with the EMS or BMS, with the CMMS, and with the reporting tools used in product quality review. For each interface, define the data exchanged, the direction, the system of reference for that data, the checks on correct and secure transfer, the behaviour if the receiving system is unavailable, and how a failed transfer is detected. Annex 11 indeed requires systems exchanging data electronically to include built-in checks for the correct and secure entry and processing of data.

Two practical points. Manual transcription of a value from the SCADA onto a paper form is also an interface, the least reliable one: it must be handled with an independent check and declared as a residual risk. And when the same data lives in more than one system, it must be decided which copy is the record, otherwise an investigation ends up choosing after the fact which version of the truth to use — precisely what data integrity rules out. The same logic applied to an environmental monitoring system is explored in the article on EMS software, Annex 11 and Part 11.

Remote access, cybersecurity and patching

Remote support from the supplier is the normal support mode and, at the same time, the normal way of losing control of the configuration. The minimum requirements to fix in the contract and in the procedure: a non-permanent connection initiated by the site, named authentication, documented approval per intervention, session logging, review of the changes at the end, and change control for any intervention touching parameters or software in a validated state.

On cybersecurity the tension is well known: security logic asks for patches to be applied quickly, validation logic asks for nothing to be changed without assessment. The answer is not to pick a side, it is to have a process: patch categories defined in advance, predefined criteria for assessing impact on GMP functions, proportionate verification, and a documented emergency path for critical vulnerabilities. An unpatched system is a GMP risk too: unavailability, loss of historical data and record alteration are quality consequences. Segregating the automation network from the office network and from the internet is a design measure. The URS must request the declared support duration, the patch release policy, version compatibility and availability of the configuration documentation: a SCADA on an operating system that is no longer supported is solved by a retrofit, not by a patch.

Risk-based CSV: how much to validate, and on what basis

The starting point is a documented determination: which functions are GMP-critical, which electronic records are required by a predicate rule, whether and where electronic signatures are used. This assessment establishes the Part 11 boundary and is consistent with the 2003 FDA guidance. Declaring "the system is not Part 11" without an assessment is not a defensible position; declaring "everything is Part 11" is expensive and just as poorly argued.

The extent of validation is graded on risk using the ICH Q9(R1) method. Water system software is almost always configured software on a commercial platform: the effective strategy is to assess the supplier — Annex 11 requires supplier assessment and service provider management — to leverage, where the assessment allows it, the development and test documentation the supplier has already produced, and to focus your own verification on the site-specific configuration and the critical functions.

Testing must not be duplicated with respect to water system qualification: it belongs to the same plan, with the ASTM E2500-25 approach deriving every verification from an identified critical aspect. What is typically verified in the field: the correspondence between the value read by the instrument, the value displayed and the value stored all the way to the historian; behaviour when thresholds are exceeded; effective permissions per role, tested negatively as well; audit trail generation; restore; time synchronisation; and behaviour on loss of power or network. How these tests fit into FAT, SAT, IQ, OQ and PQ is covered in the article on water system qualification; the cycle tests, which the system must record in full, in the one on sanitisation cycle qualification.

Periodic review of the computerised system

Annex 11 requires computerised systems to be periodically evaluated to confirm that they remain in a validated state and compliant. The frequency is not fixed by a number: it is established according to criticality and risk, written into a procedure and justified. What makes the review useful rather than a formality: changes made in the period and their change control status; deviations and incidents; alarm performance, including chronic alarms and suppressions still active; the outcome of audit trail reviews; the account list compared against personnel actually employed; restore test results; software support status and obsolescence; calibration backlog. It is not a separate exercise: it reviews the same trends as the periodic review of the water system and should be planned together with it. The other life cycle phases are collected in the Pharmaceutical Water & WFI cluster hub.

Worked example: Site Delta

Teaching example, fictional site. Site Delta buys a new WFI system and treats automation as an accessory to the mechanical supply. Four points emerge in design review: the TOC analyser has its own memory, accounts and audit trail, not integrated with the SCADA; alert thresholds can be changed from the PLC programming software with no evidence in the SCADA; the historian acquisition configuration was defined by the integrator and appears in no specification; the backup covers only the historical database, and the planned accounts are shared per shift.

Actions agreed before the FAT: a data flow map signed by Engineering and QA; critical parameters listed with the layer they reside in and the audit trail requirement at that layer; threshold changes blocked at PLC level and routed through the SCADA with named accounts; the historian configuration declared a qualified parameter and placed under change control; a full restore test included in OQ; the TOC analyser treated as a stand-alone system. The cost was concentrated before the order, where it is a contract clause: the same changes after the SAT would have been variations at supplier price and schedule delay.

Decision matrix: data management architecture

The weights column is deliberately empty: weights depend on product criticality, on the size of the system estate and on the maturity of the site's IT/OT organisation, and must be assigned and justified internally before scores are given.

Design review and internal audit checklist

• Approved data flow map, with the record of reference identified for each critical parameter.
• Documented assessment of Part 11 applicability and of GMP criticality of functions.
• Audit trail active at the layer where parameters are changeable, and exportable without the supplier.
• Historian configuration declared, qualified and under change control.
• Role/permission matrix verified positively and negatively; no shared accounts; revocation tied to personnel processes.
• Common time source; documented handling of time zone and daylight saving.
• Alarm list with priority and expected action; alert distinct from action; no permanent suppression.
• Restore test performed and documented, not merely planned.
• Supplier remote access non-permanent, approved per intervention and logged.

Common mistakes and red flags

• "The system is Part 11 compliant", stated by the supplier. Compliance is a property of the implementation and of the use, not of the product.
• The draft revision of Annex 11 cited as a requirement. It has not been adopted and has no application date: the 2011 text applies.
• Audit trail only at SCADA level while thresholds are changeable in the PLC. The trail does not cover the point where the change actually happens.
• Shared accounts on the shop-floor HMI. They make attributing an action to a person impossible.
• Compression or logging interval set at start-up and never formalised. The data the investigation needs may no longer exist.
• Regular backups and a restore that was never tested. Declared continuity, not demonstrated.
• Permanently active supplier remote connection. The validated state of the configuration is not defensible.
• Quality alarms mixed with maintenance alarms. They prevent the distinction between isolated event and adverse trend required by Annex 1 6.14.
• Clocks not synchronised across PLC, SCADA, analysers and LIMS. The sequence of events becomes impossible to demonstrate.
• Backup, audit trail review or periodic evaluation frequencies copied from another site. They must be derived from your own system's risk and justified.

If this kind of analysis is useful in your daily work, The Pragmatic GMP collects technical deep dives and regulatory updates written in the same register.

Key takeaways

• The automation system is where the continuous monitoring required by Annex 1 6.15 becomes a record: if the record cannot be reconstructed, the monitoring demonstrates nothing.
• The boundary is defined from the GMP decision each item of data supports, not from the supplier's label.
• The applicable Annex 11 is the January 2011 version; the draft under consultation until 7 October 2025 has not been adopted and is not cited as a requirement.
• Part 11 applicability is determined and documented: the 2003 FDA guidance narrows the interpretation but confirms that Part 11 remains in effect.
• An audit trail at the right layer, named accounts, a common clock and a tested restore are worth more than any supplier compliance statement.
• Backup, review and periodic evaluation frequencies are not fixed by a regulatory number: they are derived from risk and justified.

References

• EudraLex Volume 4, Annex 11 Computerised Systems — January 2011 version, operational since 30 June 2011. Draft revision (with Chapter 4 and a new Annex 22) under consultation from 7 July to 7 October 2025, not adopted. health.ec.europa.eu
• EudraLex Volume 4, Annex 1 (C(2022) 5938 final), operational since 25 August 2023 — clauses 6.13, 6.14, 6.15. Annex 15, 2015 revision, operational since 1 October 2015.
• 21 CFR Part 11 — in force. ecfr.gov
• FDA, Part 11 – Scope and Application, September 2003 — narrow interpretation and enforcement discretion; "part 11 remains in effect".
• ICH Q9(R1) Quality Risk Management, Step 4 on 18 January 2023. ich.org
• PIC/S PE 009-17 and Aide-Memoire PI 009-4 Inspection of Utilities, rev. 4, in force since 1 January 2021. picscheme.org
• ASTM E2500-25; WHO TRS 1033, Annex 3 (2021). who.int