Executive Summary
Digital sovereignty for banks and financial services enterprises has shifted from a data-residency and political debate into a practical discipline. It is increasingly essential for operational resilience, regulatory assurance, cloud and AI strategy and how enterprises manage their dependency on providers. For institutions in DACH and throughout Europe, the question has become concrete: when does the loss of control, access, resilience, data availability or the option to exit a sourcing contract pose unacceptable risk?
Risk-calibrated sovereignty (RCS) is the application of specific sovereignty controls to an organization’s workloads, data and providers where loss of control matters most and standard arrangements elsewhere. Risk-calibration gives a BFSI organization a level of control that is defensible under severe but plausible disruption, not the minimum control it can get away with. Consistent with recent analyst and academic framing, sovereignty is treated as a set of graduated decisions across the technology stack rather than an all-or-nothing architecture.
Sovereignty requirements are an extension of risk-based vendor management: they should impose incremental governance, investment and provider scrutiny in proportion to risk exposure, not to spend volume.
The discipline of digital sovereignty rests on five principles:
- Risk-based, not spend-based – rather than contract value, controls follow dependency, criticality, data sensitivity, recoverability and exit feasibility.
- Strategically designed and implemented – controls are anchored in IT and sourcing strategy, expressed through provider-ecosystem design and executed in sourcing and vendor management.
- Evidence-based – a claim of “EU hosting” or “sovereign” is insufficient without evidence of sovereignty across control plane, support access, metadata, key custody, subcontractors and tested/planned exit scenarios.
- Workload-specific – workloads, capabilities and functions should be classified to receive different requirements.
- Feasible instead of ideological – organizations should avoid both sovereignty theatre and sovereignty maximalism; the goal is sufficient control where control matters most.
Why Sovereignty Is Now a Banking Risk Discipline
Many banks, and especially European banks, face a convergence of pressures: geopolitical uncertainty, concentration in a handful of global technology platforms, heightened supervisory expectations for operational resilience, rapid AI adoption and deep dependency on complex provider ecosystems. Sovereignty has become the working language for control over data, infrastructure, management planes, cryptography, evidence and recovery from unintended disruptions.
The regulatory backdrop has hardened. DORA went into law in January 2025, and, in November 2025, the European Supervisory Authorities designated the first critical ICT third-party providers (CTPPs) for direct EU oversight. This is concrete evidence that concentration in a few providers is now a supervisory concern. The ECB’s 2025 Guide on outsourcing to cloud service providers reinforces proportionate, risk-based treatment.
Less discussed but equally important, the EU Data Act’s cloud-switching and portability obligations took place in September 2025. This gives banks enforceable workload switching and exit rights and removes most switching fees until January 2027. The EU AI Act adds a further layer: obligations for general-purpose AI model providers began in August 2025, shaping how banks assess external models, hosting and data flows.
Two further regimes raise the security and resilience baseline: 1) NIS2 broadens cybersecurity and incident-reporting duties across essential entities and their supply chains, and 2) and the Cyber Resilience Act sets security requirements for digital products. Both have bearing on provider selection, subcontractor assurance and resilience evidence.
Figure 1: EU Regulatory Timeline – Key Sovereignty-related Milestones
The policy debate matured into concrete frameworks during 2026. Germany and France presented a joint definition of digital sovereignty in June 2026 – developed by the German digital ministry (BMDS), the Chancellery and the French Directorate General for Enterprise (DGE) as a contribution to the EU Tech Sovereignty Package – describing sovereignty as the ability to develop, provide, use, adapt and control digital technologies independently.
The definition unfolds into six risk-based dimensions:
- Enforcement capability
- Technology skills
- Economic value creation
- Protection of sensitive data
- Substitutability and interoperability
- Infrastructure resilience
The European Commission’s package adds the Cloud and AI Development Act and an EU Open-Source Strategy. Demand-side sentiment points the same way: Bitkom reports that 78% of German companies are concerned about dependency on a handful of non-EU providers, and almost two thirds treat EU data-center location as an important selection criterion. Much of this momentum is aimed at the state and the public sector, yet it sets the direction of travel for regulated industries – banks should expect the same vocabulary to surface in supervisory dialogue, client due diligence and interpretations of digital resiliency as described by the DORA regulation.
Beyond Data Residency
Data residency still matters, but on its own it no longer guarantees control: a workload can be hosted in an EU data center while its administration, support and encryption keys are governed from outside European jurisdiction.
Recent analyses of cloud control planes argue that sovereignty must extend to governance authority, privileged access, cryptographic trust, data-lifecycle control, observability and incident response. For a bank, the relevant tests are therefore not only “where is the data stored?” but:
- Who is authorized to administer the environment?
- Who is authorized to reach metadata and telemetry?
- Where are encryption keys controlled?
- How and from where is support delivered?
- Which legal entities are involved?
- Can we keep operating if provider access is impaired?
This last point is sharpened by extraterritorial-law exposure (e.g., the U.S. CLOUD Act and the PATRIOT Act), which can reach a global provider regardless of where European data physically sits.
Please fill out this form to continue.
A Fast-moving Provider Landscape
Provider options have expanded quickly:
- AWS opened its European Sovereign Cloud in Brandenburg, Germany, operated by EU-resident personnel under an EU-controlled parent in January 2026.
- Microsoft has announced a three-tier model spanning Sovereign Public Cloud, Sovereign Private Cloud and National Partner Clouds (including Delos Cloud in Germany and Bleu in France).
- Google and T-Systems offer a jointly operated German sovereign cloud (T-Systems Sovereign Cloud powered by Google Cloud).
- Schwarz Digits, the technology arm of Germany’s Schwarz Group (Lidl and Kaufland), is building a sovereign workplace offering together with Google: Google Workspace running on Schwarz’s STACKIT cloud with client-side encryption and EU-only data residency and backup – explicitly aimed at regulated sectors including financial services.
- European providers such as OVHcloud position SecNumCloud-qualified services for sensitive workloads.
The landscape spans a broad spectrum: hyperscaler sovereign regions, European providers, national partner clouds, private and regulated hosting, sovereign-SaaS controls and cryptographic patterns.
The task for banks is to match the right pattern to the right workload and to test the substance behind each “sovereign” label. For banks, the objective reaches beyond protecting “data”: sovereignty is about ensuring stable and secure business as trusted institutions for retail and wholesale clients, as shown in Figure 5 below.
Sovereignty as an Extension of Risk-based Vendor Management
Sovereignty is best understood as the next evolution of mature vendor management. Mature, resilient functions already scale effort by criticality, data sensitivity, dependency, substitutability, concentration and regulatory impact. Sovereignty adds jurisdictional, control-plane, data-availability and exit dimensions.
Most importantly, spend is an unreliable proxy for risk: a low-spend niche SaaS provider may process sensitive customer data or create a severe exit constraint, while a high-spend provider may support only commodity services. Exemplary findings in ISG’s risk assessments for clients often show a jump by two risk category levels compared to previous spend level categorization.
| Traditional Vendor-management Lens | Sovereignty-enhanced Lens |
| Spend, contract value and commercial importance | Dependency exposure, operational criticality and substitutability |
| Service levels and commercial performance | Data availability, continuity, crisis access and resilience evidence |
| Standard information-security questionnaire | Control-plane access, key custody, metadata exposure, subcontractor and support model |
| Exit clause included in the contract; vague scenario descriptions for unintended termination | Tested exit path, portable data, deployable alternative and runbook readiness |
| Annual supplier review cycle | Risk-triggered reviews aligned to regulatory, geopolitical, AI and platform change |
Figure 2: Traditional vs. Sovereignty-enhanced Vendor Management – Graduated Assessment Depth (levels 1–5)
In practice, this means provider tiering must incorporate sovereignty exposure rather than contract value alone; due diligence must test operational control and exit feasibility before selection; evidence must be collected continuously, not only at onboarding; and residual risk must be explicitly accepted where no via-ble sovereign alternative exists.
Public procurement shows where contracting practice is heading. Germany’s Vergabebeschleunigungs-gesetz (in force since July 2026) makes “aspects of digital sovereignty” an explicit award criterion (§ 58 VgV) and – more consequentially – a permissible contract-performance condition (§ 128 GWB) that binds the provider for the entire contract term, with termination and penalty rights on breach.
Banks should mirror this pattern in their own sourcing: sovereignty requirements deserve the status of on-going, evidenced contractual obligations – data localization, access rights, certified infrastructure – with exit consequences attached, in addition to being scored at selection.
Because banks consume technology through various ecosystems (hyperscalers, SaaS platforms, integra-tors, managed-service and data providers, AI model providers and their subcontractors) provider-ecosystem management becomes the bridge between strategy and execution.
Risk-Calibrated Sovereignty as an Operating Principle
RCS is the deliberate application of sufficient controls to the workloads, data, providers and technology layers where loss of control would create unacceptable risk. It rejects the assumption that every workload needs a fully sovereign stack and equally rejects the assumption that standard public-cloud, SaaS or AI services are acceptable merely because they are convenient or without practical alternatives.
The objective is risk-managed control, consciously designed and transparently governed without losing functionality and business value. Banks should guard against two failure modes:
- Sovereignty theatre – claims based on EU data-center location or marketing labels without enforceable, evidenced operational control, producing false assurance and a weak audit posture.
- Sovereignty maximalism – attempting to replicate every service with a sovereign alternative regardless of risk, cost or business value, producing excessive cost, slower innovation and operational fragility.
 |
 |
 |
Figure 3: Finding the Right Scale of Sovereignty – Theatre, Dependency Swap and Maximalism
Between these two poles sits a subtler trap: buying sovereignty at the price of new dependency. The risk evaluation of sovereignty measures and sovereign alternatives must therefore also assess the new dependencies and lock-ins they create. Substituting a hyperscaler with a single EU vendor can simply ex-change one concentration risk for another, often with proprietary interfaces, a narrower ecosystem and less proven substitutes.
Exit strategies need to take this into account: portability, second sources and tested exit runbooks apply to the sovereign alternative no less than to the provider it replaces. Open standards, modular architectures, a software bill of materials (SBOM) and credible open-source options are the practical instruments that keep substitutability real and prevent a sovereign placement from becoming just another single-vendor bet.
A risk-calibrated posture can still set a demanding bar. For a critical payment workload, for example, it may require strong EU operational control, customer-held keys, tested exit, independent backup, strict support-access limits and board-approved residual risk. For commodity collaboration, it may mean contractual controls, an EU data boundary, baseline encryption, standard monitoring and a documented residual-risk statement including a flexible, tested second-source at hand in case of sudden termination or unavailability.
Critics of RCS argue that, faced with tail-risk scenarios such as abrupt sanctions, legal compulsion or geo-political rupture, a “minimum” posture can leave a bank exposed precisely when control matters most, and that the cost of fuller sovereignty is simply the price of genuine resilience. The tail risk is concrete: when U.S. sanctions hit the International Criminal Court’s chief prosecutor in 2025, access to his Microsoft-hosted e-mail was lost, and the court has since begun moving to open-source alternatives. For a bank, an equivalent suspension of a U.S.-operated payments, sanctions-screening or trading service would collide within seconds and days with SEPA instant-payment and settlement obligations – a gap no contractual remedy can bridge quickly enough.
RCS takes this objection seriously and responds with governance: the trade-off is made explicit and board-owned (like with every regulatory requirement for risk-awareness and conscious risk-acceptance by the board): where a credible tail risk would be catastrophic and irreversible, the workload belongs in a higher tier with stronger controls, and the residual risk of anything less must be consciously accepted rather than assumed away.
From Strategy to Execution
Sovereignty requirements must be anchored in IT and sourcing strategy, derived in provider-ecosystem management and executed through sourcing and vendor management. Without this chain, sovereignty degenerates into a late procurement checklist or an architecture exception. It cannot be owned by sourcing alone because many requirements are architectural, operational and legal; nor by architecture alone be-cause provider leverage, contractual enforceability and exit economics determine feasibility.
A workable operating model defines decision rights across:
- CIO / CTO: technology direction, cloud principles and architecture guardrails
- CISO / Technology Risk: control requirements, security evidence and resilience testing
- CRO / Operational Risk: alignment to critical operations, scenario analysis and residual-risk acceptance
- Sourcing / Procurement: market engagement, provider ecosystem management, commercial structure and contractual commitments
- Vendor Management: ongoing governance, ensure operational excellence, evidence collection, reviews and remediation
- Legal / Data Protection: jurisdiction, privacy, subcontractors and enforceability
- Enterprise Architecture, Portfolio and Service Design: category management, workload placement, portability, integration and exit design
- AI Governance: model governance, prompt and data flows, runtime evidence
Classifying Workloads and Assessing Risk
A sovereignty program starts with workload and scope classification: the same provider may be acceptable for one workload and unacceptable for another. Classification should reach beyond applications to data domains, integration and network services, identity, security tooling, backup and recovery, AI models, managed-service operations and developer toolchains, where hidden control points often sit.
| Tier | Typical examples | Sovereignty posture |
|---|---|---|
| Tier 0 – Crown jewels | Core banking, payments, identity, key management, core IP applications | Maximum control; EU operation, customer-held keys, tested exit, board-approved residual risk |
| Tier 1 – Regulated critical | AML, fraud, credit decisioning, customer data platforms | Strong controls and evidence; sovereign or enhanced-control placement |
| Tier 2 – Important, substitutable | Analytics, workflow, non-critical channels, developer platforms | Proportionate controls; active portability and exit planning |
| Tier 3 – Commodity | Productivity, marketing, low-risk collaboration | Baseline contractual controls and an EU data boundary |
For each workload, assessment turns on four questions:
- How dependent are we?
- Can we access and recover data under stress?
- Can we exit or substitute within tolerance?
- Do we retain ownership of the intellectual property our systems and AI models generate, rather than ceding it to the provider?
Scoring should combine inherent risk, control maturity and residual risk and should drive concrete control and mitigation efforts rather than a theoretical compliance score. Each assessment should resolve to one of four outcomes:
- Accept: acceptable with baseline controls and documented residual risk
- Control uplift: acceptable once specific technical, contractual or operational controls are in place
- Sovereign placement: move to a sovereign cloud, European provider, private platform or en-hanced-control pattern
- Strategic remediation or exit: dependency is unacceptable; reduce it, build exit capability or re-place the provider
In this respect, the sovereignty assessment adds a more sophisticated assessment to the question of what any institution’s “core IP” is that should always be kept internally.
Ready-made assessment vocabularies are emerging from the public sector. The European Commission’s Cloud Sovereignty Framework (CSF) defines eight sovereignty objectives with five Sovereignty Effec-tiveness Assurance Levels (SEAL-0 to SEAL-4) and a weighted sovereignty score. It has already been applied to a tender of roughly €180 million.
In Germany, the IT security governing body BSI’s C3A catalogue (Criteria enabling Cloud Computing Autonomy, April 2026) complements the BSI’s established C5 catalogue (Cloud Computing Compliance Criteria Catalogue), the de-facto attestation standard for cloud security in German regulated industries: where C5 attests how secure a cloud service is, C3A assesses whether it can be operated self-determinedly. Together with the six dimensions of the Franco-German definition, these catalogues give banks an externally recognized basis for tier definitions, due-diligence questionnaires and provider scoring.
AI Sovereignty: A Distinct Dimension
AI adds a second layer of sovereignty exposure on top of infrastructure: control must now extend to mod-els, training pipelines and the data flowing through them. Beyond where data sits, banks must track where prompts, embeddings, fine-tuning data, logs and model outputs are processed and stored; whether a pro-vider may use bank or customer data to train or improve its models, and whether any opt-out is contractual-ly enforceable; and how decisions made or supported by external models can be explained and evidenced to supervisors.
Ownership is the dimension most easily lost. The data may be the banks’, but the models, weights and generated outputs often remain the provider’s – a subtler form of lock-in compared to infrastructure de-pendency. Sovereignty due diligence should therefore cover IP rights in AI-generated content, model and fine-tuning licensing, and the risk of proprietary knowledge leaking into a shared model.
Exiting an AI model or its provider deserves the same discipline as a cloud exit: can the bank move to another foundation model without losing essential capability, accumulated tuning or audit evidence? A test-ed second source matters here, too – and the practical European foundation-model options remain limited, with Mistral currently the most prominent EU-based provider (but still trailing far behind current top-tier models in benchmarks and leaderboards), which makes deliberate abstraction (keeping prompts, retrieval data and orchestration portable) the more reliable safeguard.
Treated this way, AI sovereignty becomes an extension of the same risk-based logic: bringing AI providers into vendor, technology and model-risk governance, and aligning evidence with the EU AI Act’s expecta-tions for general-purpose models, human oversight and auditability. The objective is control, transparency and accountability over how AI is built, hosted and governed.
A 24-month Roadmap
Sovereignty is best delivered as a staged transformation that integrates into existing vendor, outsourcing, cloud and resilience governance, rather than a one-off assessment.
A program should baseline two things in parallel: the sovereignty risk of individual workloads (the tiering above) and the organization’s sovereignty maturity – a 1–5 assessment of control, transparency and resili-ence across data, infrastructure and cloud, AI governance, operational resilience, and skills and supplier alignment. The maturity baseline shows where capability, not just architecture, must improve, and sequences the roadmap accordingly.
| Phase | Horizon (month) | Key outcome |
|---|---|---|
| 1. Mobilize and align | Month 0–2 | Executive mandate, sovereignty taxonomy, risk appetite and decision rights |
| 2. Assess exposure | Month 2–5 | Inventory of critical workloads, data domains, providers, AI and concentration |
| 3. Classify and prioritise | Month 4–7 | Tiered workload register with dependency, data-availability and exit scoring |
| 4. Define target controls | Month 6–10 | RCS control catalogue, RFP criteria, contract clauses and evidence requirements |
| 5. Pilot and scale | Month 9+ (individual) | Tier 0/1 pilots (key custody, data export, exit runbooks), then rollout and board reporting |
In the first 90 days, banks should prioritize three moves:
- Add sovereignty exposure to the vendor-tiering model.
- Rapidly classify 20-30 candidate workloads across cloud, SaaS, data and AI.
- Select two pilot scopes (e.g., one infrastructure and one SaaS or AI) to test evidence and exit in practice rather than on paper.
ISG helps enterprises position digital sovereignty as a strategic extension of vendor management, sourcing and technology risk. We help organizations identify workload, data, provider, AI and ecosystem dependencies requiring action, align provider roles and sourcing channels, turn sovereignty into ongoing governance, evidence collection, issue management and board reporting. Contact us to find out how we can help your organization.
About the author
