Data Processing complete

• No processing inventory. The organisation uses cloud services, SaaS platforms, and third-party tools without knowing which data centres or regions handle its workloads. Infrastructure could span multiple jurisdictions without anyone being aware.
• Unrestricted provider access. The provider's operations, support, and engineering teams can access customer data without restriction. No technical barriers (encryption, access controls) limit what provider personnel can see or do.
• No purpose limitation. Terms of service may grant the provider rights to use customer data for analytics, advertising, machine learning training, or product improvement - and the organisation has not reviewed or negotiated these terms.
• Unknown sub-processors. Data may flow through multiple third parties during processing - CDNs, analytics platforms, logging services - without the organisation's knowledge or consent.

When an organisation does not understand its processing landscape, it cannot satisfy even the most fundamental regulatory obligations. GDPR Art 5(1)(b) requires that data be collected for specified, explicit, and legitimate purposes. If the organisation cannot articulate what processing occurs, it cannot demonstrate lawful purpose.

Beyond compliance, the absence of processing awareness creates operational blind spots. Performance issues, data leaks, or service outages in unknown sub-processors can cascade without any ability to diagnose or respond.

Sovereignty over data processing is non-existent at this level. The organisation has outsourced not just the processing itself but all decisions about how processing is conducted. This represents complete dependency - the provider could change processing locations, introduce new sub-processors, or alter processing methods without the organisation having any mechanism to detect or prevent it.

• Provider-managed pipeline. All compute, transformation, and data access decisions are made by the provider. The organisation selects a service tier and region but has no influence over how workloads are scheduled, where intermediate data is stored, or how processing resources are allocated.
• Multi-tenant infrastructure. Workloads run on shared physical hardware alongside other customers. Logical isolation (separate VMs, containers) may exist, but there are no guarantees of physical separation or protection against side-channel attacks.
• Default terms govern processing. The provider's standard terms of service or a click-through DPA define the processing relationship. These typically grant the provider broad latitude and offer limited purpose restriction.
• Passive sub-processor awareness. The provider may publish a sub-processor list or send change notifications, but the organisation does not actively monitor, review, or respond to changes.

Shared infrastructure introduces risks that are difficult to quantify. Side-channel vulnerabilities - such as those exploiting shared CPU caches, memory buses, or network paths - have been demonstrated repeatedly in academic and real-world settings. While cloud providers invest heavily in mitigating these risks, the fundamental exposure remains when workloads share physical resources.

Without a negotiated DPA, the organisation lacks contractual tools to enforce processing restrictions. If the provider changes its processing behaviour - introducing a new sub-processor, shifting workloads to a different region, or using data for secondary purposes - the organisation may have no legal basis to object.

Sovereignty at this level is nominal. The organisation knows who processes its data but cannot materially influence how that processing occurs. Processing decisions remain with the provider, and the organisation's ability to enforce constraints depends entirely on the provider's goodwill and standard policies rather than on technical or contractual mechanisms within its control.

• Comprehensive DPAs. Each processor relationship is governed by a DPA that meets GDPR Art 28(3) requirements: specified processing purposes, data categories, duration, controller instructions, and obligations upon termination. These are negotiated documents, not click-through defaults.
• Sub-processor governance. The organisation maintains a register of sub-processors for each provider. DPAs include advance notification requirements and objection rights when sub-processors change. Reviews occur at least annually.
• Contractual geographic restrictions. Processing is limited to named jurisdictions or regions through DPA clauses. The provider attests to compliance, and the organisation may collect compliance certifications (SOC 2, ISO 27001) as supporting evidence.
• Purpose limitation is defined, not enforced. The DPA specifies permitted processing purposes, but the organisation has no technical mechanism to detect if the provider processes data beyond those purposes.

Contractual controls represent a significant step forward from Level 1. They provide a legal framework for enforcement, establish clear expectations, and create accountability mechanisms. Many organisations operate successfully at this level, and it satisfies the baseline requirements of most data protection regulations.

However, contracts are only as strong as the ability to verify compliance. A DPA that restricts processing to EU data centres is meaningless if the organisation cannot independently confirm that processing actually stays within those boundaries. Provider compliance certifications offer some assurance but are point-in-time assessments that may not reflect continuous operations.

Sovereignty at Level 2 is contractual rather than technical. The organisation has defined what processing should look like and has legal tools to enforce those definitions. But the actual enforcement depends on the provider's operational integrity and the organisation's ability to detect violations - both of which have inherent limitations. True processing sovereignty requires technical controls that make policy violations technically impossible, not merely contractually prohibited.

• Confidential computing. Production workloads run within trusted execution environments (TEEs) such as Intel SGX enclaves, AMD SEV-SNP virtual machines, or equivalent technologies. These environments encrypt data in use, preventing the cloud provider's staff, hypervisor, and host operating system from accessing plaintext data during processing.
• Jurisdiction enforcement through infrastructure. Region restrictions are not merely contractual promises - they are enforced through infrastructure-as-code policies, cloud organisation policies, or network-level controls that technically prevent workloads from running in non-approved regions. Violations trigger alerts.
• Organisation-controlled audit logging. All data access events, including provider administrative access, are logged and forwarded to logging infrastructure that the organisation controls. This may be a dedicated cloud account, an on-premises SIEM, or a third-party log management service under the organisation's contract.
• BYOK/HYOK for processing. Encryption keys used during processing are managed by the organisation, not the provider. The organisation can revoke key access to immediately terminate the provider's ability to process data. This provides a technical kill switch that does not depend on provider cooperation.

Level 3 represents a qualitative shift in the sovereignty posture. At Levels 0-2, the organisation relies on the provider to honour processing constraints - whether through default behaviour, contractual commitment, or compliance certification. At Level 3, technical controls make many violations structurally impossible.

A provider engineer cannot read data processed within a TEE, because the hardware prevents it. A misconfigured deployment cannot process data in a restricted jurisdiction, because infrastructure policies block it. An unauthorised data access cannot go undetected, because audit logs capture it independently.

Level 3 is appropriate for organisations processing sensitive personal data at scale, financial services subject to DORA, critical infrastructure under NIS2, and healthcare or legal services handling confidential records. It is also warranted when the organisation's CLOUD Act risk assessment identifies provider access to data during processing as a significant exposure that contractual controls cannot adequately mitigate.

For general business workloads where Level 2 contractual controls are proportionate to the data's sensitivity, the additional cost and complexity of confidential computing and BYOK/HYOK may not be justified. TEE deployment requires workload re-architecture and ongoing attestation management. Organisations should assess whether the residual risk at Level 2 is acceptable before committing to the operational overhead of Level 3.

Processing sovereignty at Level 3 is substantial but not absolute. The organisation controls what happens to data during processing and can verify that controls are functioning. However, it still relies on the provider's hardware, firmware, and silicon supply chain. TEE guarantees are only as strong as the underlying hardware implementation - vulnerabilities in CPU architectures (as demonstrated by Spectre, Meltdown, and subsequent attacks) can potentially undermine enclave security.

For most organisations, Level 3 represents the optimal balance between sovereignty and operational efficiency. The residual risks are real but require sophisticated, targeted attacks to exploit, and they are actively addressed by hardware vendors and the security research community.

• Self-hosted infrastructure. Processing runs on hardware the organisation owns outright or leases on an exclusively dedicated basis. This includes servers, storage, networking equipment, and supporting infrastructure (power, cooling, physical security). No shared cloud resources are involved.
• Zero provider access. No external entity - cloud provider, hardware vendor, managed service provider, or support contractor - can access the processing environment during operation. Remote access tools are disabled. Vendor support, when needed, occurs under supervised conditions with full audit logging and explicit authorisation.
• Air-gapped environments. The most sensitive workloads run on physically isolated networks with no connection to the internet or any external network. Data ingress and egress occur through controlled, audited transfer procedures (e.g., physically carried media with integrity verification).
• Full stack control. The organisation manages the entire processing stack from hardware procurement through application deployment. Hardware sourcing includes supply-chain integrity measures. Firmware is validated against known-good signatures. Operating systems and runtimes may be built from source with reproducible build pipelines.

Level 4 eliminates the trust dependency on external providers that exists at every other level. At Level 3, the organisation trusts the provider's hardware and firmware integrity. At Level 4, the organisation verifies or controls these layers directly. This is the only level at which the organisation can make absolute claims about processing sovereignty.

This level is typically required for processing classified government data, defence-related workloads, critical national infrastructure systems, and other scenarios where any external access - even theoretical - is unacceptable.

Processing sovereignty at Level 4 is complete. The organisation controls every aspect of the processing environment, from the silicon to the application layer. No external entity can access, observe, or influence data processing without the organisation's knowledge and explicit consent.

The trade-off is significant operational complexity and cost. The organisation must maintain data centre facilities, procure and manage hardware, build and operate infrastructure software, and employ specialised staff across all these domains. Many organisations will find that Level 3 provides sufficient sovereignty for their risk profile, reserving Level 4 for a subset of their most sensitive workloads.

Level 4 is required for classified government data, defence-related workloads, critical national infrastructure, and other scenarios where any external access to the processing environment is unacceptable. It is also warranted when the organisation needs to demonstrate to regulators or clients that no third party can observe or influence data processing under any circumstances.

For most commercial organisations, Level 3 provides verifiable technical controls sufficient for regulated sectors. Level 4's total cost of ownership is substantially higher than cloud-based processing, and the organisation bears full responsibility for availability, resilience, hardware lifecycle management, and staffing. Level 4 should be reserved for workloads where the threat model specifically requires elimination of all external provider dependencies.

Organisations at Level 4 must invest in capabilities that cloud providers typically abstract away: hardware lifecycle management, firmware patching, capacity planning, physical security, power and cooling redundancy, and disaster recovery for self-hosted infrastructure. The total cost of ownership is substantially higher than cloud-based processing, and the organisation bears full responsibility for availability and resilience.