Data Residency Was the Easy Part: What Europe's Sovereignty Rules Now Demand From Your Engineering Team

The Two Words That Reorganised European Procurement

In sworn testimony to a French Senate inquiry on digital sovereignty, Anton Carniaux, Microsoft France's director of public and legal affairs, was asked a direct question: could he guarantee that French citizens' data would never be handed to US authorities without explicit French authorisation? His answer was two words: no, he could not.

He added the reasonable caveats — Microsoft resists requests it considers unfounded, and the situation had not in fact arisen. But the legal point stood and could not be argued away. Under the US CLOUD Act, US-headquartered providers can be compelled to produce data in their possession, custody, or control regardless of where that data physically sits. A datacentre in Frankfurt does not change the corporate structure that owns it.

European buyers had been circling this argument for years without a clean way to raise it in a procurement meeting. Sworn testimony from the vendor's own executive gave them one. Combine it with cumulative GDPR enforcement passing €7.1 billion by January 2026, and with Austrian, French, and Italian supervisory authorities ruling against US-based tools over transatlantic transfer mechanics, and the debate stopped being about whether sovereignty mattered and became about how much of it you could actually buy.

What follows from that shift is what engineering leaders keep underestimating. Sovereignty sounds like a contract clause. It is almost entirely an architecture problem — and the legal instruments now arriving in force are specific enough that you cannot satisfy them by moving a workload to a differently branded region.

The Money Moved Before the Law Did

Budget reallocation is usually the most honest signal of where an industry is going, and the numbers here are not subtle. Gartner forecasts worldwide sovereign cloud IaaS spending at $80 billion in 2026, up 35.6% year over year. Europe is the sharpest curve in that figure: an 83% increase, from $6.9 billion in 2025 to $12.6 billion in 2026, with Europe forecast to overtake North America on sovereign cloud spend in 2027.

The intent data points the same way. Sixty-one percent of Western European CIOs say they want to increase their use of local cloud providers. European infrastructure providers — OVHcloud, Hetzner, IONOS, Scaleway — are all reporting the kind of growth that follows a structural shift rather than a marketing cycle.

It is worth being clear-eyed about the base, though, because the sovereignty discourse tends toward triumphalism. AWS, Microsoft Azure, and Google Cloud still hold somewhere between two thirds and 72% of the EU cloud market. European providers account for roughly 13-15%. No large European enterprise is exiting the hyperscalers in 2026, and anyone selling that story is selling something.

The realistic picture is bifurcation: a sovereign tier for regulated, public-sector, and strategically sensitive workloads, and a conventional tier for everything else. That is a harder engineering problem than wholesale migration, because it means running two operating models simultaneously and knowing, at design time, which workload belongs in which. Most organizations have no mechanism for making that call and no inventory that would support it.

CADA Turns a Preference Into a Tiered Legal Obligation

On 3 June 2026 the European Commission unveiled its Tech Sovereignty Package, and with it the Cloud and AI Development Act. CADA is the instrument that converts sovereignty from a purchasing philosophy into something with tiers, thresholds, and dates.

Its centrepiece is a four-level cloud sovereignty framework classifying providers by progressively stricter requirements across infrastructure location, ownership, operational control, and personnel. Level 1 is the baseline every provider serving the public sector must meet. Level 2 requires demonstrated independence from third-country jurisdiction and transparency over the software supply chain. Level 3 requires EU ownership and control, plus additional criteria that extend to the citizenship of personnel operating the service. The framework runs to a fourth level for the most sensitive workloads.

The timeline matters more than the tiers, because it is the thing that determines whether this is a 2026 problem or a 2028 one. CADA formally takes effect on 4 August 2026. The first tier of sovereignty requirements applies from February 2028, with the highest tier mandatory by August 2029. Read casually, that sounds like breathing room. Read as an engineering leader, it is roughly eighteen months of design and migration work before the first binding date, for organizations that have not yet classified their workloads.

CADA also carries an industrial policy payload that will shape capacity and pricing: the EU's stated objective is to triple European datacentre capacity within five to seven years, with public procurement deliberately used as the demand lever. If you are planning sovereign capacity for 2028, you are planning against a supply curve that is being built at the same time.

Your Vendor Now Has a Sovereignty Score

Running alongside CADA is the Commission's Cloud Sovereignty Framework, which does something procurement teams have wanted for a decade: it makes sovereignty a measurable quantity rather than a marketing adjective.

The framework organises 48 specific criteria into eight sovereignty objectives — strategic, legal and jurisdictional, data and AI, operational, supply chain, technological, security and compliance, and environmental sustainability. From those it derives an overall sovereignty score and a Sovereignty Effectiveness Assurance Level, or SEAL, running from SEAL-1 through SEAL-4, where the upper bands correspond to data sovereignty, technological autonomy, and full sovereignty respectively.

This is not theoretical. The Commission ran a €180 million tender to select up to four providers over six years, each required to meet minimum levels across all eight objectives. The winners — Luxembourg's Post Telecom with OVHcloud and Clever Cloud, Germany's StackIT, France's Scaleway, and a Belgian-French-Luxembourgish consortium led by Proximus with S3NS, Clarence, and Mistral — are now the reference implementations of what a scored sovereign provider looks like.

For engineering leaders the practical consequence is that 'sovereign' has stopped being a claim you either accept or don't. It is a number, derived from published criteria, and it will start appearing in RFPs. The awkward corollary is that a provider's SEAL level tells you nothing about your own architecture. You can procure a SEAL-3 platform and deploy onto it a system that federates identity through a US tenant, ships telemetry to a US-operated SaaS, and holds encryption keys in the provider's own KMS. The score belongs to the vendor. The exposure remains yours.

What Sovereignty Actually Costs in Engineering Hours

The single most useful thing to understand about sovereign infrastructure is that a sovereign cloud is not a region. It is a partition, and partitions break assumptions that your platform code has quietly depended on for years.

The AWS European Sovereign Cloud went generally available in January 2026 with its first region in Brandenburg, backed by a €7.8 billion long-term investment and expanding through sovereign Local Zones in Belgium, the Netherlands, and Portugal. Structurally it is isolated from global AWS: a separate legal entity under German law, EU-resident-only operations, and independent IAM, billing, DNS, and certificate authority. Every one of those independent components is a place where your existing automation stops working. Cross-account roles do not span the partition. Your organisation-level guardrails do not apply. Your CI/CD pipeline's credentials, your service catalogue, your DNS delegation, your certificate issuance, and your consolidated billing all need a second implementation rather than a second parameter.

The managed services gap compounds it. Sovereign partitions launch with reduced catalogues — the AWS European Sovereign Cloud's launch catalogue did not include managed confidential computing as a top-line service, and sovereign providers like StackIT fill equivalent gaps with different primitives such as confidential Kubernetes. Every proprietary managed service you have to replace with a self-operated equivalent is a permanent addition to your platform team's run cost, not a one-off migration ticket.

Key custody is where the architecture question gets genuinely interesting. Bring-your-own-key, where the provider still holds and operates the key material, offers considerably weaker guarantees than hold-your-own-key with an external key manager. Under external custody your encrypted data is inert without your key, and revocation crypto-shreds it everywhere at once — which is precisely the property that makes an extraterritorial disclosure order less consequential. It also introduces a new class of operational failure that your team now owns entirely, including the scenario where you lock yourself out of your own production data.

The aggregate cost is real and should be stated plainly rather than discovered later. Analysts expect roughly 60% of multinational firms to split AI stacks across sovereign zones by 2028, with integration costs tripling as a result. Meanwhile European buyers surveyed at VivaTech 2026 put their willingness to pay a sovereignty premium at 5-10%. Those two numbers do not reconcile, and the gap between them is the budget pressure that will land on engineering teams as a mandate to absorb sovereignty without additional headcount.

The Data Act Gave You an Exit. Your Architecture May Not Be Able to Use It.

Sovereignty and portability are the same problem viewed from different angles, and the EU Data Act is the instrument that addresses the second one. Applicable since September 2025, it grants cloud customers a set of switching rights that are unusually concrete for European digital regulation.

The commercial provision is the one that gets the headlines: switching charges, including data egress fees, may only recover a provider's actual direct costs until 12 January 2027, after which they are prohibited outright for all data processing services. Egress pricing has been the quiet tax that made multi-cloud strategies uneconomic for a decade. In under six months, it stops being a lawful lever.

The technical provisions matter more and get discussed less. Providers must support switching within a 30-day transition window, extendable up to seven months only where genuinely technically unfeasible, and the target of that switch is functional equivalence — not a raw data dump. In-scope contracts must carry specific switching provisions, and key information must be disclosed before signature.

Here is the uncomfortable inversion. The Data Act removes the legal and commercial barriers to leaving a provider, which means that from January 2027 the only thing keeping you in place is your own architecture. If your application logic is welded to a proprietary managed queue, a vendor-specific serverless runtime, and an identity model with no portable equivalent, you will hold a statutory right to switch in 30 days and a codebase that needs eighteen months. The regulation has, in effect, converted vendor lock-in from a commercial condition into an engineering debt that is now entirely self-inflicted.

The work this implies is unglamorous and should start now: a portability audit that identifies which proprietary couplings are genuinely load-bearing, which exist because they were the default, and what functional equivalence would actually require for each. This is exactly the kind of multi-quarter, low-visibility engineering programme that loses every prioritisation argument against feature work — and exactly the kind that a dedicated team with stable ownership can carry to completion while the product roadmap continues.

Sovereignty Includes People, Not Just Servers

The detail in CADA that most engineering organizations have not yet processed is that its upper tiers reach personnel. Level 3 does not merely require that infrastructure be owned and controlled from the EU; it extends to criteria covering who operates the service, including citizenship. Sovereignty, in the framework's own logic, is about jurisdiction over people as much as jurisdiction over data.

That reframes a set of questions most outsourcing arrangements cannot answer. Which individuals hold production access to your systems? In which jurisdictions do they reside? Which entity actually employs them, and is that entity the one on your contract or a subcontractor two layers down? If a foreign authority served a disclosure order on any organisation in that chain, would you be told? For project-based outsourcing and large body-shop engagements, these questions frequently have no determinable answer, because work is distributed across engineers the client never meets, employed by companies the client never contracted with.

This is where delivery model becomes a compliance control rather than a commercial preference. StepTo's engagements are built on named senior engineers working as a persistent extension of the client's team, under a single contracting entity, with no subcontracting layers between the client and the people touching the code. Access is held by identified individuals in a known jurisdiction. That does not make a sovereignty assessment pass by itself; it makes the assessment possible to conduct at all, which is the actual prerequisite.

On jurisdiction, the honest position is more useful than the marketing one. Serbia is not an EU member state and is not covered by an EU adequacy decision, so transfers of personal data rely on standard contractual clauses. What Serbia does have is a Personal Data Protection Act closely modelled on the GDPR and in force since 2019, ratification of Convention 108+ in May 2020, and an explicit national Data Protection Strategy whose stated goal is securing a Commission adequacy decision. It is also outside the reach of the US CLOUD Act, which is the specific extraterritorial exposure that started this entire conversation.

Applied honestly, that produces a clear line. If you are building a SEAL-4 or CADA Level 3 workload for a European public authority, you will need EU-citizen personnel and an EU-owned operator, and any partner worth engaging will tell you that outright rather than obscuring it. For the very large majority of enterprise workloads that sit below that line — private-sector systems where the requirement is EU data residency, GDPR-grade contracting, auditable access, and no US extraterritorial exposure — a nearshore team in Serbia clears the bar, at a cost structure and timezone overlap that a Western European sovereign-cloud consultancy will not match.

What to Actually Do in the Next Two Quarters

The organizations that will handle this well are not the ones with the strongest opinions about digital sovereignty. They are the ones that started classifying workloads while the deadlines were still comfortably distant.

Start with a sovereignty tiering of your estate, because everything downstream depends on it. For each system, record what data it processes, which regulatory regimes attach to that data, whether it serves public-sector or critical-sector customers, and what the consequence of an extraterritorial disclosure order would actually be. Most estates split roughly into a small set of genuinely sovereignty-bound systems and a long tail where the honest answer is that standard EU residency is sufficient. Making that split explicit prevents the two most expensive failure modes: over-engineering everything to the highest tier, and discovering in 2028 that a system you classified as routine serves a regulated customer.

Then run the portability audit the Data Act has effectively scheduled for you. Inventory proprietary couplings, distinguish load-bearing from incidental, and estimate what functional equivalence would cost for each. Do this before January 2027 rather than after, because the value of the egress-fee prohibition is entirely determined by whether your architecture can exercise it.

In parallel, fix the things that are cheap now and expensive later: move to external key custody for data where extraterritorial exposure is a genuine concern, get identity federation off single-jurisdiction dependencies, ensure your observability and telemetry pipelines do not silently export regulated data to a non-EU SaaS, and put access records for production systems into a form you could hand to an auditor without a two-week reconstruction exercise.

Finally, resource it as a programme rather than a series of tickets. This is long, invisible, precision-demanding work with no feature at the end of it, which is exactly the profile of work that in-house teams consistently fail to complete under roadmap pressure. A dedicated nearshore team that owns the sovereignty and portability workstream end to end, in overlapping hours, with the seniority to make architectural calls without escalating each one, is a structurally better fit than trying to squeeze it into the sprints of a team that also owns the product.