The dependency you can’t audit away
Every BFSI security leader already runs a third-party risk register. The uncomfortable part is that some dependencies can’t be mitigated with a better contract, a data-residency clause, or an EU region, because the exposure is jurisdictional, not technical.
Under the US CLOUD Act, a US-incorporated provider can be compelled to produce or act on data regardless of where that data physically sits. Encryption and EU data centres reduce some risks; they do not remove the provider’s exposure to its home jurisdiction’s export controls, sanctions, and legal orders. This is not a hypothetical reading. It is why the European Commission, in its 2025 Cloud Sovereignty Framework, made supply-chain sovereignty – control over who ultimately owns and can switch off the service – the single highest-weighted assessment objective, and why it now grades providers on a five-level assurance scale (SEAL-0 to SEAL-4) in actual procurement.
The concentration that makes this material is well documented: roughly 70% of the EU cloud infrastructure market is held by three US providers (AWS, Microsoft Azure, Google Cloud), with combined European-provider share in the low teens. When the substrate is that concentrated, “vendor diversification” inside it is not the same as reducing jurisdictional dependency.
For a CISO, the practical question isn’t whether foreign dependency is bad in the abstract. It’s a narrower, answerable one: which dependencies are acceptable, and which sit under a control I’m legally required to guarantee?
A precise definition, because the term is abused
“Digital sovereignty” has suffered definitional inflation. The most usable working definition is the one EU member states signed in the Declaration for European Digital Sovereignty (Berlin, 18 November 2025): the ability to act autonomously and choose your own solutions while still cooperating with global partners where sensible.
Two implications matter for BFSI and are routinely missed:
- Full autonomy is neither achievable nor the goal: Any bank depending on external suppliers – US, European, or domestic – is never 100% autonomous. Sovereignty is therefore a risk-management discipline – a deliberate choice about which dependencies are acceptable, not an attempt to eliminate all of them.
- Sovereignty is a gradient, and it’s layer-dependent: The degree you can hold correlates with how much of the stack you control. Self-hosted logic on your own infrastructure sits high on the gradient. A remote, proprietary, foreign-operated service sits low. Where you land is largely an architecture and procurement decision – which means it’s one you can actually make.
A model for allocating scarce effort: Criticality × Attainability
A bank runs hundreds of systems. You cannot make all of them sovereign, and you shouldn’t try. Two variables decide where effort is worth spending:
- Criticality: How severely would loss of sovereignty hit operations, compliance, or reputation? A core-banking outage is existential; a marketing-site outage is an inconvenience.
- Attainability: How feasible is meaningful sovereignty given today’s market? “Feasible” folds in two things: whether a credible sovereign option exists at all, and what it costs to switch to it. On-prem NDR scores high on both. Wholesale migration off a hyperscaler scores lower – not because sovereign options don’t exist, but because switching cost is high.
The matrix deliberately places unlike systems – a detection tool, a cloud platform, an office suite – on the same two axes. That is the point, not a flaw: it normalises otherwise incommensurable systems so you can rank where effort is worth spending.
The strategic question it answers: where must sovereignty be near-absolute, and where is managed interdependence sufficient?
This prioritization produces:
Priority 0 – Sovereign now, where the technology is mature: Network Detection & Response.
NDR and behavioral network analytics can run entirely on customer or EU-sovereign infrastructure, process telemetry locally, and require no outbound connectivity to foreign clouds. The capability gap versus US vendors in this specific category is small to negligible. Under DORA, a detection failure is not merely an operational event – it’s a reportable ICT incident with supervisory consequences. A control you’re required to guarantee should not itself be a foreign dependency.
Honest caveat: this is strongest for NDR. “Sovereign SIEM” and “sovereign full-SOC tooling” are a bigger claim. Most European BFSI SOCs run Splunk, Sentinel, or CrowdStrike today, and sovereign alternatives at equivalent scale and ecosystem maturity are more contested. Treat NDR as the achievable near-term move, and SIEM/SOAR migration as a longer, evidence-driven evaluation – not a slogan.
Priority 1 – Maintain sovereignty already largely held.
Core banking and payment processing (SWIFT/SEPA) are existential and mostly on-prem or on tightly governed infrastructure. Keep them there.
High criticality but constrained – cloud infrastructure and productivity suites. The IaaS layer everything runs on, and the M365/Workspace tier that holds your email, documents, and customer data, are both critical on availability and on CLOUD Act data exposure. Neither is low-stakes. What makes them managed dependencies is attainability: no equivalent-capability sovereign replacement, and high switching cost. For cloud, sovereign options are proven enough to migrate deliberately (in the Commission’s €180M sovereign-cloud award, providers such as STACKIT, OVHcloud and Scaleway reached SEAL-3); for productivity suites, wholesale migration is rarely realistic today, so the honest posture is mitigate hard – data minimisation, encryption, residency, exit clauses – and consciously accept the residual. In both cases: reduce lock-in on a roadmap, don’t defer the cheaper moves waiting on these.
Security analytics: high criticality, high attainability
This is the opposite quadrant, and it’s where a decision can be made this quarter.
The criticality is not in dispute: a bank that can’t detect intrusion, lateral movement, or exfiltration is one incident away from sanction and reputational damage and under DORA, from a reportable failure. What separates it from the cloud layer is switching cost: deploying sovereign NDR does not require migrating everything else first. NDR and behavioral analytics are mature, and they can run on-premises or in EU-sovereign environments with no foreign API dependency and no cross-border transfer of telemetry. High criticality, and – uniquely among your critical systems – high attainability at low switching cost.
That combination – high criticality, high attainability – is exactly the profile that justifies acting first.
Why a temporary disruption is still disqualifying here
The strongest objection to the “foreign dependency” argument is that most disruptions are short and get resolved. That’s often true, and it’s precisely why the detection layer is different.
A recent, bounded example: in June 2026 the US Department of Commerce imposed export controls that suspended access to certain Anthropic AI models for foreign nationals, including European customers. Access was restored roughly three weeks later once the controls were lifted. The point is not that this specific outage was catastrophic. It’s that the mechanism – a US-jurisdiction vendor rendered unavailable by an act of the US government, not a technical fault – applies structurally to any US-hosted service, including a SOC’s detection layer.
For most systems, a three-week interruption is a manageable incident. For the control that is supposed to be continuously detecting whether you are being breached, an unplanned, externally-imposed blackout of any duration is a gap you cannot report your way out of under DORA. A control layer’s value is in its continuity; anything that can suspend it from outside your jurisdiction is a design flaw, not a supplier hiccup.
The standpoint
European BFSI faces two paths.
One treats sovereignty as an abstract goal to pursue later – when European AI champions emerge, when hyperscalers add regions, when regulators finish clarifying. This path rationalises continued concentration and defers the risk.
The other treats it as an engineering and procurement discipline exercised now, prioritised by criticality and attainability. That path recognises four things:
- DORA is in force (applied since January 2025): ICT third-party risk management requires visibility into vendor dependency and the detection layer cannot itself be an unmanaged dependency.
- Techno-nationalism is structural, not transient: Export controls and sanctions are now standing instruments of statecraft; infrastructure should be designed on that assumption.
- Sovereign NDR is available today: It’s the one critical layer that’s both attainable now and cheap to switch to – so it’s where you start. Sequence everything else.
- The cost of inaction is measurable: Every quarter the detection layer sits on foreign-jurisdiction infrastructure is unquantified operational and regulatory risk.
Digital sovereignty is a gradient, not a flag. For BFSI, the clearest first step is the one that’s both critical and attainable: move the network detection layer onto infrastructure you control. The rest can be sequenced.
Disclosure: Exeon Analytics builds Exeon.NDR, a network detection and response platform designed to run entirely on customer or EU-sovereign infrastructure with no outbound dependency on foreign cloud services. I’ve kept this argument vendor-neutral by design; if the reasoning holds, it holds regardless of which sovereign NDR you evaluate.
References
- Declaration for European Digital Sovereignty (“Berlin Declaration”), signed by EU Member States, 18 November 2025.
- European Commission, Cloud Sovereignty Framework (2025; v1.2.1, Oct 2025) – eight Sovereignty Objectives (SOV-1–8), SEAL-0 to SEAL-4 assurance levels; first applied in the €180M sovereign-cloud procurement awarded April 2026.
- DORA – Digital Operational Resilience Act (EU 2022/2554), applied from 17 January 2025.
- BaFin: BAIT/VAIT requirements for IT and cloud services.
- European Parliament briefing on EU software and cloud dependencies (US hyperscaler share of EU cloud market ≈70%).
- US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018).
- Capri, A. – Techno-Nationalism (for the framing of technology supply chains as instruments of statecraft).
