Compute & Runtime complete

• No central inventory. Platform engineering, security, and procurement each hold partial views of where workloads run. None of them can produce a complete list, and the partial views often contradict each other.
• Shadow runtimes. Teams have provisioned production environments on platforms (Vercel, Netlify, Heroku, regional PaaS providers) that procurement and security have no record of. The first time the organisation learns about these runtimes is typically during an incident or a compliance review.
• Opaque execution geography. Even for known providers, the question of which country a specific workload runs in has no documented answer. Region selection was a default at provisioning time, and no one revisited it.
• No orchestration ownership. Where Kubernetes is in use it is typically a fully provider-managed offering (EKS, AKS, GKE) with the control plane operated by the provider in a region the organisation did not choose deliberately.

Compute is the layer at which every other sovereignty consideration becomes concrete. Data residency means nothing if the workload that processes the data is running in a jurisdiction the organisation has not chosen. Key management cannot be reasoned about if the runtime that performs cryptographic operations is unknown. CLOUD Act exposure cannot be assessed for a serverless function whose execution region is undocumented.

Under GDPR Art 30, records of processing must describe the means of processing, including the location. An organisation that cannot answer "where does this workload run" cannot maintain accurate Art 30 records. Under NIS2 Art 21, the supply-chain security obligation extends to the providers that operate runtime infrastructure. A provider that is not known cannot be assessed.

Runtime sovereignty is undefined at this level because the runtime itself is undefined. The organisation has delegated the question of where its code executes to whoever provisioned it, with no mechanism for review. Establishing a complete inventory is the prerequisite for every subsequent control.

• Single-provider runtime stack. All production workloads execute on one provider's managed offerings: serverless functions, managed container runtimes, managed PaaS, or provider-managed Kubernetes. The provider operates the orchestration plane and the underlying execution layer.
• Proprietary bindings. Application code calls provider-only services directly. Lambda functions invoke Step Functions, App Service code uses Azure-specific authentication libraries, Cloud Run services depend on GCP IAM tokens. The cost of replacing these calls is non-trivial and grows with the codebase.
• Provider-operated orchestration plane. Where Kubernetes is in use, the control plane is fully provider-managed (EKS, AKS, GKE). The organisation operates worker nodes (or not, in fully-managed offerings) but has no operational role in the API server, etcd, or scheduler.
• Acknowledged but unmitigated lock-in. The risk register names the runtime dependency explicitly. No portable alternative exists yet.

The runtime is where data becomes computable. A workload's execution environment defines which legal entity has technical access to in-memory state during invocation, which jurisdiction the orchestration API answers to, and which provider's continued operation the workload depends on. Single-provider runtime lock-in concentrates all three of these into a single counterparty.

For US-headquartered runtime providers, the CLOUD Act extends compelled disclosure to data the provider has access to, including data within a running workload's execution context. Region selection at provisioning time does not change this: the runtime provider's legal entity remains subject to its home jurisdiction.

• "We chose an EU region, so we are sovereign." Region selection controls where the workload executes physically. It does not change which legal entity operates the runtime, who can be compelled to act on it, or which jurisdiction's orders the orchestration plane answers to.
• "Kubernetes is portable, so managed Kubernetes is portable." OCI container images are portable. A managed control plane operated by the provider is not. Migration involves rebuilding the control plane elsewhere, which is a substantial operation if the organisation has never run one.
• "Serverless is just a billing model." Serverless is also a runtime API. Lambda's invocation contract, App Service's deployment slots, and Cloud Run's revision model are not equivalent and not portable without rewriting the deployment surface.

Runtime sovereignty at Level 1 is functionally absent. The organisation has chosen to defer runtime decisions to the provider in exchange for operational simplicity. That trade is rational only as long as the provider's interests stay aligned with the organisation's, the runtime offering remains commercially viable, and no jurisdictional pressure makes the provider's home country's legal exposure unacceptable.

• Region and legal-entity clarity. Contracts name the execution region precisely (Frankfurt, Zurich, Dublin) and identify the contracting legal entity by name. The customer is contracted with a European subsidiary of the provider where one exists, not the US parent.
• Sub-processor disclosure for the runtime platform. The DPA lists the operational entities that support the compute platform, including any parent-company SRE or global support teams with administrative access. Sub-processor changes trigger a notification process, and the runtime platform's operators are within scope of that process rather than treated as internal to the provider.
• Catalogued runtime dependencies. A register identifies which workloads use which provider-specific features, who owns the migration assessment for each, and what portable alternative would replace it. The register is reviewed and refreshed.
• Provider-access transparency. The DPA addresses provider administrative access to running workloads with named conditions, audit logging, and notification obligations. Break-glass support sessions are subject to logged authorisation rather than being available silently to the provider.
• Portability on paper. A strategy document describes how the organisation would move workloads to OCI containers and self-operated orchestration, with prioritisation by sovereignty exposure.

Level 2 establishes the legal architecture for runtime sovereignty but does not yet enforce it technically:

• Parent-company access remains structural. Contracting with a European subsidiary reduces some legal-process exposure, but the parent typically retains operational and technical access through shared platform tooling. A US parent that is compelled to act under the CLOUD Act can do so through its operational reach into the platform regardless of which subsidiary signed the customer contract.
• In-memory state during invocation. Provider administrative access to running workloads is governed contractually, but the technical capability remains. Hypervisor-level access, debugger interfaces, and platform-side telemetry can observe execution state of workloads that have not yet adopted runtime-integrity controls.
• Orchestration-plane jurisdiction. Even when the workload runs in an EU region, the provider-managed control plane that schedules it may be operated globally with administrative endpoints reachable from outside the EU.
• Untested portability. The strategy document is only as valuable as a rehearsed migration. Until a workload has actually been moved to an alternative runtime, the cost and timeline are estimates.

Level 2 is a coherent posture for organisations that:

• Have moderate sovereignty exposure and rely on contractual safeguards as primary mitigation
• Are actively building toward Level 3 with a credible plan and budget for containerisation and self-operated orchestration
• Operate in regulatory environments where contractual sub-processor disclosure and region commitments meet supervisory expectations, while accepting that those expectations are tightening

At Level 2 the organisation has visibility and contractual standing but no technical alternative. The provider remains the operator of the runtime and the orchestration plane. The organisation can demand notification, audit logs, and named region commitments, and can bring legal claims if those are breached. It cannot continue running its production workloads without the provider's continued cooperation.

• Portable image format. Every production workload is an OCI container image. The image format itself is portable across orchestrators, registries, and runtimes. Provider-specific deployment manifests (CloudFormation, ARM, App Service config) have been replaced with Kubernetes manifests or equivalent declarative deployment surfaces.
• Self-operated or jurisdiction-controlled orchestration. The control plane is run by the organisation directly or by a managed Kubernetes provider whose legal entity sits in the EU/EEA or Switzerland (Exoscale, Scaleway, OVHcloud, Hetzner, IONOS Cloud) under contractual and operational terms the organisation can act on. The control plane is not operated by a US-headquartered hyperscaler.
• Signed-image admission. Images are built in pipelines the organisation controls, signed with organisation-held keys, and verified at admission. Admission controllers (Kyverno, OPA Gatekeeper with cosign, Sigstore policy-controller) reject unsigned images and reject images whose recorded build provenance does not match policy. The integrity verification is the assessment subject here. The provenance generation itself is the responsibility of SUPPLY-L3.
• Attested worker nodes. Worker nodes use platforms that can prove their integrity to the cluster: UEFI Secure Boot with a TPM-backed quote, AMD SEV-SNP attestation reports, Intel TDX attestation, or equivalent. Nodes whose quote does not match the expected baseline are denied cluster admission. This addresses runtime integrity. The complementary data-in-use protection sits in PROC-L3.
• Rehearsed portability. A real production workload has been migrated end-to-end to an alternative orchestration operator within the past year. The runbook is owned, runnable, and recently exercised, not a strategy document.

Level 3 is the level at which runtime sovereignty becomes verifiable rather than asserted. The organisation can produce evidence that:

• The workload is the workload it claims to be (signed image, verified provenance at admission).
• The platform under the workload is the platform it claims to be (attested boot, expected measurement values).
• The runtime is operationally portable (rehearsed migration, OCI portability of the artefact).
• Operator access into running workloads, when it occurs, leaves a record (audit logs in organisation custody).

A misconfigured deployment cannot silently land an unsigned image, because admission rejects it. A compromised worker node cannot quietly join the cluster, because attestation rejects it. An operator action against a running pod is recorded in logs the operator does not control. None of these are absolute, but each removes a class of silent failure that would have been undetectable at Level 2.

This level deliberately separates two technologies that often appear together:

• Confidential computing for runtime integrity (this level). TEE attestation here is used to prove that the execution environment matches an expected baseline. The question being answered is "is this the runtime we built and signed".
• Confidential computing for data-in-use protection (PROC-L3). TEE encryption of in-memory state is used to prevent the operator of the underlying hardware from reading data during processing. The question being answered there is "can the provider see the data".

The same hardware feature can address both, but the controls, evidence, and threat models differ. Organisations adopting confidential computing should look at PROC-L3-C1 alongside COMP-L3-C4: the criteria reinforce each other, and the evidence often overlaps, but each criterion is asking a different question and either can be met without the other.

Level 3 is appropriate for organisations that:

• Process regulated personal data, financial data under DORA, or critical-services data under NIS2 where contractual controls alone are no longer sufficient
• Operate in jurisdictions where supervisory expectations have moved from "documented contractual safeguards" toward "demonstrated operational portability"
• Have a credible threat model in which a runtime provider could be compelled to act against the organisation's interests, and want technical evidence that runtime integrity is intact

For workloads that process low-sensitivity data, run on tightly contracted European providers, and have low concentration exposure, the operational cost of self-operated orchestration and admission control may exceed the sovereignty benefit. Operating Kubernetes well is non-trivial. Organisations should not pursue Level 3 as a default; they should pursue it where the threat model and the regulatory posture justify it.

Runtime sovereignty at Level 3 is substantive but not complete. The organisation controls the orchestration plane, the image supply chain at admission, and the integrity claims about the worker nodes. It does not yet control the hardware those nodes run on. A compromise or compelled act at the hardware-operator layer (firmware update, hypervisor change, physical access) sits beneath what the orchestration controls can see. Closing that gap is the work of Level 4.

The distinguishing characteristic of Level 4 is that every operator with technical access to the running workload is the organisation itself. This goes beyond Level 3's self-operated orchestration to encompass the layers underneath it: hardware, firmware, host OS, and the attestation infrastructure that ties them together.

• Exclusive-tenancy hardware. The physical machines that run production workloads are either owned outright or leased on a single-tenant, dedicated basis. There is no shared hypervisor and no fallback to multi-tenant capacity during a capacity event. The facility is operated under a named EU/EEA or Swiss legal entity.
• Hardware-rooted attestation. A hardware root of trust (TPM 2.0, AMD SEV-SNP, Intel TDX, ARM CCA, or equivalent) anchors a measurement chain that extends through firmware, bootloader, host OS, container runtime, orchestration agent, and workload image. The appraisal service that verifies these measurements is operated by the organisation, not by the hardware vendor or the hosting facility.
• Organisation-controlled firmware and host OS. Versions are pinned, signatures are validated against a trust store the organisation administers, and measurement baselines are compared on every boot. Firmware updates are deliberate, documented, and produce a new attested baseline rather than an undetected change.
• No standing external access. Hardware vendors, hosting facility staff, and orchestration vendors do not retain remote-administrative access. Support sessions are explicit, time-bounded, organisationally authorised, and logged into custody the supporting party cannot reach.
• Isolated tier available. For the most sensitive workloads, an air-gapped or strictly isolated runtime tier exists with documented data-transfer procedures. It is operationally viable rather than aspirational.

Levels 1 through 3 each accept some external operator with technical access to the runtime: at L1 the provider operates everything, at L2 the provider operates the platform under a contract, at L3 the provider operates the underlying hardware. Level 4 is the first level at which the organisation can make a categorical claim: no external operator can act on the running workload without the organisation's explicit, audited consent.

This matters in three concrete scenarios:

• Compelled access. A government order directed at a hardware vendor or hosting provider has no operational reach into a running workload if those parties have no standing administrative access and no path that bypasses the organisation's attestation and audit controls. The order can compel facility access, but operational access requires actions the organisation will see.
• Supply-chain compromise of the operator. A compromise of a hyperscaler's internal tooling at L1-L3 reaches the customer's runtime through the operator's standing access. At L4 there is no standing access path to compromise.
• Silent firmware change. A firmware modification at L1-L3 is invisible to the customer. At L4 the change either matches the organisation's pinned baseline (in which case the organisation initiated it) or fails the measured-boot comparison (in which case the affected node does not run production workloads).

L4 deliberately frames runtime integrity as the COMP concern, distinct from the data-in-use confidentiality framing of PROC-L4:

• COMP-L4-C2 (this level). Attestation proves that the execution environment is what the organisation built and pinned. The threat is a tampered or substituted runtime.
• PROC-L4 (data-in-use confidentiality). TEE-encrypted memory and air-gapped processing prevent data from being readable during execution. The threat is observation of the data itself.

In a fully sovereign deployment both apply. Each criterion is independently verifiable, and the evidence sets overlap but are not interchangeable: an attested runtime can still leak data if memory is not encrypted, and encrypted-memory data can still be processed by an attacker-substituted runtime if attestation does not gate execution.

Level 4 demands capabilities that cloud providers normally abstract away:

• Hardware lifecycle. Procurement with supply-chain integrity controls (tamper-evident shipping, vendor verification), firmware patching with measured-baseline updates, capacity planning, hardware refresh cycles, and decommissioning under data-destruction controls.
• Attestation operations. Maintaining the appraisal service, managing the trust store, defining and updating measurement baselines as components legitimately change, and investigating attestation failures.
• Facility operations. If self-hosted, power, cooling, fire suppression, and physical access management. If co-located, the contractual and operational interface to the facility operator.
• Specialist staff. Hardware engineering, firmware operations, attestation engineering, and the orchestration expertise of Level 3 on top.

For a mid-sized organisation this is typically a team of several engineers with deep specialisation, plus on-call coverage. The operating cost is not the hardware; it is the people who keep the attested baseline current and the runtime trustworthy.

Level 4 is appropriate for organisations that:

• Process classified data, defence-related workloads, or critical national infrastructure where any external operator path is unacceptable
• Have a documented threat model that names specific external operators (hyperscalers, hardware vendors, hosting providers) as actors of concern, including under coercion
• Operate under regulatory or contractual regimes that require demonstrable end-to-end operator-exclusion
• Have the engineering depth and sustained budget to keep the runtime trustworthy over years, not just to deploy it once

For most organisations, Level 3 provides verifiable runtime sovereignty at substantially lower operational cost. The marginal sovereignty gain from L3 to L4 is real but narrow: it removes the hardware-operator layer from the trust model. That gain is worth its cost only when the threat model specifically names that layer. Organisations should not pursue L4 as an aspirational default.

Runtime sovereignty at Level 4 is complete in the sense that no external operator retains a standing path into running workloads. It is bounded only by what the organisation itself can sustain: the integrity of its own engineering practice, its ability to verify its own supply chain (covered in SUPPLY), its physical security, and its ability to keep skilled staff. The organisation has internalised the responsibility that providers carried at lower levels. That is the trade Level 4 makes.