What Convergence Means in Practice
OT/IT convergence in pharma is not a technology trend — it is a series of specific integration decisions that each introduce a new data flow, a new interface, and a new governance question. When a pharma site connects its SCADA historian to a LIMS for automated data transfer, the data path crosses a zone boundary, the LIMS becomes a downstream consumer of GMP data, and someone needs to own the question: if the data that arrives in the LIMS is wrong, who is responsible and what is the investigation process?
The practical convergence scenarios most commonly encountered in pharma automation are: historian data pushed to LIMS or ERP via a DMZ replication server; batch records generated by the SCADA exported to a document management system; MES or scheduling systems sending recipe parameters down to the SCADA; and remote monitoring dashboards — sometimes cloud-hosted — consuming process data from the historian. Each scenario has a different risk profile, a different validation boundary question, and a different governance requirement.
Every OT/IT integration creates a new answer to: if the data is wrong, who is responsible? In a purely isolated OT system, the answer is clear — the validated system owns its data. When a LIMS reads batch data from a historian via a replication server, there are now three potential failure points: the historian data (OT responsibility), the replication mechanism (IT infrastructure responsibility), and the LIMS import (IT/quality systems responsibility). The validation and governance framework must assign ownership and define how data integrity is maintained across each handoff. If no one has done this explicitly, it has not been done.
The Validation Boundary Question
The most important question OT/IT convergence raises is: where does the validated system boundary end? In a traditional isolated OT system the answer is straightforward — everything inside the OT zone is validated, everything outside is not. When SCADA data flows into a LIMS, the LIMS becomes a downstream user of GMP data. If the LIMS uses that data to support a batch release decision, it is now within scope of the GMP data integrity requirements — which means the data transfer interface itself needs to be validated.
GAMP 5 addresses this through the concept of interface validation. The interface between the OT historian and the LIMS — the data replication mechanism, the protocol (OPC-UA, SQL, CSV/SFTP), the field mapping, and the transfer frequency — is a validated interface. It needs a specification (which fields transfer, in what format, at what frequency), a test (which confirms the right data arrives in the LIMS with the correct values and timestamps), and a change control requirement (any change to the interface specification requires re-testing the transfer).
The Five Interface Types — Risk and Validation Scope
Not all OT/IT interfaces carry the same risk or validation scope. The direction of data flow and the nature of what is transferred are the primary risk drivers.
| Interface Type | Direction | GMP Risk Level | Validation Requirement |
|---|---|---|---|
| Historian → LIMS (read-only data) | OT → IT (outbound push) | Medium — data integrity of transferred values | Interface specification in FDS; transfer verification tests in OQ; data integrity sampling test confirming values match source |
| Historian → ERP (batch summary) | OT → IT (outbound, aggregated) | Low-Medium — aggregated summaries, not primary records | Interface specification; basic transfer verification; primary record remains in historian |
| MES → SCADA (recipe parameters) | IT → OT (inbound — high risk) | High — external system can modify GMP-critical process parameters | Full URS requirement for the MES interface; SCADA must validate received parameter ranges before accepting; audit trail entry on every parameter receive event; MES itself may require validation |
| SCADA → Document Management (batch record export) | OT → IT (export) | Medium — authenticity and integrity of the exported record | Export format specification; integrity check (hash or digital signature) on exported file; chain of custody documented |
| Cloud reporting dashboard (read-only) | OT → Cloud (outbound) | Low — if display-only with no write-back path | Interface documented in HDS; confirm no write-back path exists; assess open vs closed system classification impact |
The Active Directory Integration Question
One of the most common and least carefully considered OT/IT integrations is connecting the SCADA user management to the corporate Active Directory (AD). The operational appeal is obvious — users authenticate to the SCADA with their corporate credentials, IT manages the accounts centrally, and there is no separate OT user database to maintain. The compliance concern is equally obvious: a change made by an IT administrator to a corporate AD account — disabling an account, changing a group membership, resetting a password — immediately affects the validated system's access control without going through the validated system's change control process.
The compliant approach to AD integration is to use a dedicated OT organisational unit (OU) within AD, with change control applied to any modification of that OU. Changes to OT user accounts must go through the same SOP that governs access changes on the SCADA itself. The IT administrator managing the broader AD cannot make changes to the OT OU without a formal request and approval from the validated system owner. This requires a formal agreement between the OT/validation team and the IT team — typically documented in a Data Governance or IT-OT Interface Agreement.
The Governance Framework — What Needs to Exist
OT/IT convergence expands the governance footprint of the validated system. The following elements must be explicitly defined before any integration goes live:
Interface ownership. Every interface between the OT zone and the IT zone needs a named owner — who is responsible for the specification, who is responsible if the data is wrong, and who initiates change control when the interface needs to change. In practice this is typically a shared ownership model: the OT/validation team owns the OT side of the interface; the IT team or quality systems team owns the IT side; and a joint review is required for any change.
Change control scope. The change control SOP must explicitly state that changes to any IT system that sends data to, or receives data from, the validated OT system are in scope for impact assessment. A database schema change in the LIMS that affects a field populated from the historian is a change to the validated interface — even though the change was made entirely in the IT zone.
Incident and deviation scope. If the LIMS receives incorrect data from the historian, that is a potential GMP deviation. The deviation management process must extend to cover interface failures, not just in-system failures. The investigation must trace the data path end to end — the historian, the replication mechanism, the transfer protocol, and the LIMS import — to identify the root cause.
The most common OT/IT convergence finding is not a technical failure — it is a governance gap. The IT team made a change to a downstream system that affected how GMP data was displayed or stored, without realising the validated system's change control process applied. No CCR was raised, no impact assessment was done, and the change was deployed directly to production. The finding is not "the change broke something" — it is "a change was made to a GMP system without change control." Preventing this requires explicit communication of the change control scope to the IT team and a defined process for IT-initiated changes to converged systems.
Remote Access in a Converged Environment
OT/IT convergence typically expands the number of people who want remote access to OT systems — IT administrators, quality systems teams, business intelligence analysts, remote monitoring services. In a purely isolated OT system, the remote access controls are relatively simple because the population of users is small and the use cases are defined. In a converged environment, the population is larger and more varied.
The key principle is unchanged: every remote session must be authenticated, time-limited, logged, and controlled by the site. What changes is the access control policy must now define different roles for different populations — an IT administrator who needs read access to the historian for troubleshooting the replication mechanism does not need the same access as the automation engineer who needs to download PLC code. The jump host architecture supports this through role-based access policies that determine which OT zone targets each user type can reach after authenticating through the jump host.
The FDS-SYS-001 communication interfaces section (Section 8) documents every OT/IT interface with protocol, direction, field mapping, update frequency, and the URS requirement it satisfies. The SDS-SYS-001 security model includes the AD integration approach and the OT OU governance policy. HDS Section 7 firewall rules explicitly document each OT/IT interface as a named conduit with source, destination, protocol, and direction. The URS-SYS-001 includes cybersecurity requirements (URS-CYB-001 series) that drive the OT boundary design — including a requirement that all OT/IT data flows are outbound-initiated from the OT zone, with no IT-initiated connections to the OT network outside of the VPN/jump host path.