Cloud SCADA in Pharma —
Compliance
Considerations

The Compliance Question Cloud SCADA Actually Raises

When a pharma client asks whether cloud SCADA is compliant, the honest answer is: it depends entirely on how it is architected and what data lives in the cloud. There is no regulatory prohibition on cloud-hosted systems in pharma. Annex 11 does not ban cloud. 21 CFR Part 11 does not ban cloud. What the regulations require is that wherever GMP records are stored and transmitted, the controls around those records — access control, audit trail integrity, data availability, change control — meet the same standards regardless of where the infrastructure sits.

The compliance risk in cloud SCADA is not the concept. It is the assumptions that often accompany it: that the cloud provider handles security so you do not need to validate it; that audit trails are "stored in the cloud" so they must be fine; that the SaaS platform vendor's own validation means you do not need yours. None of these assumptions hold in a GMP context, and all three lead to audit findings.

Open System Classification Changes Everything

The most immediate compliance consequence of moving to cloud SCADA is the open vs closed system classification under 21 CFR Part 11. A traditional on-premise SCADA where access is controlled entirely by the pharmaceutical company is a closed system. A system where GMP records transit the public internet to a third-party data centre — even a highly secure one — is an open system, and §11.30 applies.

Open system status adds three requirements: encryption of records in transit and at rest, use of digital signatures where signatures are required, and documented transmission procedures and controls. In practice this means your URS for a cloud SCADA must explicitly address TLS encryption for all data in transit, encryption at rest for the historian database and audit trail store, and the procedures governing how records are transmitted and what happens if a transmission fails.

Under EU GMP Annex 11, the relevant section is §12 (Security), which requires that access to the computerised system is controlled and that the system protects against unauthorised access. A cloud-hosted system does not inherently satisfy §12 just because the cloud platform has ISO 27001 certification — the pharmaceutical company must demonstrate that GMP record access controls are implemented at the application level, not just at the infrastructure level.

Cloud Provider as a GMP Supplier

Under GAMP 5, the cloud platform provider — whether that is a hyperscaler like AWS or Azure, or a specialist industrial cloud platform — is a supplier of infrastructure critical to the validated system. This does not mean you need to audit AWS. It means you need to understand and document what services they provide, what their contractual guarantees cover (uptime, data sovereignty, backup frequency, RTO/RPO), and how their change management processes could affect your validated system.

The key question for a cloud supplier assessment is: when the cloud provider updates, patches, or migrates their infrastructure, what is the notification mechanism and what is your change control process for responding? An on-premise server update is within your change control. A cloud platform update pushed by the provider without notice is not — unless you have contractual provisions and a documented procedure for managing it.

This is the cloud-specific extension of the patch management challenge that exists for any OT system: you need to understand what changes are coming, assess their impact on the validated state, and decide whether each change triggers a requalification activity.

Audit Trail Integrity in Cloud Environments

Audit trail integrity is the most technically nuanced compliance consideration for cloud SCADA. The audit trail requirements under Part 11 §11.10(e) and Annex 11 §9 require that audit records are computer-generated, time-stamped, and protected against modification. In a cloud environment, "protected against modification" needs specific architecture decisions that are not automatic.

The questions your URS and OQ must address include: are audit trail records written to an append-only store where existing records cannot be modified or deleted, even by system administrators? Is the audit trail stored independently of the application data such that a database restore does not overwrite or lose audit records? Is there a tamper-evident mechanism — cryptographic hashing or equivalent — that would detect any modification of historical records? Are timestamps generated server-side against a synchronised time source, or client-side where they could be manipulated?

These are architecture questions, not configuration questions. If the cloud SCADA platform does not support append-only audit storage natively, this needs to be addressed at the design stage — not discovered during OQ when the test case for audit trail immutability fails.

Data Residency and Regulatory Jurisdiction

An often-overlooked compliance consideration for cloud SCADA in pharma is data residency. EU GMP does not explicitly prohibit GMP records being stored outside the EU, but it does require that records are accessible to regulators during inspection. If your historian data sits in a US data centre and an MHRA inspector requests it during a UK site inspection, the retrieval mechanism and the latency need to be part of your data governance planning.

Some pharma companies resolve this by specifying EU-region data storage in their cloud contracts and verifying it in the IQ. Others accept cross-region storage but document the retrieval procedure and verify it in the OQ. Either approach is defensible. What is not defensible is not knowing where your GMP records are stored.

Availability, Backup, and Disaster Recovery

A cloud SCADA system that becomes unavailable takes the operator interface, the historian, and potentially the alarm management system offline with it. For a GMP manufacturing environment, this is a production impact and potentially a data integrity event if process data is lost during the outage. Your URS must define availability requirements — typically expressed as a minimum uptime percentage for scheduled manufacturing hours — and the cloud platform's contractual SLA must meet or exceed that requirement.

The backup and recovery requirements are equally important. Cloud storage does not automatically mean adequate backup. You need to define: backup frequency, retention period, geographic redundancy of backup copies, and the tested recovery time objective (RTO) for a full system restore. "Tested" is the operative word — a backup that has never been restored is not a validated backup. The OQ for cloud SCADA should include a backup restore test that verifies recovery within the defined RTO and confirms audit trail integrity is maintained post-restore.

What Changes in the Validation Approach

A cloud SCADA project follows the same V-model lifecycle as an on-premise system. The design documents, test protocols, and qualification phases are identical in structure. What changes is the content of several key sections.

The URS gains a section on cloud-specific controls: open system requirements, data residency, availability SLAs, backup and recovery objectives, and supplier change management. The HDS is replaced or supplemented by an infrastructure design document covering the cloud architecture, network topology, and edge gateway configuration. The IQ gains a cloud infrastructure verification section covering provider certification evidence, contractual SLA confirmation, encryption configuration verification, and data residency confirmation. The OQ gains test cases specific to cloud operation: audit trail immutability, transmission failure handling, backup restore, and access control verification at both the platform and application level.

None of this is fundamentally different from the approach for any complex validated system. It is the same risk-based thinking applied to a different infrastructure model. The organisations that navigate cloud SCADA compliance well are those that treat the cloud provider as a supplier, define their requirements precisely in the URS, and verify every requirement in the qualification protocols — rather than assuming the cloud platform's own documentation covers their GMP obligations.