The cloud is not a destination. It is an operating model. The question for a regulated energy operator is not whether to adopt it , that decision has largely been made by the economics , but how to adopt it without surrendering the control properties that regulation and operational safety demand.
The cloud conversation energy operators are actually having
The energy sector’s relationship with cloud computing has matured considerably over the past five years, and the conversation has shifted in ways that are worth acknowledging before getting into architecture.
The early conversation was about whether cloud was appropriate for energy operators at all. That conversation is largely over. The economics of cloud , elastic compute, managed services, the ability to run sophisticated analytics workloads without building and operating data centre infrastructure, are compelling enough that most major energy operators are running significant workloads in public cloud environments. The question is no longer if, but which workloads, under what conditions, with what controls, and with what governance.
The current conversation is more nuanced and more difficult. It is about data sovereignty: which data can leave the operator’s direct control, which must remain within defined geographic boundaries, which must be processed only on infrastructure that the operator has specific assurances about. It is about regulatory compliance: how cloud deployments interact with NIS2, NERC CIP, the UK’s CNI security framework, and the sector-specific regulatory requirements that vary by jurisdiction and by the criticality classification of the operator. It is about operational resilience: how cloud dependencies are managed so that a cloud provider incident does not cascade into an operational incident at an energy facility. And it is about the control plane: how the operator maintains meaningful control over its own infrastructure when significant portions of that infrastructure are managed by third parties.
These are not solved problems. They are active design challenges that every major energy operator is working through right now, with varying degrees of architectural rigour. This post is an attempt to describe what rigorous looks like: the architectural principles, the design patterns, and the governance requirements for a cloud deployment that delivers the operational benefits of cloud computing while satisfying the regulatory and security requirements of a critical infrastructure operator.
Part 1: What sovereignty actually means in a cloud context
“Sovereign cloud” is a term that means different things in different contexts, and the ambiguity is commercially exploited by cloud providers whose sovereign cloud offerings vary enormously in what they actually deliver. Before making architecture decisions, it is worth being precise about what you are trying to achieve.
Data residency is the most commonly understood dimension of sovereignty: ensuring that data is stored and processed within a defined geographic boundary, typically a national jurisdiction. This is a regulatory requirement for certain categories of data in most jurisdictions, personal data under GDPR must remain within the EEA or be transferred under defined adequacy mechanisms, and energy operators in many countries have specific obligations about where operational and critical infrastructure data may be stored. Data residency is achievable with standard public cloud configurations, every major cloud provider offers region-specific deployments where data does not leave the selected region, but it requires architectural discipline: workloads must be explicitly constrained to compliant regions, data transfer paths must be audited, and cloud services that replicate data globally by default must be either avoided or configured to disable global replication.
Operational sovereignty goes further: ensuring that the operator can continue to function even if the cloud provider is unavailable, and that the cloud provider cannot unilaterally change the terms under which the operator accesses its own infrastructure in ways that create operational disruption. This is a resilience requirement as much as a sovereignty requirement. It demands architecture that avoids single points of dependency on cloud provider services, particularly managed services that can be deprecated, changed, or made unavailable without the operator’s control, and that maintains the operator’s ability to migrate workloads if necessary.
Jurisdictional sovereignty is the most demanding dimension: ensuring that the infrastructure on which data is processed is not subject to legal demands from foreign jurisdictions that could compel disclosure of data or disruption of service. This is the concern that drives energy operators in the UK and Europe toward government cloud offerings, AWS UK Sovereign Cloud, Azure Government UK, UKCloud for Managed Services, and that in some cases drives a preference for on-premises or co-located infrastructure over public cloud for the most sensitive workloads. The US CLOUD Act, which allows US law enforcement to compel US-domiciled cloud providers to produce data stored anywhere in the world, is a specific concern for non-US operators using US-headquartered cloud providers, regardless of where the data is physically stored.
Technical sovereignty encompasses the operator’s ability to understand, audit, and if necessary modify the infrastructure on which its workloads run. Full technical sovereignty, the ability to inspect and modify the hypervisor, the network fabric, the storage systems, is not available in public cloud environments and should not be expected. But a defined level of technical visibility, access to audit logs, the ability to validate cryptographic operations, the ability to verify that data is processed only by defined compute instances, is achievable and should be specified as a requirement.
Understanding which dimensions of sovereignty are required for which data and workload categories is the prerequisite for any cloud architecture work. Not all data requires jurisdictional sovereignty. Not all workloads require operational sovereignty. Building a single sovereign cloud architecture that applies the most restrictive requirements to all workloads is expensive and operationally constraining. Building a tiered architecture that applies appropriate sovereignty controls to each workload category based on its regulatory and sensitivity profile is the right approach, and it requires a data classification exercise and a regulatory mapping exercise before any infrastructure is provisioned.
Part 2: The regulatory landscape energy operators must navigate
The regulatory requirements that shape cloud architecture for energy operators are not uniform. They vary by jurisdiction, by the operator’s criticality classification, and by the category of data being processed. The following is a representative rather than exhaustive mapping of the requirements that most European and UK energy operators will encounter.
NIS2 (EU) and the NIS Regulations (UK). The Network and Information Systems Directive 2, now transposed into national law across EU member states, places explicit requirements on operators of essential services, a category that includes energy operators, regarding the security of their network and information systems. NIS2 Article 21 requires that operators implement appropriate technical and organisational measures to manage security risks, which includes supply chain security measures that apply directly to cloud provider relationships. NIS2’s incident reporting requirements, significant incidents must be reported to national competent authorities within defined timeframes, apply regardless of whether the incident occurs in the operator’s own infrastructure or in a cloud provider’s infrastructure. The operator cannot outsource its NIS2 obligations to a cloud provider.
NERC CIP (North America). For operators of bulk electric systems in North America, the NERC Critical Infrastructure Protection standards impose specific requirements on the handling of electronic security perimeters, access control, configuration management, and information protection. CIP-004 (Personnel and Training), CIP-005 (Electronic Security Perimeters), and CIP-011 (Information Protection) all have implications for cloud deployments involving BES Cyber System Information. NERC CIP compliance in cloud environments is achievable but requires specific architectural controls, dedicated tenancy, specific access logging requirements, defined data handling obligations, that must be negotiated with the cloud provider and documented in the Shared Responsibility model.
UK CNI framework. NCSC’s guidance for critical national infrastructure operators places specific expectations on supply chain security, resilience, and the management of third-party dependencies. The Cyber Assessment Framework (CAF), which NCSC applies to CNI operators, includes objectives directly relevant to cloud deployment: maintaining an accurate understanding of the organisation’s network and systems, protecting data through appropriate access control and cryptographic mechanisms, and ensuring the organisation can withstand and recover from adverse conditions including supplier failures.
Sector-specific requirements. Energy operators in many jurisdictions face sector-specific regulatory requirements in addition to cross-sector frameworks. Ofgem in the UK, ACER at the EU level, and national energy regulators in individual member states may impose specific requirements on operational data handling, market data management, and the security of energy management systems. These sector-specific requirements may not be fully addressed by cross-sector cloud security frameworks and require individual regulatory mapping.
The practical implication of this regulatory landscape is that an energy operator’s cloud architecture must be designed to satisfy multiple overlapping regulatory frameworks simultaneously, and that the Shared Responsibility model with the cloud provider must be explicitly mapped against each framework to identify which obligations the provider satisfies and which remain with the operator. This mapping is not a one-time exercise, regulatory frameworks evolve, and the mapping must be maintained as frameworks change.
Part 3: Tiered cloud architecture: matching sovereignty controls to workload sensitivity
The architecture I advocate for regulated energy operators is a tiered model that classifies workloads and data by sensitivity and applies sovereignty controls appropriate to each tier. The tiers are not arbitrary, they map to the regulatory and sensitivity classifications that the operator’s data classification framework should define. The following four-tier structure reflects the architecture I have found most useful in energy operator contexts.
Tier 1 — Restricted operational data. This tier contains data that must remain within the operator’s direct control at all times: real-time process telemetry from safety-critical systems, control system configuration and engineering data, data subject to specific regulatory restrictions on third-party access. The appropriate infrastructure for Tier 1 data is on-premises or co-located, not cloud. This tier should not be connected to any cloud environment. Its isolation is an architectural property, not a configuration choice.
Tier 2 — Sensitive operational data. This tier contains operational data that requires sovereign cloud infrastructure: historian data for regulated energy systems, market-sensitive generation and grid data, personal data of employees and customers. The appropriate infrastructure is a government-classified cloud offering, AWS UK Sovereign Cloud, Azure for Operators (with UK Sovereign configurations), or equivalent national government cloud platforms, with explicit data residency controls, dedicated tenancy where required, and contractual protections against jurisdictional data access by third-party governments. Workloads in this tier must be architecturally isolated from Tier 3 and Tier 4 workloads.
Tier 3 — Internal business data. Standard enterprise workloads, ERP, HR systems, collaboration platforms, internal analytics, that do not contain operationally sensitive or personally sensitive data at scale. Standard public cloud deployments with appropriate data residency configurations are appropriate for this tier. The primary governance requirements are data residency (within the EU/UK as applicable), access control, and encryption at rest and in transit.
Tier 4 — Public-facing and non-sensitive workloads. External-facing applications, public websites, developer tooling, non-sensitive analytics. Standard public cloud with standard security controls. The primary requirement is availability and performance rather than sovereignty.
The architectural principle that governs the relationship between tiers is one-directional data flow upward, data can aggregate from more restricted tiers to less restricted tiers through defined, controlled, audited pipelines, but the reverse is not permitted. A Tier 1 system never receives data from a Tier 3 cloud environment. A Tier 2 system may receive anonymised or aggregated data from a Tier 1 system through a defined export mechanism, but never raw operational data from a Tier 3 or Tier 4 system. This directional constraint, enforced architecturally rather than through policy, is the mechanism that prevents cloud deployments from creating inadvertent paths back to the operational infrastructure.
Part 4: The identity and access control plane
Identity and access management is the control plane through which everything else in the cloud architecture is governed. Getting it wrong, and there are many ways to get it wrong in hybrid cloud environments, produces a security posture that is worse than either a purely on-premises or a purely cloud architecture, because it combines the attack surface of cloud with the credential management complexity of hybrid identity.
The foundational requirement for energy operators is identity plane separation: the identity infrastructure that governs access to OT systems must be separate from the identity infrastructure that governs access to cloud environments, and neither should have a trust relationship to the other that allows credentials to be used interchangeably. This is the same principle I described in Post 1 regarding Active Directory and OT systems, applied to the IT/cloud boundary.
For cloud identity specifically, the architecture should implement:
Federated identity with the operator’s on-premises identity provider for Tier 2 and Tier 3 workloads. Staff access to cloud workloads should be authenticated through the operator’s own identity provider, Microsoft Entra ID (formerly Azure AD), or an equivalent, using federation protocols (SAML 2.0, OIDC) rather than cloud-native identities managed by the cloud provider. This ensures that identity lifecycle management, provisioning, deprovisioning, role changes, is controlled by the operator’s HR and identity management processes, not by cloud console administration.
Privileged Identity Management with just-in-time elevation. Administrative access to cloud infrastructure, the ability to modify security configurations, access encryption keys, view audit logs, must not be persistent. Administrators should operate with standard user privileges in their day-to-day work and request time-limited elevation to privileged roles for specific administrative tasks. Every elevation event should be logged and reviewed. This eliminates the class of attack where a compromised administrator credential provides persistent privileged access to the entire cloud environment.
Workload identity that does not rely on long-lived credentials. Cloud workloads, applications, services, pipelines, that need to access cloud resources must authenticate using short-lived, automatically rotated credentials: managed identities in Azure, IAM roles with instance profiles in AWS, Workload Identity Federation in GCP. No cloud workload should use a static API key or service account password that could be exfiltrated and reused. The principle is that a credential’s useful life to an adversary who extracts it should be measured in minutes, not weeks.
Multi-factor authentication enforced at the identity provider, not the application. MFA must be enforced at the identity provider level, so that it applies uniformly to all cloud access regardless of which application or console the user is accessing. Application-level MFA that can be bypassed by accessing a different interface to the same data is not MFA. Conditional access policies, that require MFA from any network location, that require compliant device state, that block access from high-risk sign-in locations, should be implemented and regularly reviewed.
Part 5: Network architecture for sovereign cloud deployments
The network architecture connecting an energy operator’s on-premises environments to cloud environments is where many of the sovereignty and security properties discussed above are either preserved or inadvertently undermined. The following principles reflect what I consider minimum acceptable network architecture for a regulated energy operator’s cloud connectivity.
Private connectivity, not public internet transit. Traffic between the operator’s on-premises environments and cloud environments should transit private connectivity, AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect, rather than the public internet. Private connectivity provides deterministic network performance, eliminates exposure to internet-based interception, and allows the operator to route cloud-bound traffic through its own network security infrastructure before it reaches the cloud provider’s network. The cost of private connectivity is real and should be budgeted for; the alternative of routing sensitive operational data over the public internet is not acceptable for Tier 1 or Tier 2 workloads.
Hub-and-spoke network topology with centralised security inspection. Cloud network architecture should use a hub-and-spoke model: a central hub virtual network hosts the shared network security infrastructure, firewall, IDS/IPS, network monitoring, private DNS, and spoke virtual networks host application workloads. All traffic between spoke networks, and all traffic between spoke networks and on-premises environments, transits the hub. This topology ensures that all inter-workload traffic and all traffic crossing the cloud boundary is inspected by centralised security controls, regardless of which workload generates it.
Micro-segmentation within cloud environments. Each application workload should be deployed in its own network segment, a virtual network or subnet, with security group rules or network ACLs that permit only the specific traffic flows required for the application’s function. The default posture is deny-all, with explicit allow rules for each required flow. This implements the zone-and-conduit principle from ISA/IEC 62443 in the cloud network architecture, ensuring that a compromise of one workload does not provide unrestricted network access to all other workloads in the cloud environment.
No split-tunnelling for remote access to cloud environments. Remote access to cloud environments, for engineers and administrators working remotely, must route all traffic through the operator’s network security infrastructure. Split-tunnelling configurations that allow direct access to cloud resources while simultaneously connecting to the internet introduce the risk that a compromised remote device can bridge between the internet and the cloud environment without traversing security controls. Full-tunnel VPN configurations, or Zero Trust Network Access implementations that enforce device compliance and route all traffic through cloud-based security proxies, are the acceptable models.
Part 6: Data protection architecture
The data protection architecture for a sovereign cloud deployment has three components that must be designed together: encryption, key management, and data lifecycle management.
Encryption everywhere, with operator-controlled keys. All data at rest in cloud environments, storage accounts, databases, backup repositories, must be encrypted. This is now standard practice and supported natively by all major cloud providers. The critical design decision is who controls the encryption keys. Cloud-provider-managed keys, the default in most cloud services, provide encryption but leave key management in the hands of the provider. If the provider is compelled by a foreign government to provide access to data, provider-managed keys do not protect that data.
For Tier 2 workloads, the appropriate model is Customer-Managed Keys (CMK) stored in a Hardware Security Module (HSM) that the operator controls. Cloud providers support this through services like Azure Key Vault Managed HSM and AWS CloudHSM: the HSM is provisioned in the cloud environment but the key material is generated and controlled by the operator, and access to the key requires authentication through the operator’s identity infrastructure. An operator with CMK can revoke access to all encrypted data by revoking access to the key, a capability that matters in supplier exit scenarios.
For the highest-sensitivity Tier 1 data, on-premises HSMs with cloud provider integration via the provider’s external key management capabilities are the appropriate model. Azure Key Vault and AWS KMS both support integration with external HSMs, allowing encryption operations to be performed in the cloud while the key material never leaves the operator’s on-premises HSM.
Audit logging with tamper-evident storage. All access to cloud resources, by users, by workloads, by administrators, by the cloud provider’s own operations staff, must be logged, and those logs must be stored in a configuration that prevents modification or deletion by any party, including the cloud provider. AWS CloudTrail with S3 Object Lock, Azure Monitor Logs with immutable storage, and equivalent configurations in other providers support this requirement. Logs must be retained for a period consistent with the operator’s incident response and regulatory requirements, typically a minimum of twelve months online with additional archival retention.
Data lifecycle management. Cloud environments accumulate data easily and dispose of it poorly. The data lifecycle management architecture must define, for each data category, how long it is retained, where it is retained, how it is disposed of at the end of its retention period, and how disposal is evidenced. Regulatory requirements for energy operational data vary by jurisdiction and data type, some categories must be retained for defined periods, others must be disposed of promptly when no longer needed. Cloud storage that accumulates indefinitely, with no defined retention or disposal process, is both a regulatory risk and an unnecessary attack surface.
Part 7: Resilience architecture: designing for cloud provider failure
A regulated energy operator cannot accept a scenario in which a cloud provider incident causes operational disruption to energy services. The resilience architecture must ensure that cloud dependencies are managed such that their failure, whether due to provider outage, network connectivity failure, or regulatory enforcement action, does not cascade into operational failure.
The architecture principle here is graceful degradation: the operator’s critical operational functions must be able to continue, at reduced capability if necessary, in the event of cloud provider unavailability. This requires understanding which operational functions have cloud dependencies and designing each to fail gracefully.
Critical operational functions must not have hard cloud dependencies. Real-time SCADA and control functions must not depend on cloud availability. This is an extension of the Tier 1 principle: if a control system function requires connectivity to a cloud service to operate, it has been incorrectly designed. Historian collection, alarm management, and HMI functionality must continue to operate on local infrastructure in the event of cloud connectivity loss.
Cloud-dependent business functions must have defined degraded operating procedures. Functions that do depend on cloud, analytics dashboards, enterprise reporting, some scheduling and optimisation systems, must have defined procedures for operating in degraded mode during cloud unavailability. These procedures must be documented, tested, and known to the operational staff who will need to execute them.
Multi-region and multi-provider architecture for critical cloud workloads. For Tier 2 and Tier 3 workloads that have business criticality, the architecture should include replication to a secondary cloud region, within the same jurisdiction for data residency compliance, and ideally a secondary cloud provider for the most critical workloads. Single-provider dependency for critical business functions is a concentration risk that the resilience architecture must address.
Supplier exit planning. The contract with every cloud provider must include provisions for data portability, the operator’s right to export all data in portable formats, and a defined exit process that includes provider cooperation with migration. The technical architecture must be designed for portability: avoiding proprietary cloud-native services that create lock-in, using open standards for data formats and APIs, and maintaining documentation that allows workloads to be migrated to alternative infrastructure within a defined timeframe.
Part 8: The governance model: making sovereignty a sustained property
Sovereign cloud architecture is not a state that is achieved and then maintained passively. It is a governance commitment that must be actively sustained as the cloud environment evolves, as regulatory requirements change, and as the threat landscape develops.
The governance model must include:
Cloud security posture management (CSPM). Automated tooling that continuously monitors the cloud environment for configuration deviations from the defined security baseline, misconfigured storage accounts, overly permissive security groups, disabled audit logging, encryption keys approaching rotation deadlines. CSPM tools, Microsoft Defender for Cloud, AWS Security Hub, Wiz, Orca Security, provide continuous visibility into the security posture of cloud environments that cannot be maintained through periodic manual audit in dynamically changing cloud estates.
Regular sovereign cloud compliance reviews. Periodic reviews, at least annually, and triggered by significant regulatory changes or cloud provider service changes, that assess the cloud architecture against the regulatory requirements mapped in Part 2. These reviews must include the operator’s legal and compliance function alongside the technical security architecture team, because the regulatory interpretation questions that arise in cloud compliance are not purely technical.
Cloud provider relationship management. The operator’s relationship with its cloud providers must be actively managed at a senior level, not just at the procurement and technical integration level. Changes to cloud provider service terms, data handling practices, or sub-processor arrangements that affect the operator’s sovereignty or compliance position must be identified, assessed, and if necessary escalated to the regulatory relationship. Cloud providers change their services continuously; the operator must maintain visibility into those changes and their compliance implications.
Incident response procedures covering cloud environments. The operator’s incident response procedures must explicitly address cloud-based incidents, including scenarios where the cloud provider is the affected party and the operator’s data or workloads may be at risk. The procedure must define how the operator will detect a cloud provider incident that affects its workloads, how it will assess the impact, how it will fulfil its regulatory notification obligations, and how it will initiate degraded operating procedures if cloud-dependent functions are unavailable.
Conclusion: Sovereignty as architecture, not aspiration
The energy operators who are navigating cloud adoption most successfully are those who have treated sovereignty as an architectural property, something designed in from the beginning, verified through controls, and maintained through governance, rather than as an aspiration addressed through contractual language.
The contractual protections that cloud providers offer, data processing agreements, sub-processor lists, government access commitments, matter, and they should be negotiated carefully. But they are not a substitute for architecture. An energy operator whose cloud deployment routes Tier 2 operational data through publicly accessible APIs, stores it with provider-managed keys, and has no private network connectivity between its cloud environment and its operational infrastructure is not a sovereign cloud operator, regardless of what its contracts say.
The architecture described in this post, tiered sovereignty controls matched to workload sensitivity, private network connectivity, operator-controlled key management, identity plane separation, resilience architecture that tolerates cloud provider failure, and sustained governance, is achievable with current cloud provider capabilities. It requires investment, it requires architectural discipline, and it requires a governance commitment that extends beyond the initial deployment project. But for a regulated energy operator operating critical national infrastructure, it is not optional.
The alternative, cloud adoption driven by operational expediency without the architectural controls that sovereignty requires, produces an infrastructure estate that is exposed to regulatory enforcement, jurisdictional risk, and the adversary targeting that critical energy infrastructure attracts. The cloud is worth adopting. The sovereignty controls are the price of adopting it responsibly.
Key references and further reading
- NCSC — Cloud Security Guidance — ncsc.gov.uk/collection/cloud-security — The UK NCSC’s fourteen cloud security principles, the foundational reference for UK-regulated cloud deployments.
- ENISA — Cloud Computing: Benefits, Risks and Recommendations for Information Security — EU Agency for Cybersecurity guidance on cloud risk management, with specific coverage of sovereign cloud considerations.
- NIS2 Directive (EU) 2022/2555 — The Network and Information Systems Directive 2. Article 21 requirements on supply chain security and risk management are directly applicable to cloud provider relationships.
- NERC CIP-011 — Information Protection standard, including requirements applicable to cloud storage of BES Cyber System Information.
- CSA STAR — Cloud Security Alliance Security Trust Assurance and Risk programme. The STAR certification provides third-party assurance of cloud provider security controls relevant to regulated deployments.
- Microsoft Azure for Operators / Azure Government — Microsoft’s sovereign cloud documentation, including UK Sovereign configuration guidance.
- AWS UK Sovereign Cloud — AWS’s documentation on its dedicated sovereign cloud infrastructure for UK public sector and regulated industries.
- NIST SP 800-210 — General Access Control Guidance for Cloud Systems. The access control architecture reference for cloud deployments.
- UK Government Cloud Security Principles — Cabinet Office guidance on cloud procurement for government and regulated entities, including the assurance requirements that commercial cloud providers must satisfy.
This post is part of an ongoing series on security architecture for critical infrastructure and energy systems. The next post examines the OT DMZ in depth — the specific design patterns for the network zone that sits between operational control systems and enterprise IT, and why most implementations of it fall short.
About the author: Infrastructure Architect with 14 years of experience spanning enterprise architecture, operational technology environments, and regulated digital infrastructure. Currently leading infrastructure architecture for a major energy operator. Holds CISSP certification. Previously Technical Director at a digital health startup. Views expressed are personal.