Writing · Sovereignty
The question American CISOs aren't asking.
In October 2025 at European Defence Week in Paris, Matthias Vallentin (CEO of Tenzir) put a sentence on record that landed differently in different rooms: "Europe's defence runs on American cloud infrastructure." For European security professionals, this wasn't news — it was the strategic vulnerability they've been working to solve for a decade. For American CISOs evaluating security data platforms, sovereignty isn't on the spreadsheet at all. That asymmetry is the part that matters.
What digital sovereignty actually means
Strategic autonomy, not nationalism.
The framing that gets the conversation off the rails fastest: treating sovereignty as European protectionism dressed up in security language. It isn't. It's the ability to operate critical infrastructure without dependence on foreign entities that could restrict access during geopolitical conflicts. Three concrete pressures shape it from the European side. Dependency risk on US cloud infrastructure carries US export-control and CLOUD Act jurisdictional surface. GDPR plus the evolving EU regulatory stack (NIS2, DORA, the Cyber Resilience Act) requires data residency and control guarantees that US vendors struggle to provide convincingly. And defence and critical-infrastructure sectors need guarantees that their security data won't become a leverage point in a future geopolitical event.
Vallentin's sharper version of the framing: the US built tech dominance by owning the full data stack; Europe is renting US infrastructure and calling it sovereignty. The European critique isn't that the infrastructure is bad; it's that it isn't theirs.
The grounded scenario that keeps European CISOs up at night runs as follows. A European financial institution stores security logs in a US-based SIEM (Splunk, Microsoft Sentinel, CrowdStrike Falcon). The logs contain forensic evidence of fraud originating from a geopolitically sensitive region. US law enforcement issues a CLOUD Act request for the data. The European institution is bound by GDPR not to transfer that data outside the EU without stringent safeguards. The US vendor is legally obligated to comply with US law regardless of EU contractual terms. The result is legal deadlock — the data is simultaneously required and forbidden to be accessed. Schrems II is exactly this fact pattern, with court precedent attached. It's not hypothetical; it's the Schrems II ruling reality, with the failure modes already documented.
How vendors are responding
Three strategies, different levels of honesty.
Full sovereign deployment.
The infrastructure runs entirely in the customer's environment — their AWS account, their Azure tenant, their on-premises hardware. No data leaves the customer's control boundary. The vendor provides software, not a hosted service. Tenzir's AWS-native deployment model is an example: open-source execution engine running in the customer's account, customer owns the deployment. Trade-off: more operational complexity for the customer, in exchange for a sovereignty guarantee that survives geopolitical disruption.
Regional data residency.
AWS, Microsoft, Google, and others offer EU-region deployments with contractual commitments about data locality. AWS EU regions in Frankfurt, Paris, Stockholm, Milan. Microsoft's EU Data Boundary commitments. AWS European Sovereign Cloud, currently being built out for Germany and France. Trade-off: meaningfully improved compliance posture, but the ultimate corporate control still sits with a US-headquartered entity subject to US law. CLOUD Act applicability isn't waved away by region selection.
Ignore the question and hope.
The default for US-centric vendors who treat sovereignty as an edge case and focus on the US market. Works until the vendor tries to sell into European defence, critical infrastructure, or regulated financial sectors — at which point sovereignty becomes table stakes and the deflection becomes a deal-blocker. Increasingly common to see this pattern produce after-the-fact "we're working on it" announcements that arrive 18 months after the European deal closed with a competitor.
The licensing distinction
Open source and source-available are not the same property.
Sovereignty conversations get derailed by licensing language that sounds open and isn't. The distinction that matters in a procurement contract:
Source-available. You can read the code. You can report bugs. You can suggest features. You cannot fork, modify, or deploy independently in production without licensing restrictions. The HashiCorp BSL switch and Elastic's SSPL are the canonical examples. The vendor retains commercial control.
Actually open. Apache 2.0, MIT, GPL or similar permissive licenses. Fork, modify, deploy without restriction. No vendor-controlled "enterprise tier" required to run in production. The customer has the legal right and technical ability to operate independently of the vendor.
For sovereignty, the difference is not academic. If the vendor can revoke your license, change the terms, or restrict deployment models, you don't have sovereignty — you have temporary permission. True sovereignty requires both the legal right and the technical capability to keep running if the vendor relationship ends or is restricted by law. Apache 2.0, MIT, and GPL are sovereignty-compatible. Open-core models with proprietary enterprise features and source-available licenses with deployment restrictions require legal review at minimum, and often functional replacement work for production-grade deployments. European procurement teams scrutinize this; American procurement teams routinely don't.
Why US CISOs should care
Even without European operations, the question travels.
The first reason is regulatory globalization. GDPR is the strictest framework today; NIS2, DORA, and the Cyber Resilience Act extend the framework into critical infrastructure, financial services, and product security. Brazil's LGPD is GDPR-derived. China's PIPL and Cybersecurity Law impose data sovereignty and localization. India's DPDP framework is moving in the same direction. The pattern is clear: European requirements today are global baseline expectations within five to seven years. Architecture choices made now are still in production then.
The second reason is M&A surface. Plans to expand into European markets, the possibility of acquiring a European company, or being acquired by a European entity all bring sovereignty into the diligence process. Dependency on US-only vendors that can't provide EU sovereign deployment becomes either a deal-blocker or a valuation concession. Sovereignty-compatible architecture meaningfully widens the acquirer pool.
The third reason is that the customer questions are changing. European customers — and increasingly large US enterprise customers post-SolarWinds — are asking whether the platform can run entirely in their AWS EU account, whether the license is truly open source rather than source-available, what happens if export controls restrict the service to a country, and whether they can fork and maintain the platform independently if the company is acquired. Vendors who can't answer these confidently lose the deal. Vendors who can, win.
The fourth reason is the simplest: sovereignty-compatible architecture (open-source licensing, customer-controlled deployment, regional data residency) is good architecture regardless of motivation. It produces vendor independence, operational resilience, and regulatory flexibility. The geopolitics-as-motivation framing is one path to the architecture; the architecture's properties are valuable across many futures, including ones where the geopolitics never escalate.
Practical guidance
The questions worth asking, in the procurement conversation.
For platform decisions where sovereignty might matter — EU operations now, EU operations within the five-year horizon, sales to regulated European customers, or simple architectural resilience — the questions worth putting in writing during procurement:
- Can the platform run entirely in EU infrastructure (AWS EU, Azure EU, on-premises)?
- Is data processing restricted to EU regions by architecture, not just by policy commitment?
- Can the customer operate the platform independently if vendor access is restricted?
- Is the licensing truly open source (Apache 2.0, MIT, GPL) — or source-available with deployment restrictions?
- What is the vendor's documented response plan if a CLOUD Act request and GDPR obligation conflict on customer data?
- What happens to support, services, and product access if export controls restrict the vendor's service to a customer country?
- If the vendor is acquired by a non-sovereignty-compatible entity, can the customer migrate or fork?
Vendors who answer these confidently with documented architectural specifics are the ones whose sovereignty claims survive contact with the legal review. Vendors who treat the questions as edge cases are signaling the actual architecture isn't there yet. Both answers are useful, just for different reasons.
Sovereignty-compatible is just resilient architecture under a different name.
The platform-baseline anchor hypothesis on the research page applies the same lens — open formats, neutral catalogs, replaceable engines — without leaning on the geopolitics framing.