Search for digital sovereignty and you find two literatures that never meet. Sovereignty content lists EU alternatives to US SaaS, swap this vendor for that one. Build-versus-buy content weighs cost and features and never cites a regulation. Yet the strongest sovereignty argument is legal and structural, and it points past substitution: residency does not change jurisdiction, EU law is now openly legislating for exit, and the only stack no third party can switch off is one you own. This piece connects the law to that engineering conclusion. One caveat runs throughout: we are engineers, not lawyers, treat every legal summary here as a starting point and verify specifics against current texts and counsel.
What does digital sovereignty actually mean for a software stack?
Sovereignty is your ability to keep operating on your own terms when a vendor, a foreign court, or a price change says otherwise. It has three layers: where data physically lives (residency), whose courts can compel access to it (jurisdiction), and who controls the code that processes it (ownership). Most public debate argues only about the first.
The layers fail independently:
- ▸Residency fails when your provider is legally reachable from elsewhere regardless of server location.
- ▸Jurisdiction fails when your EU vendor is acquired, or turns out to run on a non-EU hyperscaler underneath.
- ▸Ownership is the only layer where failure requires a decision of your own.
Keep the three separate. Conflating them is how companies buy an EU region and believe they bought sovereignty.
Why doesn't EU data residency protect you from foreign jurisdiction?
Because jurisdiction attaches to the provider, not the server. The US CLOUD Act, as commonly summarized, lets US authorities compel providers subject to US jurisdiction to produce data in their possession or control wherever it is stored. An EU region of a US-parented cloud changes latency and GDPR transfer mechanics, not who can be compelled.
The Act's exact reach is contested, it contains comity mechanisms, and providers do challenge orders, so treat any confident summary, including this one, as a pointer to primary sources. But the direction was underlined in 2025, when press coverage of French Senate hearings reported a major US cloud provider declining to guarantee that EU-hosted data could never be handed over to US authorities. Residency is an engineering property; jurisdiction is a corporate one, and it travels with ownership structures you do not control. We covered the residency layer itself in Sovereign Cloud and EU Data Residency in 2026: An Engineering Playbook.
What switching rights does the EU Data Act actually give you?
The Data Act's cloud-switching chapter, applicable since September 2025, with switching charges being phased out into 2027, obliges data-processing services, SaaS included, to remove contractual, commercial and technical obstacles to switching: capped notice periods, defined migration windows, export of your data in a structured, machine-readable format. Verify timelines and scope against the current text.
Read what the law is telling you: the EU has concluded that lock-in is a market failure serious enough to legislate against. But statutory rights get you your data, not your operations. The schema you receive is still the vendor's, and functional-equivalence obligations aim mainly at like-for-like infrastructure services, not at recreating a decade of CRM customization somewhere else. The Act opens the door; you still have to be able to walk through it. The engineering to-do list is in EU Data Act, September 2026: Access-by-Design and Cloud Switching Obligations.
How do NIS2 and DORA turn vendor dependence into a compliance finding?
Both regimes make suppliers your regulated problem. NIS2 obliges in-scope companies to manage supply-chain risk, which includes the SaaS vendors sitting inside critical workflows. DORA, for financial entities, goes further: documented exit strategies for critical ICT third parties are expected, a regulator can ask to see your plan for leaving a vendor.
In practice that converts an architecture opinion into audit evidence:
- ▸A critical workflow running on a vendor with no tested export path is now a supply-chain risk you must write down and defend.
- ▸An exit strategy that says we-would-migrate, with no data model, no runbook and no rehearsal, is the paper kind supervisors discount.
The engineering translation of both regimes is in EU Cyber Compliance for Engineers: NIS2, DORA and the Cyber Resilience Act, and the scope surprise for ordinary suppliers in DORA for Non-Banks: The Operational-Resilience Work Nobody Scoped. Scoping is fact-specific, confirm yours with counsel, not a blog.
Why do EU-SaaS substitutes only move the problem?
Replacing a US SaaS with an EU SaaS genuinely improves jurisdiction and usually residency, and changes nothing structural. Your workflows still live in someone else's code, your data in someone else's schema, your roadmap in someone else's board meetings. You have changed landlords. That is sometimes worth doing; it is not sovereignty.
Three quiet failure modes of sovereignty-by-substitution:
- ▸The substrate problem. Many EU SaaS products run on US hyperscaler infrastructure underneath. Check the sub-processor list before celebrating.
- ▸The acquisition problem. Smaller EU vendors are acquisition targets, and the acquirer chooses the new jurisdiction. Your due diligence has a shelf life.
- ▸The parity problem. You often trade a mature product for a thinner one while keeping every lock-in mechanic: export friction, per-seat pricing, roadmap dependence.
Why is code you own the terminal form of sovereignty?
Every measure short of ownership is a mitigation: residency mitigates transfer exposure, EU vendors mitigate jurisdiction, the Data Act mitigates lock-in, contracts mitigate price shocks. Code you own, source in your repository, data in your schema, deployable on infrastructure you choose, is the only configuration in which no third party's legal exposure or business decision can turn your operations off.
Ownership here means something specific:
- ▸Source and build: you can modify and redeploy without anyone's permission or license audit.
- ▸Schema: your data model is documented and yours, so the next migration is an infrastructure choice rather than a hostage negotiation.
- ▸Portability: the same system runs on a hyperscaler, an EU provider, or your own hardware, Sovereign-by-Design: Architecting EU and North Africa Data Residency Without a Hyperscaler shows the far end of that spectrum.
This does not mean owning everything. It means owning the systems whose loss or seizure would actually threaten the business. The decision framework and the migration path itself are in the pillar guide, Escaping SaaS: The Complete Guide to Migrating Your Business to Custom Software.
What does a sovereignty-driven exit look like in practice?
Not a purge. Rank systems by what a forced loss would cost: customer and operational data, records regulators care about, workflows the company stops without. Own that core; keep renting the commodity edge, email delivery, video calls, payroll. Extract data first, build alongside, cut over gradually, and keep the evidence trail regulators now expect.
Two moves make it concrete:
- ▸Run an exit-readiness audit on your most critical vendor before its next renewal, lock-in mechanisms, export quality, contract clauses, as in The CRM Exit-Readiness Audit.
- ▸Build a thin replacement prototype before you negotiate. It is leverage at the renewal table and the seed of the real exit if talks fail, Build the Exit Before the Renewal.
And cost the ownership honestly: owning software is a subscription to your own roadmap, with a real year-two line item, priced openly in Custom Software Is a Subscription to Yourself.
What are the honest limits of the ownership argument?
Owning code exempts you from nothing: GDPR still applies, NIS2 duties still apply, and the patching pager is now yours. A company that cannot operate software reliably gains no sovereignty by owning it, it gains an unmaintained liability. Sovereignty is an operational capability you build, not a procurement decision you sign.
Be suspicious of your own motivated reasoning. If a workload is commodity, low-sensitivity and well served by a vendor whose jurisdiction you can live with, renting remains the right answer. The sovereignty case is strongest exactly where the dependency runs deepest: core operational systems, regulated data, workflows a vendor could reprice or retire on ninety days' notice. Spend your build capacity there and nowhere else.
How TuniCyberLabs helps
We work both layers of this problem from the EU and North Africa: the compliance engineering, NIS2 and DORA evidence, exit strategies a supervisor will accept, and the custom builds that end the dependency instead of documenting it. If your renewal calendar contains a vendor you could not leave today, that gap is the finding; closing it is the project.
Book a sovereignty and exit review, one critical vendor, one tested export, one honest plan.