The EU Tech Sovereignty Package: what it actually changes for your SaaS stack
Brussels unveiled its Tech Sovereignty Package on 27 May. The framing has shifted from a defensive reaction to a structured industrial-policy push. Here is what changes for a buyer in 2026, and what does not.
On 27 May 2026 the European Commission unveiled its Tech Sovereignty Package, a coordinated bundle of policy instruments anchored by the Cloud and AI Development Act (CADA), the cloud/AI law the Commission is tabling alongside the package, which would harmonise an EU-wide definition of "sovereign cloud" and ease data-centre build-out, plus the second iteration of the Chips Act and a refreshed open-source strategy. Its headline measure is a proposed restriction on the US hyperscalers (AWS, Azure and Google Cloud) for sensitive public-sector data in healthcare, finance and the judiciary, across all 27 member states. It is a proposal, not yet law: it still needs the member states' approval to take effect. The announcement was telegraphed for weeks; the substance, less so. This page is a pragmatic reading from the perspective of someone who has to make actual SaaS purchasing decisions in the next twelve months, not a policy explainer.
The single most useful framing is this: the package is the institutional consolidation of moves that were already happening, not a new direction. NIS2 has been in force since October 2024. DORA has been in force since January 2025. The €180M sovereign cloud tender awarded on 17 April 2026 to Scaleway, Clever Cloud, OVH and STACKIT (with AWS, Azure and Google Cloud excluded) was the signal that real procurement budget had begun to move. France is migrating 2.5 million civil servants off Microsoft. Schleswig-Holstein is 80% Microsoft-free. The International Criminal Court dropped Microsoft for OpenDesk in November 2025. Dutch banks have publicly begun seeking alternatives. The package is the framework that organises these moves into a doctrine.
For a buyer, the practical question is not "is US software now illegal". It is not, and the package proposes no general ban for private-sector buyers. What it does propose is a binding limit on the US hyperscalers for sensitive public-sector data; everything outside that perimeter is direction-of-travel, not prohibition. The practical question is where on the spectrum of resilience your current stack sits, and how much of that you need to change before your next renewal cycle.
Three things change for European SaaS buyers in the second half of 2026, and they change at different speeds.
Public-sector procurement hardens immediately, and now names the hyperscalers. The package's headline restriction targets AWS, Azure and Google Cloud directly for sensitive public-sector data in healthcare, finance and the judiciary. Beyond those sectors, tenders for regulated EU entities (public administration, defence supply chain, the rest of finance) will increasingly write sovereign-cloud and EU-sub-processor requirements directly into the bid. For vendors selling into these markets, the absence of an EU hosting region or a clean sub-processor chain is no longer a soft objection. It is a disqualification at procurement intake. The first sign you will see this in the wild is updated boilerplate in RFPs from German Länder, French ministries and large EU institutions.
Private-sector buyers face procurement pressure transmitted downstream. A French SaaS selling into a SecNumCloud-required ministry must itself sit in a SecNumCloud-aligned posture or lose the tender. A German fintech under DORA must demonstrate that its critical sub-suppliers (analytics, identity, document signing, observability) meet equivalent operational-resilience controls. This pressure cascades. A DACH SMB that thought it was insulated from sovereignty considerations finds itself answering vendor-due-diligence questionnaires it did not have to answer twelve months ago.
The default-question changes. Until 2025, the default question on a procurement call was "is this tool functionally adequate, with a signed DPA." In 2026 the default question is "is this tool functionally adequate, with a signed DPA, and is the hosting + sub-processor chain defensible against a Schrems II transfer impact assessment." The third clause used to be a specialist concern. It is now in the standard checklist.
A clear-eyed reading also has to name what the package does not change, because hype cycles around announcements like this can mislead buyers into wasted migration projects.
The CLOUD Act remains. A US-incorporated company, even if it stores all data in Frankfurt, remains subject to US extraterritorial subpoena. The package does not (and cannot) change US law. What it does is make CLOUD Act exposure a more visible procurement signal, particularly for regulated buyers. The signal was always there; the package raises its weight.
Schrems II still requires a vendor-specific transfer impact assessment. No certification, including SecNumCloud or BSI C5, blanket-discharges a controller from the Schrems II obligation. The assessment is still per-controller, per-data-flow. The package is expected to reference these frameworks positively, but a reference is not an exemption.
EU-owned does not automatically mean Schrems-safe. Several European vendors run substantial workloads on US hyperscalers, route email through Mailgun or Postmark, or pipe analytics through Segment. Ownership is one independent signal; sub-processor chain is another; physical hosting is a third. They have to be evaluated separately, which is the practice this directory tries to make routine.
Most US software is not going anywhere fast. Replacement velocity for entrenched horizontal tools (Slack, Notion, Salesforce, GitHub) is constrained by switching costs, integration sprawl and team familiarity. The package accelerates the direction of travel; it does not collapse the timeline. Expect category-by-category migration, starting where the buyer has highest leverage (email, document signing, password management, file storage) before moving to deeply entrenched collaboration suites.
For a buyer with limited time, the most useful operational reading is a four-question audit applied to each tool already in the stack.
- Who owns the operating entity? EU-owned, EU-headquartered with US funding, US-owned. This is the ownership signal: the simplest to verify and the one that determines baseline CLOUD Act exposure.
- Where does the data sit at rest, in which region, on whose infrastructure, and who holds the keys? A "European" tool whose primary storage is
us-east-1is not an EU-hosted tool. The data centre matters more than the corporate flag. Under CADA's emerging "sovereign cloud" criteria, even an EU region looks set to be insufficient on its own: encryption-key custody outside the provider's control is becoming part of the test. - Which sub-processors touch the data? Read the public sub-processors document. Flag every US-owned entry. A vendor with two transient US sub-processors and no data-at-rest exposure is in a very different posture from one piping events to Segment and Mixpanel.
- What does the public DPA actually say about international transfers? Standard Contractual Clauses are necessary but no longer sufficient. Supplementary measures, named hosting region, named sub-processors, and an audit-rights clause are what a defensible procurement file now contains.
Run that audit on the top ten tools in the stack. The ones that fail two or more questions are the ones to plan migrations for at the next renewal, not necessarily all at once, but with a calendar attached.
The framing this directory uses, and that the package implicitly endorses, is resilience as a spectrum, not a binary. A SaaS stack is rarely either "sovereign" or "compromised." It is some combination of: EU-owned tools with US sub-processors; US tools with German data residency; open-source self-hosted; SecNumCloud-qualified for the regulated workloads; pragmatic US choices where no credible alternative exists yet.
A buyer's job in 2026 is not to chase a sovereignty maximum. It is to make the trade-offs visible, document them, and move on the highest-leverage replacements first. The Tech Sovereignty Package is the framework that says the trade-offs are legitimate procurement concerns. The work of making them is still on the buyer.
Browse our verified European cloud providers, SecNumCloud-qualified services, encrypted cloud storage, private email, open-source password managers, and EU VPN providers. Each entry is annotated with ownership, hosting, sub-processor chain, CLOUD Act exposure, and the date we last verified the public disclosures. That is the format the next twelve months will reward.
Frequently asked questions
- What is the EU Tech Sovereignty Package?
- A coordinated 2026 set of policy instruments announced by the European Commission on 27 May, anchored by the Cloud and AI Development Act (CADA), the cloud/AI law the Commission is tabling alongside the package, which would harmonise an EU-wide definition of 'sovereign cloud' and ease data-centre build-out, plus the second iteration of the Chips Act and a refreshed open-source strategy, and a proposed restriction on the US hyperscalers for sensitive public-sector data in healthcare, finance and the judiciary. It is best read as the consolidation of moves that began with NIS2 (October 2024) and DORA (January 2025) and the institutional follow-up to the April 2026 €180M sovereign cloud tender that excluded US hyperscalers. It is industrial policy framed as supply-chain resilience, not a ban on US software.
- Do I have to migrate off US-owned SaaS now?
- No. The package does not introduce a general prohibition on US-owned services for private-sector buyers. What it does is propose a binding limit on the US hyperscalers for sensitive public-sector data, a measure that still needs the 27 member states' approval to take effect, add weight to existing Schrems II and CLOUD Act risk assessments, and signal that the procurement direction of travel for regulated buyers is one-way. Private-sector SMBs face no direct legal change in 2026, but their public-sector customers' tenders will increasingly require EU-sovereign sub-suppliers.
- Which of my vendors will be affected first?
- Those selling into public-sector, healthcare, defence-supply-chain, finance and any DORA-scoped financial entity. Cloud infrastructure, email/collaboration suites, identity providers, analytics, and document-signing tools are the first practical pinch points. A useful proxy: any tool that already sits in a DPA chain where the data controller is a regulated EU entity will see questions in the next renewal.
- Is a SecNumCloud-qualified or BSI C5-aligned provider automatically compliant under the new framing?
- Closer, but not automatically. Both qualifications materially reduce extraterritorial-law and security-control risk, and the package is expected to reference them positively. Neither one substitutes for a vendor-specific transfer impact assessment, which still depends on ownership, sub-processor chain and physical hosting location. Treat them as strong shortlisting filters, not as blanket exemptions.
For every product we read the public DPA, sub-processors document, hosting region declaration, and corporate ownership records. Each is timestamped. Signals are editorial, re-verified quarterly. We never accept self-attestation.