The European Commission's Cloud Sovereignty Framework (CSF v1.2.1), published on 20 October 2025, transforms digital sovereignty from a political aspiration into a structured assessment methodology. For the first time, European institutions — and, increasingly, regulated financial institutions — have a rigorous, evidence-based framework for evaluating and documenting the sovereignty characteristics of their cloud arrangements. The CSF was immediately applied to the Commission's own EUR 180 million Cloud III procurement, where minimum SEAL levels served as hard pass/fail thresholds. Providers that failed to meet the minimum assurance level for any single objective were automatically rejected.
This article works through each of the eight Sovereignty Objectives from the perspective of a BaFin-regulated bank, assessing what achieving each SEAL level requires in practice, what ratings different cloud provider types can realistically be expected to achieve, and what minimum SEAL levels are appropriate for different categories of banking workload. It assumes familiarity with the CSF's structure; readers who have not yet reviewed the framework itself should read the companion article on digital sovereignty first.
The SEAL Framework: A Brief Orientation
The five SEAL levels are defined in the CSF as follows. Understanding what distinguishes each level — particularly the specific conditions that separate SEAL-2 from SEAL-3 and SEAL-3 from SEAL-4 — is essential to making accurate assessments.
The critical boundary in the context of regulated banking is between SEAL-2 and SEAL-3. SEAL-2 means EU law applies and can be enforced, but material non-EU dependencies remain — which describes the situation of most standard hyperscaler deployments with data residency controls in place. SEAL-3 requires that non-EU control is marginal rather than material. Achieving SEAL-3 on the Legal & Jurisdictional objective, for example, requires demonstrating that the CLOUD Act exposure is more than contractually acknowledged — it must be architecturally addressed to the point where non-EU authority over the service is genuinely marginal rather than merely limited.
Assessing Each Objective for a Regulated Bank
The following assessment covers all eight Sovereignty Objectives. For each, I describe what the CSF's contributing factors require, what a typical regulated bank using a US hyperscaler's standard sovereign cloud product can expect to achieve, and what architectural or contractual steps would be required to reach higher levels. The provider type labels used are: US Hyperscaler Standard (Azure/AWS/GCP standard offering); US Hyperscaler Sovereign Product (Azure EU Data Boundary, AWS EU Sovereign Cloud, Google Cloud with Sovereign Controls); and EU-Native Provider (Open Telekom Cloud, OVHcloud, Hetzner and equivalents).
The CSF's contributing factors for SOV-1 focus on whether decisive authority over the service sits within EU jurisdiction, assurances against change of control, EU-sourced financing, and consistency with EU digital sovereignty objectives. This is the most structurally challenging objective for US hyperscalers, because the decisive authority — board composition, shareholder control, ultimate corporate governance — sits in the United States regardless of how many EU-resident operational structures are created beneath it.
US Hyperscaler Standard / Sovereign: SEAL-1 in most assessments. EU law formally applies to EU operations, but decisive authority — including the ability to discontinue, modify, or redirect the service — remains with the US parent. The CSF specifically asks whether the provider can sustain operations against requests to "cease or suspend the service" from the parent entity; for US-headquartered providers, this assurance cannot be given unconditionally.
EU-Native Provider: SEAL-3 to SEAL-4, depending on ownership structure and financing. Pure-EU-controlled providers with no significant non-EU shareholding or debt financing can achieve SEAL-4. Those with minority non-EU investment or significant US technology dependencies in their stack will typically land at SEAL-3.
Banking implication: For most banking workloads, a SEAL-1 SOV-1 rating from a hyperscaler is acceptable with appropriate risk documentation. For workloads that are classified as critical national infrastructure under DORA's systemic risk provisions, a higher SOV-1 requirement — and therefore a preference for EU-native providers — may be warranted.
SOV-2 is the objective most directly concerned with CLOUD Act exposure. The CSF's contributing factors explicitly include the degree of exposure to non-EU laws with cross-border reach (e.g., US CLOUD Act, Chinese Cybersecurity Law) and the existence of legal, contractual or technical channels through which non-EU authorities could compel access to data or systems. It also covers the jurisdiction of intellectual property creation and development — relevant for AI services where the underlying models are developed and maintained in the US.
US Hyperscaler Standard: SEAL-1. US FISA and CLOUD Act exposure is present and material. Standard contractual commitments to challenge government requests do not eliminate the exposure. EU law applies formally to EU data processing but the extraterritorial reach of US law creates a material non-EU dependency.
US Sovereign Product: SEAL-2 where the sovereign product demonstrably reduces the CLOUD Act attack surface — through EU-entity operations, EU-resident encryption key management, and documented technical barriers to US-staff data access. The residual exposure from the US parent entity's legal obligations prevents achieving SEAL-3 without a fundamentally different corporate structure.
EU-Native Provider: SEAL-3 to SEAL-4. No CLOUD Act or FISA exposure. EU IP jurisdiction. For providers whose supply chain includes significant US-origin software or hardware (virtually all providers), SEAL-4 remains challenging due to SOV-5 dependencies.
Banking implication: For data subject to German banking secrecy (Bankgeheimnis), a minimum SOV-2 level of SEAL-2 is the appropriate baseline, requiring either a hyperscaler sovereign product with customer-managed EU-resident encryption keys or an EU-native provider. For strategic information and M&A-related data, institutions should consider whether SEAL-2 is sufficient or whether SEAL-3 requires EU-native infrastructure.
SOV-3 has two distinct dimensions: data sovereignty (control over data storage, access and deletion) and AI sovereignty (control over AI models, training data, and AI service governance). For regulated banks, the data dimension is the more immediately pressing; the AI dimension becomes critical as AI use in banking decisions expands under the EU AI Act. The CSF requires that only the customer, not the provider, has effective control over cryptographic access to their data — a standard that requires customer-managed encryption keys, not provider-managed keys.
US Hyperscaler Standard: SEAL-1 for data dimension (provider-managed keys by default; data residency not guaranteed without specific configuration). For AI, SEAL-0 to SEAL-1 where AI models are trained and governed in the US with no meaningful customer control over model governance.
US Sovereign Product with CMEK: SEAL-2 to SEAL-3 for data dimension where customer-managed encryption keys with EU-resident HSMs are implemented and data is strictly confined to EU jurisdictions. For AI, SEAL-1 to SEAL-2 where the AI service is EU-hosted but model development and governance remains under US control. SEAL-3 for AI would require EU-controlled model development — not currently available from US hyperscalers for their proprietary AI services.
EU-Native Provider: SEAL-3 to SEAL-4 for data, depending on HSM architecture. For AI built on open-source models (Mistral, LLaMA variants) with EU-based training infrastructure, SEAL-3 or SEAL-4 is achievable.
Banking implication: Banks using hyperscaler AI services (Azure OpenAI, AWS Bedrock, Google Vertex AI) for any workload touching customer data or credit decisions should assess their SOV-3 AI rating explicitly. The EU AI Act's requirements for data governance in high-risk AI systems interact directly with SOV-3 — an AI system that fails SOV-3 is likely also failing the AI Act's data sovereignty requirements.
SOV-4 is closely aligned with DORA's operational resilience and exit planning requirements. The CSF's contributing factors include: ease of migrating workloads without vendor lock-in; capacity for EU operators to manage and maintain the technology without non-EU vendor involvement; existence of EU-based talent; and availability of full technical documentation enabling long-term autonomy. For a regulated bank, this objective essentially asks: could you operate these workloads independently of the cloud provider, and if so, for how long?
For most hyperscaler deployments that use proprietary managed services, the honest answer is that independent operation would require significant re-platforming — achievable in months to years, but not immediately. The DORA exit planning requirement and the SOV-4 assessment are, in effect, asking the same question, and institutions that have completed credible DORA exit planning are well-positioned to assess their SOV-4 rating.
US Hyperscaler: SEAL-2 where the institution has genuine exit capability, EU-resident operational expertise, and workloads built on portable foundations. SEAL-1 where deep proprietary service integration makes realistic exit a multi-year, multi-hundred-million-euro exercise.
EU-Native Provider: SEAL-3 where the provider's support is exclusively EU-based and the technology stack is documented and portable. SEAL-4 requires that the institution can operate the service entirely independently — applicable to on-premise or dedicated infrastructure, not shared cloud services.
SOV-5 is, in practice, the most difficult objective for any cloud provider to achieve at high SEAL levels. The CSF examines hardware manufacturing origin, firmware jurisdiction, software origin and development location, and the full supplier chain including sub-suppliers. Given that the global semiconductor supply chain runs heavily through the United States, Taiwan, South Korea and Japan — and that hyperscaler hardware (custom silicon, networking ASICs, storage controllers) is manufactured and designed outside the EU — SEAL-3 and SEAL-4 on SOV-5 are not achievable by any current mainstream cloud provider.
All cloud providers: SEAL-1 to SEAL-2. The EU does not have a significant domestic hardware manufacturing capability for cloud-scale infrastructure. Even EU-native providers' hardware supply chains run through non-EU manufacturers. This is a widely understood limitation of the CSF framework — it reflects where the EU wants to go (through initiatives like the European Chips Act) rather than where it currently is.
Banking implication: For regulated banks, SOV-5 is an objective where SEAL-1 or SEAL-2 is the realistic achievable level for any provider, and risk acceptance at board level is the appropriate response rather than attempting to architect around a supply chain limitation that is structural rather than contractual. BaFin's supervisory expectation is that this limitation is documented and accepted, not that it is solved.
SOV-6 maps directly onto the technological sovereignty dimension and the lock-in risk discussed in the companion article. The CSF's contributing factors include: non-proprietary APIs and openly governed standards; open-source licensing with rights to audit, modify and redistribute; architectural transparency including data flows and dependencies; and EU independence in computing capabilities. This is the objective most directly influenced by architectural choices — a bank that has deliberately built on portable, open-standards foundations will score significantly higher on SOV-6 than one that has used the same hyperscaler's proprietary services throughout.
US Hyperscaler (proprietary-heavy architecture): SEAL-1. Proprietary APIs, closed-source managed services, no meaningful audit rights to underlying code.
US Hyperscaler (open-standards architecture): SEAL-2 to SEAL-3 where workloads are containerised using open standards (Kubernetes, OCI), data is stored in open formats, APIs are documented and provider-agnostic, and the institution has verified that migration to an alternative provider is architecturally feasible.
EU-Native Provider on open-source stack: SEAL-3 to SEAL-4 where the provider's platform is built on auditable open-source infrastructure (OpenStack, Kubernetes, Ceph) with full architectural transparency.
Banking implication: SOV-6 is the objective most directly within a bank's control. Architectural choices made in the design phase — whether to use proprietary managed services or open-standards equivalents — determine the SOV-6 rating. This should be an explicit design criterion in cloud architecture principles.
SOV-7 is the objective with the most natural alignment to existing banking regulatory requirements. The CSF's contributing factors include: attainment of EU certifications (ISO 27001, ENISA schemes, C5); adherence to GDPR, NIS2 and DORA; Security Operations Centres operating exclusively under EU jurisdiction; customer ability to oversee logs and monitoring directly; transparent EU-compliant breach reporting; and the capacity for EU entities to perform independent security audits. For a DORA-compliant bank with appropriate third-party risk management, many of these requirements are already addressed — though typically through contractual commitment rather than architectural independence.
US Hyperscaler with EU SOC and DORA-compliant contracts: SEAL-2 to SEAL-3. EU-based SOC, ISO 27001 and C5 certification, GDPR-compliant DPA, DORA-compliant contractual provisions, and customer access to audit logs enables SEAL-2. SEAL-3 requires that security monitoring and patch management can be conducted by EU entities independently of non-EU vendor involvement — achievable for some providers with dedicated sovereign support structures.
EU-Native Provider: SEAL-3 to SEAL-4. Fully EU-based security operations, no non-EU parent entity involvement, audit rights exercisable without non-EU intermediary. SEAL-4 requires that the bank itself can conduct security operations entirely independently — not typical for cloud shared-responsibility models.
SOV-8 is the most straightforward objective for regulated banks to assess, and the one with the least banking-specific complexity. The contributing factors cover energy efficiency (Power Usage Effectiveness targets), renewable energy commitment, circular economy practices, and long-term resilience against energy dependency risks. All major hyperscalers have published renewable energy commitments and PUE targets; the distinguishing factor at higher SEAL levels is whether energy supply is genuinely EU-controlled and resilient, rather than reliant on international energy markets subject to geopolitical disruption.
For most banking workloads, SEAL-2 (verifiable renewable energy commitment, measurable PUE, EU-based data centres with EU energy supply) is an achievable and appropriate baseline. ESG reporting requirements may drive some institutions to seek documentation that supports SEAL-3 claims regarding energy sovereignty.
Recommended Minimum SEAL Levels for Banking Workloads
The following table suggests minimum SEAL levels by Sovereignty Objective for three categories of banking workload. These are starting points for institutional assessment, not regulatory requirements — the appropriate minimums depend on each institution's specific risk appetite and the regulatory classification of the data involved.
| Objective | Non-sensitive operational workloads (dev/test, analytics on anonymised data) | Standard customer data workloads (core banking, CRM, general reporting) | Sensitive / regulated data (banking secrecy, strategic, regulatory submissions) |
|---|---|---|---|
| SOV-1 Strategic | SEAL-1 | SEAL-1 (documented) | SEAL-2 preferred |
| SOV-2 Legal/Jurisdiction | SEAL-1 (documented) | SEAL-2 | SEAL-2 minimum; SEAL-3 where feasible |
| SOV-3 Data & AI | SEAL-1 | SEAL-2 (CMEK required) | SEAL-2/3 (institution-controlled keys, EU HSM) |
| SOV-4 Operational | SEAL-1 | SEAL-2 (credible exit plan) | SEAL-2/3 |
| SOV-5 Supply Chain | SEAL-1 (accept & document) | SEAL-1 (accept & document) | SEAL-1 (accept & document) |
| SOV-6 Technology | SEAL-1 | SEAL-2 (open standards preferred) | SEAL-2/3 (open standards required) |
| SOV-7 Security | SEAL-2 | SEAL-2 (DORA-compliant contracts) | SEAL-2/3 (EU SOC, independent audit) |
| SOV-8 Environmental | SEAL-2 | SEAL-2 | SEAL-2 |
The Sovereignty Score and How Banks Should Use It
Beyond the pass/fail SEAL levels, the CSF defines a Sovereignty Score — a weighted quantitative measure computed across the eight objectives. In EU procurement, the Sovereignty Score contributes to the quality score used to rank compliant tenderers. For regulated banks, the Sovereignty Score offers a useful tool for comparing cloud provider options in a structured, documented way — particularly when evaluating the trade-offs between a US hyperscaler's sovereign product and an EU-native alternative for a specific workload category.
The scoring methodology weights each objective's SEAL level contribution by a factor reflecting its relative importance. Banks can adapt the weighting to reflect their specific regulatory profile: a German bank with significant banking secrecy obligations might weight SOV-2 (Legal & Jurisdictional) more heavily than a bank with a simpler data classification profile. The key discipline is that the weighting decisions are made explicitly and documented, rather than left implicit in procurement preferences.
The most immediate practical value of the CSF/SEAL framework for regulated banks is not as a procurement specification — it is as a documentation and risk acceptance tool. BaFin expects institutions to have assessed, documented, and formally accepted the residual risks of their cloud arrangements. The CSF provides a structured, evidence-based methodology for doing exactly that: one that produces a documented SEAL rating for each Sovereignty Objective, identifies the specific contributing factors that prevent a higher rating, and creates a clear basis for the formal risk acceptance that BaFin requires. Institutions that adopt the CSF framework for their cloud governance documentation will find themselves in a stronger supervisory position — not because they have achieved higher SEAL levels, but because they have demonstrated the structured, rigorous risk assessment that the regulator expects.
Next Steps: Conducting Your Own SEAL Assessment
- Obtain CSF v1.2.1 from the European Commission website and read the full contributing factor descriptions for each objective — particularly SOV-2 and SOV-3, which contain the most banking-relevant detail.
- Define your workload classification tiers (at minimum: sensitive regulated data, standard customer data, non-sensitive operational) and determine the minimum SEAL level your institution will require for each tier and each objective.
- For each significant cloud provider arrangement, work through the eight objectives against the CSF's contributing factor questions, gathering supporting evidence from the provider's documentation, certifications, and contractual commitments.
- Identify the SEAL-limiting factors for each objective — the specific contributing factors that prevent a higher rating — and assess whether architectural changes (CMEK implementation, open-standards migration, exit planning) could move the rating upward.
- Document the resulting SEAL ratings, the evidence base for each rating, and the formal risk acceptance for objectives where the achieved level is below the institution's stated minimum.
- Present the Sovereignty Score analysis to the appropriate governance body — typically the CRO or CISO function, with escalation to the management body for material residual risks — and incorporate the output into the DORA third-party risk register.
- Schedule annual reassessment: cloud provider sovereign offerings are evolving rapidly, and a SEAL rating that was accurate in 2026 may not reflect the provider's current capabilities in 2027.