Soveryne company logoSoveryne
All articles
SovereigntyGovernance

A Pragmatic Sovereignty Playbook for the Next 12 Months

Seven posts of problem. This one is all solution. Here is what a European organization can actually do in the next year to reduce its dependence on foreign technology, without a rip-and-replace, without autarky, and without waiting for Brussels to build the alternatives.

Ilke Tosunoğlu
Ilke TosunoğluJune 25, 20268 min readUpdated July 20, 2026
A 12-month roadmap arc with six milestones (map, tier, fix sensitive, design exit, open standards, skills) under the line "Start on Monday. No rip-and-replace."

Part of the pillar series Sovereignty You Can Actually Operate.

Across this series we've established the shape of the problem: dependence is real and measurable, ordinary tools quietly become critical, compliance isn't sovereignty, and the honest goal is selective autonomy, not isolation. The recurring risk underneath all of it is simple: Europe has been regulating its dependencies faster than it builds substitutes for them, and an organization that waits for that gap to close will wait a long time.

You don't have to. Here is the playbook: six steps, sequenced, each anchored to something concrete you can point at. None of it requires ripping out what works.

Step 1: Map your dependencies and concentration

You cannot manage a single point of failure you can't see. Start by building the inventory: which providers underpin which functions, which of them are "not easily substitutable," and where several critical services quietly trace back to the same parent. This isn't just good practice. Under DORA it's a baseline obligation, complete with a register of ICT third parties and a concentration-risk assessment (DORA Art. 29). Most organizations discover their real exposure is more concentrated than the org chart suggests.

Step 2: Tier your workloads by how sovereign they need to be

The six-step sovereignty playbook as a numbered checklist (map dependencies, tier workloads, fix sensitive workloads first, design exit paths, prefer open standards, build skills) beside the SEAL 0–4 maturity ladder. Footer: control where it matters, buy European where you can, test what you claim.

Not everything needs the same treatment, and pretending it does is how sovereignty projects stall. Sort your estate by the honest question: if a foreign party could access, disrupt, or cut this off, what happens? The EU's own Cloud Sovereignty Framework gives you a ready-made ladder for this, Sovereignty Effectiveness Assurance Levels (SEAL) 0 to 4, and you can set a minimum level per data class rather than boiling the ocean. The rows below show the levels that matter for procurement decisions; SEAL-1 (contractual EU-law protections without enforceability) sits below the practical floor and is omitted here.

SEAL level In plain terms
0 Controlled by non-EU parties under non-EU law
2 EU law applies and is enforceable; no extra customer measures needed
3 Immune from non-EU supply-chain disruption
4 Full EU stack, "chips to software"; no provider has reached it

Source: European Commission Cloud Sovereignty Framework. The Commission itself did exactly this in its April 2026 sovereign-cloud tender: it set SEAL-2 as the floor, reserved higher levels for sensitive workloads, and split the award across four providers to avoid lock-in (EC). That's the template: tiering, not a wall.

Step 3: Fix the sensitive tiers first

Now spend your scarce sovereignty budget where it counts: move the Tier-1 and Tier-2 workloads (the crown jewels) onto genuinely sovereign infrastructure, and do it with customer-held keys, because data residency alone doesn't answer the compulsion question. Leave the general-purpose Tier-3 estate where it is for now, kept portable. This is the single highest-return move in the playbook, and it's finite and achievable in a year.

Step 4: Design for exit

Sovereignty you can't walk away from isn't sovereignty. Build the exit before you need it: open formats, machine-readable export, tested failover, and reversibility clauses in every contract. Two hard deadlines make this urgent and cheaper: DORA Art. 28(8) requires documented, tested exit strategies for critical functions, and from 12 January 2027 the EU Data Act bans all switching and egress charges (Data Act Art. 29). Prepare now and you walk through that door the day it opens.

Step 5: Prefer open standards and open source where the function is mature

For identity, collaboration, document formats, and middleware, the deep points of administrative lock-in, favour open standards and open-source options where they're genuinely ready. Public administrations across Europe are proving it works: Schleswig-Holstein has moved almost 80% of its state-administration workstations (excluding tax administration) to open-source office software (Land Schleswig-Holstein, December 2025), and the trend is toward "public money, public code." It reduces long-run lock-in and builds demand for European and open ecosystems. (We go deep on this in the companion technical post.)

Step 6: Treat skills as critical infrastructure

None of the above sticks without people to run it. Europe is short roughly 300,000 cybersecurity professionals (ISC2, 2024), and sovereignty specifically depends on having teams that can operate, audit, and switch the systems you've chosen. Budget for it, use conversion pathways from adjacent IT roles, and treat vendor knowledge-transfer as a hard requirement, not a nicety.

Procurement is your fastest lever

If you take one thing from this playbook, take this: procurement moves faster than anything else you control. You don't have to build a European cloud; you have to buy in a way that builds one. Sovereignty criteria in tenders, multi-sourcing to avoid lock-in, exit clauses tied to ownership changes, and open-source-first defaults are already reshaping the market, from the EU institutions' €180M tender to national frameworks in the Netherlands, Denmark, France, and Germany. Anchor demand is the lever that turns "we wish Europe had alternatives" into "Europe has alternatives."

What not to do

Three failure modes to avoid, because they waste the budget and the goodwill:

  • Autarky. Building everything yourself is neither realistic nor desirable. Adopt the world's best where it's safe to; reserve sovereignty for what matters.
  • Sovereignty theatre. A "sovereign" badge without customer-held keys, tested exit, and real EU operational control is what critics rightly call "sovereignty washing": a label that's proven "empty in substance" (Lawfare, 2025).
  • Rip-and-replace. Big-bang migrations fail. Tier, sequence, and move the sensitive workloads first.

Where Soveryne fits

This playbook is, more or less, the company we built. Command does Steps 1, 4, and 6 as a product, mapping dependencies and controls, keeping tested exit and continuity evidenced, across NIS2, DORA, and ISO 27001. The Soveryne Cloud Foundation is where you put the Step-3 sensitive workloads: EU-hosted, operated by an EU entity, keys in EU jurisdiction, EU-sovereign AI inference, open-source core, no US-jurisdiction subprocessor in the data path. And Counsel gives you grounded, cited answers on that same sovereign ground. It's selective autonomy, delivered: pragmatic, evidenced, and startable now.

If you want a place to begin, get in touch. We'll help you tier your workloads and, true to the brand, if we're not the right fit for a given tier, we'll say so.

FAQ

How do I start reducing dependence on US tech without disrupting the business? Map dependencies, tier workloads by sovereignty need, and move only the sensitive tiers first onto sovereign infrastructure with your own keys. Keep the rest portable. It's sequencing, not a rip-and-replace.

What is the SEAL framework? The EU Cloud Sovereignty Framework's Sovereignty Effectiveness Assurance Levels (0–4), a way to score how sovereign a cloud service actually is. It's the best off-the-shelf yardstick for setting a minimum standard per data class.

What's the fastest lever to build European alternatives? Procurement. Sovereignty criteria in tenders, multi-sourcing, exit clauses, and open-source-first defaults create the anchor demand that builds supply, faster than waiting for regulation or new entrants.

What should I avoid? Autarky, sovereignty theatre (a badge without keys or a tested exit), and big-bang migrations. All three waste effort and undermine trust.

You can start this on Monday. Map, tier, fix the crown jewels, design the exit, and buy in a way that builds the alternative. To put the sensitive tiers on sovereign ground, explore the Soveryne Cloud Foundation; to operate the whole program, see Command or get in touch.

Sources

A layered reference-architecture shield inside an EU boundary, listing the seven pillars in order (jurisdiction/ownership, region-locked data, key custody, regional inference, cell isolation, tamper-evident audit, enforcement + test) with side notes on sovereign-by-design, privacy-by-default, resilience, and auditability.
Companion piece
A Reference Architecture for Sovereign-by-Default Platforms

Eight posts in, from the dependence map to the region lock, here's the synthesis: the minimum architecture that honestly earns the word "sovereign." Not a product pitch: a blueprint you can hold your own stack against.

Read the companion piece

More articles

A map of Europe's dependence on US technology: cloud, software, AI and chips, alongside the leverage points Europe still holds in lithography and telecom.
SovereigntyCloud

Europe's Digital Dependence, Explained

This is the stakes, in one place. How deep does Europe's reliance on US technology run, why does concentration turn ordinary tools into systemic risk, and why is passing an audit not the same as being sovereign? This cornerstone ties the argument together and links to the detail behind each claim.

July 20, 20264 min read
A dial set between "open / dependent" and "sovereign / isolated", marked at a pragmatic middle labelled selective autonomy: control where it matters, open everywhere else.
SovereigntyGovernance

Sovereignty You Can Actually Operate

This is the method. Once you accept that dependence is real and compliance alone won't fix it, the question becomes operational: what do you actually control, how do you prove it, and how do you leave if you have to? This cornerstone turns the point of view into a how-to and links to the article behind each move.

July 20, 20264 min read
A prompt and its retrieved context flowing into a model, splitting one path to a foreign GPU outside the jurisdiction, the other to in-region EU inference that keeps the data home.
AISovereignty

Sovereign AI, Explained

This is our whitespace. Cloud dependence is a known story; AI is repeating it one layer up, faster and deeper. This cornerstone explains why "sovereign AI" is a real category and not a marketing label, and links to the article behind each claim.

July 20, 20263 min read