TL;DR

• The EU Commission’s April 2026 €180 million sovereign cloud tender (IP/26/833) codified a Cloud Sovereignty Framework across eight technical dimensions: strategic, legal, operational, environmental, supply chain transparency, technological openness, security, and EU-law compliance, and every dimension maps to a concrete platform engineering decision, not a procurement checkbox.
• Data residency (where hardware sits) and data sovereignty (who can compel access) are not the same thing. A Frankfurt AWS region doesn’t insulate you from a US CLOUD Act request. Platform teams building for DORA- or NIS2-in-scope workloads need to engineer around jurisdictional access controls, not just geography.
• Gartner forecasts global sovereign cloud IaaS spending to hit $80 billion in 2026, a 35.6% increase from 2025, with Europe growing 83% to $12.6 billion, before overtaking North America entirely in 2027, the market signal that sovereignty is a structural shift, not a regulatory cycle.
• The IDP control plane is where sovereignty breaks down in practice. When developers self-serve through a SaaS platform whose control plane sits outside EU jurisdiction, provisioning metadata, user identity logs, and approval records all leave the regulated perimeter, even if the deployed infrastructure doesn’t.
• Portable, GitOps-first infrastructure as code is the practical hedge against shifting sovereignty requirements. When the CADA arrives with new eligibility criteria, organizations with IaC in self-controlled state backends can migrate providers without rebuilding their delivery pipeline.
• Not every workload in a regulated organization needs sovereign infrastructure. The correct engineering answer is a classified workload matrix: personal data and DORA-in-scope services go sovereign; non-regulated workloads can stay on hyperscalers, provided cross-environment data flows are audited and controlled at the platform layer.

What Cloud Sovereignty Means for Platform Teams

Cloud sovereignty is the ability to control where infrastructure runs, who can access it, which legal jurisdiction governs it, and whether external entities can compel access to data, metadata, encryption keys, or operational systems. For platform engineering teams, this stops being a legal discussion very quickly. It becomes an infrastructure design problem involving identity systems, key management, deployment pipelines, audit trails, and provider dependencies.

A workload running in a Frankfurt region is not automatically sovereign. If the cloud provider, support organization, control plane, or encryption hierarchy remains subject to foreign jurisdiction, regulators may still treat the environment as externally exposed. This is the distinction many teams miss during initial cloud adoption: data residency only answers where the hardware exists, while sovereignty also asks who ultimately controls access to the environment and under which legal framework.

This matters because modern Internal Developer Platforms (IDPs), CI/CD pipelines, and Infrastructure as Code (IaC) systems continuously exchange operational metadata outside the workload itself. Deployment approvals, Terraform state files, audit logs, RBAC events, and GitOps pipelines often traverse systems operated by third-party SaaS vendors. In regulated sectors covered by DORA, NIS2, GDPR, or public-sector procurement rules, those operational systems now fall inside the compliance boundary too.

The engineering conversation changed significantly in April 2026 when the European Commission awarded a €180 million sovereign cloud contract to four European providers under a formal Cloud Sovereignty Framework. The important shift was not the contract value itself, but the introduction of measurable technical evaluation criteria for sovereignty. Instead of treating “sovereign cloud” as a marketing language, the framework evaluated providers across operational independence, legal jurisdiction exposure, supply chain transparency, technological openness, key management controls, and EU-law compliance.

For platform teams, this changes sovereignty from a procurement preference into a system architecture requirement. Questions like where Terraform state is stored, who controls encryption keys, whether audit logs remain inside EU jurisdiction, and whether deployment pipelines depend on foreign-operated SaaS control planes now become part of infrastructure design reviews rather than post-deployment compliance discussions.

The EU Cloud Sovereignty Framework and What It Demands

On 17 April 2026, the European Commission awarded contracts under IP/26/833 to four European cloud providers: Post Telecom (partnering with CleverCloud and OVHcloud), STACKIT, Scaleway, and Proximus (partnering with S3NS, a Thales-Google Cloud joint venture, alongside Clarence and Mistral). The tender, launched under the Cloud III Dynamic Purchasing System in October 2025, allows EU institutions to procure sovereign cloud services for up to €180 million over six years.

Providers were selected against the Commission’s Cloud Sovereignty Framework, which evaluates eight dimensions: strategic sovereignty (financial and legal anchoring in EU law), legal and jurisdictional sovereignty (protection from foreign authority access), operational sovereignty (ability to run independently of any single provider), environmental sovereignty (sustainability compliance), supply chain transparency (hardware and software documentation), technological openness (open standards usage), security (meeting EUCS or equivalent assurance levels), and EU-law compliance (no conflicting foreign jurisdiction exposure).

Two outcomes from the tender are especially important for platform engineers. First, the Commission evaluated operational control, not marketing claims. Under the legal, operational, and supply chain transparency dimensions, providers had to demonstrate how non-EU entities were restricted from accessing infrastructure, operational systems, encryption hierarchies, and customer environments. This included reviewing key management ownership, personnel access controls, operational escalation paths, and infrastructure dependency documentation. In practice, sovereignty was treated as a verifiable system property rather than a contractual statement.

Second, the tender showed that sovereignty does not automatically exclude non-EU technology stacks. Under the operational sovereignty and EU-law compliance dimensions, providers could still qualify if the operational control boundary remained inside EU jurisdiction. Proximus, for example, qualified partly through its S3NS partnership, where Google Cloud infrastructure operates behind EU-controlled key management, EU-resident operational staff, and locally governed access procedures. For platform teams already running workloads on AWS, Azure, or GCP, this changes the migration discussion significantly. The deciding factor is often not the underlying infrastructure technology itself, but who controls the operational layer surrounding it.

US CLOUD Act Exposure and Why Data Residency Alone Isn’t Enough

One of the most important dimensions in the EU Cloud Sovereignty Framework is legal and jurisdictional sovereignty: specifically, whether infrastructure remains exposed to foreign government access requests outside EU legal control. This is where the discussion moves beyond data center geography and into provider ownership, operational control, and applicable jurisdiction. A workload running entirely inside an EU region may still fail sovereignty requirements if the provider operating that infrastructure remains subject to foreign disclosure laws.

The specific legal problem is this: a cloud provider incorporated under US law, regardless of where it operates data centers, can receive a lawful order under the Clarifying Lawful Overseas Use of Data Act (CLOUD Act) to produce data stored anywhere in the world. A Frankfurt AWS region does not create EU-only jurisdiction over that data. US hyperscalers hold over 70% of the European cloud market, and every organization using them is, to varying degrees, subject to this exposure.

The distinction that platform teams need to build around is between data residency (where the hardware sits) and data sovereignty (who can compel access, under which jurisdiction, and at what level of the stack). In practice, this affects decisions like where Terraform state is stored, who controls encryption keys, whether support engineers outside the EU can access production systems, where audit logs are processed, and whether deployment metadata passes through SaaS control planes operated under foreign jurisdiction. A workload may run entirely inside an EU region while its CI/CD logs, identity provider events, approval workflows, or backup systems remain accessible to a non-EU parent company under foreign disclosure laws. The Netherlands Court of Audit found that 67% of Dutch cloud infrastructure is provided by Google, Amazon, and Microsoft. A recent Bitkom study found 78% of German companies surveyed believe Germany is too dependent on US cloud providers. These aren’t abstract concerns; they’re the audit findings driving regulatory action.

DORA changes how financial organizations evaluate cloud dependencies. Before DORA, many teams treated hyperscaler risk as a contractual issue handled through vendor agreements and procurement reviews. DORA moves that responsibility into ongoing operational oversight. Financial institutions must now identify which cloud providers support critical services, document those dependencies, prove they can recover from provider failures, and demonstrate that regulators can audit the underlying infrastructure relationship if required.

For platform teams, this creates direct infrastructure requirements. Critical workloads cannot depend entirely on one provider for compute, identity, logging, backups, and deployment control simultaneously. Terraform state, audit trails, approval records, and deployment pipelines must remain traceable and recoverable even during a provider outage or regulatory investigation. The question is no longer just “Where is the workload running?” but also “Who controls the operational systems around it, and what happens if access to that provider is disrupted?”

NIS2 extends similar expectations beyond finance into sectors such as energy, healthcare, transport, manufacturing, public administration, and digital infrastructure. Organizations must document external cloud dependencies, segment regulated environments from non-regulated ones, maintain incident reporting processes, and prove that suppliers meet equivalent resilience standards. In practice, this pushes platform teams toward workload classification, policy-based environment isolation, auditable GitOps pipelines, and stricter control over where operational metadata is stored and processed.

Mapping the EU Sovereignty Regulatory Stack to Infrastructure Decisions

Regulations produce requirements, and requirements produce architecture. The problem is that NIS2, DORA, GDPR, and the Cloud Sovereignty Framework each address overlapping concerns from different angles, and platform teams often encounter them during audits rather than during design. The sections below map each regulation to the specific infrastructure decision it drives.

NIS2 Obligations and What They Mean for Multi-Cloud Network Segmentation

NIS2 requires medium and large entities across 18 sectors to report incidents within 24 hours of discovery (six hours in some member states, including Cyprus), maintain documented supply chain security measures, and demonstrate contractual resilience obligations with every external cloud dependency.

For platform teams operating in multi-cloud environments, these requirements affect how environments are separated and governed in practice. Consider a healthcare organization running patient systems on a sovereign EU cloud while hosting internal analytics workloads on AWS. Under NIS2, those two environments cannot casually share networking, IAM federation, or centralized logging pipelines if regulated data could traverse into the non-sovereign environment during a compromise.

A common implementation pattern is to isolate regulated workloads into separate Kubernetes clusters, separate identity providers, and separate logging backends entirely. For example, patient-facing APIs may run inside an EU-hosted cluster with EU-managed object storage and self-hosted observability, while internal developer tooling continues running on standard hyperscaler infrastructure. Network policies then explicitly block east-west traffic between the regulated and non-regulated environments unless traffic passes through approved gateways with audit logging enabled.

apiVersion

The audit requirement is where many teams struggle during their first NIS2 review. Regulators do not only ask whether segmentation exists; they ask for evidence showing when policies changed, who approved them, and whether the controls were tested. A GitOps pipeline with version-controlled network policies and policy-as-code validation produces that evidence automatically. A manually maintained architecture diagram or Confluence page does not.

DORA’s Third-Party Risk Requirements and IaC Audit Evidence

DORA’s Article 28 and the associated RTS require financial entities to document every ICT service dependency and demonstrate that concentration risk is actively managed. Concentration risk, in DORA’s framing, means that if the same provider underlies backup, compute, and identity management, a single incident or compelled disclosure cascades across all three. Platform teams must be able to show that no single third-party failure can take down the entire technology stack.

For infrastructure specifically, every resource in a DORA-in-scope environment must have a version-controlled, audit-traceable deployment record. A Terraform state file stored in an S3 bucket controlled by AWS fails this requirement if AWS is a US-incorporated entity and the state contains configuration evidence that regulators need. State must live in a self-controlled backend inside the regulated jurisdiction, backed by immutable logs that trace each change to an identity, a pipeline run, and a Git commit.

GitOps-first deployment models, where every infrastructure change flows through a version-controlled pipeline with an approval record, produce exactly the evidence DORA auditors look for. The Git history is the change control log. The pipeline run is the deployment record. The approval step is the authorization evidence. Teams that built infrastructure through click-ops or untracked CLI commands face significant remediation work to produce this evidence retroactively.

What the EU Cloud Sovereignty Framework’s Eight Dimensions Mean for Platform Architecture

The Commission’s framework gives engineers a structured way to evaluate both cloud providers and their own platform design. Each dimension maps to a concrete decision:

1. Strategic sovereignty affects provider selection at the environment level. A regulated production environment handling DORA- or NIS2-scoped workloads may only be allowed to deploy onto providers legally headquartered inside the EU, while lower-risk development environments continue running on standard hyperscalers.
2. Legal and jurisdictional sovereignty affects identity systems, encryption architecture, and operational access. In practice, this means deciding where Key Management Service (KMS) root keys live, whether Terraform state is encrypted with EU-controlled keys, whether support engineers outside the EU can access production clusters, and whether audit logs remain inside EU jurisdiction.
3. Operational sovereignty affects disaster recovery and deployment architecture. Teams must assume a provider outage, legal dispute, or forced migration scenario. That requirement influences how Infrastructure as Code (IaC) is stored, whether backups can be restored independently of the provider, whether container registries are mirrored locally, and whether the Internal Developer Platform (IDP) control plane can continue operating if a third-party SaaS dependency becomes unavailable.
4. Environmental sovereignty appears directly in deployment planning and cost governance. Public-sector workloads increasingly require reporting carbon footprint data per region, provider, and deployment. This changes environment selection decisions during provisioning, especially for organizations bidding on EU public contracts.
5. Supply chain transparency affects CI/CD pipelines and artifact management. Container images, Terraform modules, operating system packages, and third-party binaries must be traceable through Software Bills of Materials (SBOMs) and documented dependency chains. Platform teams often implement this through signed container registries, artifact scanning pipelines, and provenance validation before deployment.
6. Technological openness affects how portable the environment remains over time. Teams relying heavily on proprietary managed services may struggle to migrate workloads later if sovereignty eligibility requirements change. This is why many regulated environments standardize around Kubernetes, Terraform, PostgreSQL, and S3-compatible object storage instead of provider-specific abstractions.
7. Security affects encryption boundaries, RBAC design, HSM integration, network segmentation, and audit logging architecture. EUCS-aligned environments typically require stronger separation between regulated and non-regulated workloads, stricter approval workflows, and immutable audit trails tied to deployment activity.
8. EU-law compliance affects the entire operational perimeter surrounding the workload. Even if compute resources run inside the EU, the environment may still fail sovereignty requirements if CI/CD logs, approval workflows, observability pipelines, or SaaS control planes remain accessible under foreign jurisdiction.

Sovereign Cloud Architecture Patterns for Platform Engineering Teams

Most sovereignty-compliant environments follow a layered architecture where deployment control, workload execution, audit logging, and identity systems remain inside the regulated jurisdiction boundary. Instead of relying on one SaaS control plane, teams separate the environment into independently controlled infrastructure layers.

A typical sovereign deployment architecture looks like this:

In this model:

• deployment approvals stay inside EU-controlled systems
• Terraform state remains in self-hosted storage
• policy evaluation happens before infrastructure provisioning
• logs never leave the regulated perimeter
• regulated and non-regulated workloads run in isolated environments

The sections below explain how teams implement these isolation boundaries in practice.

Example: Air-Gapped and Restricted Sovereign Environments

An air-gapped or restricted sovereign environment usually removes direct internet access entirely from production systems. Instead of pulling Terraform providers, container images, or OS packages from public registries during deployment, every dependency is mirrored internally and reviewed before becoming available inside the regulated environment.

Full air-gap is the correct architecture for a narrow set of use cases: classified government workloads, defense systems handling national security data, and specific financial clearinghouses operating under the highest security classifications. For most organizations under NIS2 or DORA, full air-gap is operationally unnecessary and carries a maintenance cost that quickly becomes prohibitive.

What air-gapping actually requires, beyond disconnecting from the internet, is: local package mirrors for every OS, container, and language ecosystem in use; internal certificate authorities replacing public CAs; air-gapped container registries with a documented process for ingesting new images after security review; and update pipelines that pull from internal mirrors without reaching external endpoints. Every dependency update is a manual operation. Security patches that take hours in a connected environment can take days in an air-gapped one, which creates its own security risk.

The middle ground that satisfies most NIS2 and DORA requirements for non-classified workloads is network-restricted deployment: no inbound internet access, controlled and logged egress to a small approved set of endpoints, Terraform providers and container images served from internal mirrors, and key management backed by internal or HSM-based systems. Cycloid’s Dedicated platform deploys fully in customer infrastructure, air-gapped or isolated, with control plane, data plane, and audit logs all staying inside the regulated perimeter.

Self-Hosted Internal Developer Platforms as the Governance Layer

The IDP is where sovereignty controls become operational, and it’s also where they most commonly fail. A developer who provisions infrastructure through a self-service portal is interacting with a control plane. If that control plane is a SaaS platform hosted outside EU jurisdiction, then provisioning instructions, user identity data, approval records, and audit logs are all leaving the regulated environment, even if the infrastructure itself deploys into a Frankfurt data center.

In practice, this means a developer never directly accesses sovereign infrastructure credentials. The platform validates the request, checks jurisdiction policies, records the approval chain, and executes deployment through a controlled pipeline whose logs remain inside the regulated environment.

Self-hosting the IDP means running the platform’s control plane and data plane inside the regulated jurisdiction. Nothing about the provisioning workflow should create egress of metadata, user activity, or configuration data to external systems. In practice, this includes: the service catalog stacks and their configuration templates, the pipeline engine that executes deployments, the identity provider integration, the approval workflow records, and the asset inventory that tracks what’s running where.

RBAC here is an audit question as much as an access control one. Every deployment must be attributable to an identity, and every approval must produce a record that survives a regulatory request. If the approval record lives in a SaaS vendor’s system outside EU jurisdiction, it may not be producible under EU law. Cycloid’s multi-organization RBAC model, Infrapolicies, and Stack versioning enforce deployment boundaries with audit trails stored in the customer’s own Git repository, versioned, immutable, and addressable under EU law.

Policy-as-Code for Cross-Jurisdiction Workload Guardrails

When teams run regulated and non-regulated workloads simultaneously, which is the common state during sovereignty migration, the platform must enforce which workloads can land where without relying on each developer knowing which services are DORA-in-scope or NIS2-covered.

Policy-as-code, using Open Policy Agent, Sentinel, or platform-native Infrapolicies, encodes jurisdiction rules as machine-readable constraints: block deployments of stacks containing personal data to non-EU provider accounts; require selection from an approved sovereign provider list for services tagged as DORA-in-scope; flag any stack routing metrics or logs to endpoints outside the designated region. The policy executes during StackForm submission before Terraform plans or Kubernetes manifests are applied. A deployment targeting a non-approved provider fails immediately, preventing regulated workloads from reaching non-sovereign infrastructure accidentally.

The failure mode of human-review-only enforcement is predictable. A developer building a new microservice doesn’t know whether it processes personal data at the point of selecting a deployment target. By the time the service is in production, the violation has already occurred. Policy-as-code catches the violation at the StackForm layer, before deployment, when fixing it costs nothing.

Sovereign Cloud Provider Selection: Technical Criteria Beyond Marketing Claims

Every major cloud provider now has a sovereignty narrative. Evaluating those narratives requires asking specific technical questions, not reading marketing pages. The Commission’s April 2026 tender provides a useful template: it required assurance evidence, not assertions.

How the Commission’s Eight-Dimension Assessment Works in Practice

Providers in the April 2026 tender had to document their supply chain, demonstrate key management architecture, specify which staff have access to customer data and under which legal framework, and provide exit and portability documentation. The assurance level requirement, that non-EU third parties have limited control, is not satisfied by a contractual commitment alone. It requires technical architecture where EU-resident entities hold root keys, where helpdesk and SRE access requires EU-based authorization, and where the provider can demonstrate operational continuity without the non-EU parent.

The Proximus selection illustrates the boundary. Proximus partners with S3NS, a joint venture of Thales (French) and Google Cloud (US). Google Cloud provides the underlying infrastructure technology; Thales holds the encryption keys and controls operational access. The result satisfies the Commission’s framework because the EU entity, not Google, controls the mechanisms through which data could be accessed. For platform engineers evaluating providers, the right questions are: who holds the root keys and under what legal entity; where are SRE and support staff based and what authorization do they need to access customer data; what are the documented exit procedures and what formats does the provider support for data and configuration export?

Sovereign Clouds Built on European Infrastructure: STACKIT, Scaleway, Outscale, and IONOS

The four providers selected in the Commission tender represent different points on the sovereignty spectrum.

1. STACKIT, the cloud division of Schwarz Group (which operates Lidl), is Germany-headquartered with EU-only infrastructure, no US parent company, and ISO 27001 certification. Schwarz Group has committed €11 billion toward sovereign data center infrastructure for STACKIT, including a major new facility in Lübbenau, Brandenburg. The service catalog is narrower than AWS or Azure, but the jurisdictional guarantees are cleaner because there’s no foreign parent company to complicate the CLOUD Act analysis.
2. Scaleway, part of France’s Iliad group, is designed explicitly as a European alternative to hyperscalers. Data centers operate in Paris, Amsterdam, and Warsaw. Pricing is in euros. The provider participates in GAIA-X and holds SecNumCloud qualification for specific service tiers.
3. Outscale, a Dassault Systèmes subsidiary, operates under French SecNumCloud certification, the highest French national cybersecurity qualification. SecNumCloud certification includes specific requirements around access controls, key management, and personnel security clearance, making it one of the most rigorous sovereignty certifications available in Europe.
4. IONOS, Germany-headquartered, offers GDPR-native architecture and explicitly documents its non-exposure to the US CLOUD Act given its European corporate structure.

The tradeoff is consistent across all four: stronger jurisdictional guarantees come with smaller managed service catalogs, fewer availability zones, and less mature platform services compared to AWS, Azure, or GCP. The engineering decision is whether the sovereignty requirement applies to all workloads or only regulated ones, which leads directly to workload classification.

Evaluating Exit Risk and Portability When Sovereignty Requirements Change

Sovereignty requirements are tightening, not stabilizing. The forthcoming CADA may introduce eligibility criteria that require rearchitecting workloads on providers that don’t qualify. Teams that haven’t built for portability will face this under deadline.

Assessing exit risk means asking: does the provider use open formats and standards, Kubernetes, Terraform, OpenStack APIs, S3-compatible object storage, or proprietary interfaces that create lock-in? Does the IaC that provisions the environment produce portable state, or state that only resolves against that provider’s backend? Does the provider supply documented data export procedures that work at scale?

With Cycloid Infra Import you’ll be able to regain control of your runway infra. 

Infrastructure as Code, version-controlled in Git with self-controlled state backends, is the practical answer to all three questions. When the provider changes, the infrastructure definition travels with the organization. Cycloid’s Infra Import capability, backed by the open-source TerraCognita tool, reads existing resources from AWS, Azure, GCP, and VMware and generates Terraform configuration files. For organizations whose infrastructure exists in a hyperscaler without version-controlled IaC, this is the starting point for any sovereignty migration, because teams can’t plan what they haven’t inventoried.

Governance and Audit Architecture for Sovereignty-Compliant Platform Teams

Sovereignty isn’t maintained by architecture alone. Auditors, regulators, and certification bodies need evidence, structured, dated, attributable records that prove controls operated as designed. Building the evidence trail into the platform architecture from the start costs far less than reconstructing it after an audit request.

Structuring Audit Trails That Satisfy NIS2, DORA, and Internal Certification Audits

NIS2 and DORA auditors don’t look for logs; they look for change control evidence. Every infrastructure deployment must be traceable through: a Git commit that records what changed and who authored it; a pipeline run that records when the change was applied and whether it succeeded; an identity record that confirms which authorized user triggered the pipeline; an approval record if the environment requires it; and an outcome record that shows the post-deployment state.

The specific failure mode of SaaS-only IDPs is that approval records, pipeline logs, and audit trails live in the vendor’s system. If the vendor is outside EU jurisdiction, producing those records during a regulatory investigation may require a legal process that takes weeks and may not produce complete records. A self-hosted, Git-backed IDP stores every record inside the regulated environment, under the organization’s own access controls, addressable under EU law.

Cycloid keeps detailed audit trails for all platform actions and changes, with all records storable in the customer’s own infrastructure when deployed in dedicated or self-hosted mode. Every stack deployment, every approval, and every configuration change produces an immutable record in the customer’s Git repository, the format auditors can read and that legal processes can compel from the organization’s own systems, not a third party’s.

RBAC Design for Multi-Tenant Sovereign Environments

Managed service providers, shared service centers, and large enterprises running both regulated and non-regulated workloads share a common RBAC problem: sovereignty boundaries must be enforced at the platform layer without requiring every operator to manually verify which environment each developer is authorized to reach.

The design requirement is multi-tenancy with hard isolation between authorization domains. Organizations, teams, environments, and stacks must be separate authorization scopes so that a developer authorized for the non-regulated environment cannot, by misconfiguration or accident, deploy to a regulated one. DORA’s RTS adds the concentration risk dimension: a failure or breach in one tenant’s environment must demonstrably not affect another’s, which requires network isolation, separate identity scopes, and separate pipeline contexts.

Cycloid’s multi-organization RBAC model enforces these boundaries through Infrapolicies and Stack versioning. Platform teams define which stacks are available to which organizations, which environments require approval workflows, and which providers are eligible for each regulatory scope. MSPs using Cycloid can manage multiple customer environments with strong isolation, separate audit trails per tenant, and RBAC that prevents any operator from crossing tenant boundaries without explicit authorization.

Carbon and Cost Governance as Part of the Sovereignty Framework

Environmental sovereignty is one of the Commission’s eight assessment dimensions, and for public sector procurement in the EU, it functions as a scoring criterion. Teams building for public sector contracts need per-deployment carbon footprint data alongside cost data, visible before deployment, not reported retrospectively.

Pre-deployment cost and carbon estimation, exposed at the self-service layer, changes the decision point. A developer choosing between two deployment options who can see that Option A costs €200/month and produces 12kg CO₂e while Option B costs €180/month and produces 8kg CO₂e makes a better decision than one who sees neither figure. Escalating every environment sizing decision to a platform team to check compliance is not scalable; exposing the data at the StackForm layer puts the decision where the choice is made.

Cycloid’s FinOps and GreenOps modules expose cost and carbon data per project, region, provider, and tag, filterable in real time. Cost estimation runs before deployment, at the StackForm layer, giving developers the figures before they commit. For organizations pursuing public sector contracts that score against the Commission’s environmental sovereignty dimension, this data is audit-ready evidence of compliant procurement behavior at the infrastructure level.

Migration Pathways from Hyperscaler-Dependent to Sovereignty-Compliant Architecture

Sovereignty migration is a multi-year engineering program in most organizations, not a switch-over event. The practical path starts with classification, proceeds through IaC generation, and lands in a provider-abstracted delivery pipeline that can accommodate sovereign targets without rebuilding from scratch.

Workload Classification: Which Services Actually Require Sovereign Infrastructure

Not every workload in a regulated organization needs to run on a sovereign cloud. The Commission’s own framework acknowledges that non-EU technologies can satisfy minimum sovereignty requirements in the right operational context. The engineering objective is to identify which workloads genuinely require sovereign infrastructure and architect accordingly.

A workload classification matrix works across three axes: data sensitivity (personal data under GDPR, confidential business data, classified information), regulatory scope (DORA-in-scope financial services, NIS2 essential services, specific sector regulations), and operational criticality (what fails if this environment is unavailable or compromised). Workloads that score high on data sensitivity and regulatory scope need sovereign infrastructure. Workloads that score low on both can stay on hyperscalers, as long as data flows between the two environments are logged and controlled.

A hybrid architecture is the correct outcome for most organizations, not a failure of sovereignty intent. The classification matrix makes the boundary explicit and defensible: regulators can be shown exactly which workloads are on sovereign infrastructure and why, and which aren’t and why that’s compliant. The classification also determines which environments need the full governance architecture (self-hosted IDP control plane, RBAC isolation, policy-as-code enforcement) and which can operate with lighter controls.

IaC-First Migration: Using Infra Import to Generate a Portable Baseline

Organizations whose infrastructure exists in a hyperscaler without version-controlled IaC are starting sovereignty migration from a blind spot. Without a documented baseline, teams don’t know what they’re moving, what dependencies exist between resources, or what configuration drift has accumulated since the original deployment.

Cycloid’s Infra Import capability, backed by the open-source TerraCognita tool, reads existing cloud resources from AWS, Azure, GCP, and VMware and generates Terraform configuration files. The output is a version-controlled, portable baseline from which migration planning can begin. Teams can review the generated IaC for drift (resources that exist in the cloud but not in the configuration), undocumented dependencies (resources that reference each other without explicit declaration), and legacy configuration that doesn’t meet current sovereignty requirements.

The generated IaC then becomes the authoritative source for migration planning. Environments are recreated from code on the target sovereign provider, with the IaC reviewed and approved through the same GitOps pipeline as any other infrastructure change. The state backend moves to a self-controlled endpoint in the regulated jurisdiction, and the delivery pipeline connects to the new provider account. The result is a documented, auditable migration with a complete change history.

Sovereign Cloud Onboarding Without Rebuilding the Delivery Pipeline

One of the largest practical blockers to sovereignty migration is the assumption that switching cloud providers means rebuilding CI/CD pipelines, service catalogs, and deployment automations. On a GitOps-first IDP, the provider is an input variable, not the foundation of the delivery architecture.

A developer interacting with a StackForm doesn’t see the underlying provider API. The form asks what environment to deploy, what size, what region, and the platform translates those inputs into provider-specific API calls behind the scenes. Changing the deployment target from AWS Frankfurt to Scaleway Paris, for stacks that have been built to be provider-agnostic, requires adding a new provider account to the platform and exposing it to the relevant tenants. The StackForm doesn’t change. The pipeline template doesn’t change.

What changes instead is the infrastructure destination and the governance policy attached to it. Cycloid’s asset inventory layer gives platform teams real-time visibility into which workloads, Terraform stacks, cloud accounts, and Kubernetes resources exist across regulated and non-regulated environments. During sovereignty migration, this becomes the operational source of truth for identifying which services still depend on non-sovereign infrastructure and which environments have already migrated.

Cycloid’s InfraView and open-source InfraMap capabilities then generate infrastructure topology directly from live Terraform state, producing environment documentation automatically instead of relying on manually maintained architecture diagrams. For teams preparing for NIS2 or DORA audits, this creates continuously updated infrastructure evidence showing network boundaries, provider dependencies, and resource relationships across sovereign and non-sovereign environments.

Cycloid’s StackForms allow cloud account selection as a form variable, meaning platform teams can add a sovereign provider as a new account option and immediately make it available to the tenants who need it, without rebuilding the service catalog or retooling the delivery pipeline. Existing stacks that already deploy via Concourse pipelines continue to do so. Provider account is another destination. 

Cycloid’s Components layer becomes especially useful during phased sovereignty migrations where provider-specific services must be swapped incrementally instead of rebuilding entire stacks. Teams can replace individual infrastructure components, for example moving from AWS-managed databases to Scaleway or Outscale equivalents, without redesigning the surrounding deployment workflow. The abstraction happens at the component layer rather than forcing teams to rebuild the entire service catalog.

This is where Cycloid’s sovereignty model differs from a standard SaaS Internal Developer Platform. The platform itself can run inside dedicated, self-hosted, isolated, or fully air-gapped environments while preserving the same RBAC model, audit pipeline, policy engine, StackForms, and governance controls. Sovereignty is enforced not only at the infrastructure layer, but at the control-plane layer where deployment approvals, Terraform state access, audit logs, and operational metadata are generated and stored.

Conclusion

Cloud sovereignty has moved from compliance label to a systems design specification. The EU Commission’s April 2026 eight-dimension Cloud Sovereignty Framework, DORA’s third-party risk and concentration risk requirements, NIS2’s supply chain documentation obligations, and GDPR’s transfer restrictions collectively define a technical architecture, one that requires self-controlled IaC state backends, platform control planes that don’t route metadata outside the regulated jurisdiction, policy-as-code that enforces workload placement before deployment runs, and portable infrastructure definitions that don’t create exit risk.

Teams that treat sovereignty as a procurement decision will architect themselves into a corner. When CADA formalizes eligibility criteria across the EU single market, organizations whose infrastructure is opaque (no version-controlled IaC), whose IDP control plane is a foreign SaaS system (approval records outside EU jurisdiction), and whose workload classification is undocumented (no basis for demonstrating compliance) will face costly remediation under deadline. Teams that build the governance architecture into the platform layer now, self-hosted control planes, GitOps-first pipelines, policy-as-code enforcement, classified workload boundaries, will have the audit evidence, portable IaC, and architectural flexibility to meet whatever the next regulatory specification requires.

FAQs

1. What is the Difference Between Cloud Sovereignty, Data Sovereignty, and Data Residency for Engineering Teams?

Residency is the hardware location, while data sovereignty is about legal jurisdiction and access. Cloud sovereignty adds eight dimensions like operational independence and supply chain visibility. US-based providers in Frankfurt satisfy residency, but the CLOUD Act may cause sovereignty failure.

2. How Does the EU Cloud Sovereignty Framework’s Eight-Dimension Assessment Affect IDP Toolchain Selection?

The framework’s focus on technological openness favors open standards like Kubernetes and Terraform to prevent exit risk. To meet legal and jurisdictional requirements, the IDP control plane must operate within the regulated jurisdiction. This rule restricts SaaS platforms hosted outside the EU for organizations following DORA or NIS2 standards.

3. What Specific DORA Obligations Require Changes to How Platform Teams Store Terraform State and Deployment Audit Trails?

DORA Article 28 requires documented ICT dependencies and managed concentration risk, which are not met if using US-controlled storage for infrastructure state. State must reside in self-controlled EU backends where change history is traceable to authorized users and pipeline runs. This ensures configuration records remain within the regulated territory for audit purposes.

4. Can Organizations Use AWS or Azure and Still Meet EU Cloud Sovereignty Requirements Under the Commission’s 2026 Framework?

Organizations can use hyperscalers if the technology is operated through an EU-controlled framework where resident staff manage encryption keys. While models like AWS European Sovereign Cloud aim for separation, compliance relies on technical architecture rather than vendor claims. Third-party review against the eight-dimension framework is necessary to verify these sovereignty claims.