Okay, I had a conversation this week that motivated me to write this post after a long break.
But I think the topic is worth describing, and it’s a good argument to maybe try to get back to regular writing.
I was speaking to someone whose job is to connect companies - usually 20 to 200 people with public sector organizations and tenders in the Nordics. A person whose job is to live between procurement and the company and whose business is to make their customers get paid in those tenders.
I expected our talk about digital sovereignty to focus on end customers, then public organizations and their need for cloud migrations, regulations, etc.
But it was different; he told me something that, after a long time of writing and talking about it, shocked me at first: the main beneficiaries of such a service will not be public organizations but local vendors selling into the European public sector. Because they need to change first to be an option for those publics.
Then the post today will be divided into a couple of sections around this topic:
The observation of what the market looks like from an IT perspective
Why the problem is never a new risk and why Europe just gave an old problem a passport
The window where this is the differentiator for those vendors and how long it stays one
What “proof” actually means, because claiming and proving are different sports
What to do this quarter, if you sell to the public sector and would rather not learn this the hard way
His Observation
What he also said is something like: buyers no longer ask whether your data stays in Europe — they ask you to prove it.
They don’t care whether you plan it or your provider says so; you need your own proof. A document with an architecture, a contract, and a legal evaluation, with a sovereignty score and risk backlog, written in a form that a non-technical person can understand.
The second thing he said, which I think opened my business wider and stuck with me, was that most of the clients cannot have this today, and the vendors that will have it will be shown in a better light. Being sovereign will move them up in the ranking. So it is a differentiator right now.
And as I have been writing about digital sovereignty for a while, starting a year ago, I have been saying that it’s not a buzzword but a new perspective on the vendor management game. But I see now that I’ve always looked at it from a buyer perspective. The other perspective may be an even more important part of that coin, because without sovereign vendors, making sovereign choices is more than problematic.
Why was this never a new risk
As I write in my posts and say in my digital sovereignty presentations, we used to say geopolitics created a new surface called digital sovereignty, so we need new frameworks, new labels, new “sovereign clouds,” and solutions.
I never agreed. When I speak to Americans today, they say, “We have the same problem with different naming: vendor lock-in.”
And that’s true; every CIO/CTO on the planet always has some kind of risk register that says “dependency on a single software provider”. But it was scored too low, accepted, and never analyzed or revisited. What happened in the last two years isn’t a new risk; it is a change in the probability of this risk materializing. So everybody in IT controls should take it and reassess.
And they need to do it quickly, as more and more industries make it a requirement with a deadline.
Two small examples from that same conversation.
A Danish company built on open source, proudly for their vendor-agnostic architecture based on Kubernetes. Great, they did everything right; they can feel they can leave any time! Not.
They have five petabytes of data sitting with one provider. Moving it would cost roughly half a million euros in transfer costs alone — before anyone thinks about changing anything in the technology stack. Open source didn’t save them. Data volume did what it always does, and nobody put it in the risk register because “we are on open source” sounds like enough of a solution.
Another example just from the trenches. Say you’re a vendor building an AI-assisted case-handling tool for a municipality on Azure OpenAI, deployed in Sweden Central. “Data stays in Europe” — true, and it’s in your risk register as a green flag. Now think about what a public sector caseworker actually types into that tool: firearms license applications, death certificates, child welfare notes, medical records, and many others. Exactly the kind of content an automated abuse classifier is built to flag, because it cannot differentiate a coroner from a terrorist from a book author.
Here’s what happens next, reading straight from the documentation. Flagged prompts and completions may be stored in an abuse-monitoring log for up to 30 days. When the automated review isn’t confident enough, authorized Microsoft employees review edge cases. In Europe, those people sit in Europe, at secure workstations, with approvals and proper training. That’s totally Fine. But they are still people outside your organization and outside the municipality reading a citizen’s record—and neither you nor the municipality is told which records will land there. Switching this off is possible, but it’s not a portal setting vendors or customers can switch in the UI: it’s an application under Microsoft’s Limited Access program for customers who meet additional eligibility criteria. Most mid-sized vendors have never heard of the form, let alone filled it out.
Back to the solution itself: even though this setup is limited to paid mode, Global Standard doesn’t guarantee processing in Europe; the only rule is that data at rest stays in Europe, but processing can still happen between those states. So you have to choose EU processing explicitly and pay for it.
That information isn’t hidden; it’s in long documentation and regulatory descriptions, and Microsoft is technically very transparent here. So we come back to risk management because it’s the buyer’s role to check whether the service fits their requirements. Therefore, your organization should understand who can see this example citizen’s data and decide what can be done with it.
That was a real gap between knowing that the digital sovereignty problem exists and being able to control it with proof, score, and the right process.
Neither of those is a geopolitical problem. Both are the same old lock-in problem — we just started asking about it in tenders with different wording.
The window
Here’s the part that I think matters most, and that people understand totally differently, of course from vendor perspective.
Presently, for local vendors being able to show what dependencies they have, which are critical and putting some plan and estimated cost of exit is some kind of ranking advantage. Because maybe couple of companies do this. And because evaluators just started to ask about it. Then whoever will show up with the evidence will look up like adult and get more points in total sheet. Of course it doesn’t mean they will always win, but the differentiator is clear and serious so lot of organizations will value this.
But and this is critical, this dirrerentiators have an expiration date, and it’s visible slowly. EU regulations will tighten procurement rules by regulations. Data handling will move from nice to have to mandatory. Defense and its supply chain companies are already there, and who is in supply chain is even just here much wider than you can think. Because if you sell headphones or factory monitoring devices, if they’re sold for production of military equipement it starts being military supply chain. And as IoT keeps being included in more and more “things” data sensitivity will become problem even of what you wear going to work. Of course you can imagine that public sector will follow and with them even more companies.
I can imagine that in three to four years from benefit it will come to requirement and entry ticket. So the work to have this will be the same. But upside will be gone.
So the question in the end is not if we will have to do this. It is we want to go with it early as investment and early benefit or when it will be obligatory.
To be honest I think this is same as with a lot of competitive edge solutions, all the DevOps, containers, etc. When you start early it’s your differentiator, if you start late it’s only additional requirement.
Therefore, Sovereignty is on the same trajectory, and we are somewhere in the early part of it. The part where the return is possible is now.
What “proof” actually means
Let me be concrete, because "be sovereignty-ready" is exactly the kind of advice that sounds good and helps nobody, It’s too wide topic.
Proof, in a tender context, isn’t a certificate or a sentence in a document. It’s the ability to answer, in writing, with references:
Where does every piece of the service actually run? Not “in the EU region” — which service, which sub-processor, which contractual layer. Including the AI parts, because “where inference runs” is becoming a standard question, and it is often the one place the answer is not what you assumed.
Which of those dependencies would stop the service if they changed their terms tomorrow? Most won’t. A few would. You need to know which few, and you need to have decided what you’d do about each of them if this happen.
What does the exit cost, in money and in time? Not a plan to migrate everything — nobody believes that, and nobody funds it. A number, per critical dependency, that says “if we had to, this is what it takes”. That number is what turns sovereignty from ideology into risk management, and it’s what an evaluator can actually score.
Who owns this answer? In most companies, the truthful reply is “the risk register, in a section nobody has opened since 2022”. That is not an owner. If it isn’t somebody’s job to keep the answer current, it’s stale by the time the tender lands.
None of this requires leaving Microsoft or AWS. I say that in every conversation, and I’ll say it here: sovereignty does not mean abandoning the hyperscalers. It means knowing what would stop the business if one of them were lost, and being able to show that you know. The all-or-nothing framing is the main reason companies do nothing — the task looks impossible, so it goes back in the drawer, next to the risk register nobody reads. I wrote about that drawer before; it’s getting crowded.
What to do this quarter
If you sell into the public sector in Europe and you're somewhere between "we're on a hyperscaler and we've read the residency page" and "we could hand an evaluator a dependency map tomorrow", here's what I would do before the next tender asks.
First, map value streams, not systems. Start from what the customer actually buys from you and work backwards to the technology that makes it possible. This alone cuts the problem down to the 15–20% of your stack that genuinely matters. The rest can stay exactly where it is.
Second, for that critical slice, read the legal print — the service-specific terms, not the marketing page. Write down what you find. Most of the surprises are in there, and it is far better to find them yourself than to have an evaluator find them for you.
Third, put a cost on exit for each critical dependency. Rough is fine. A number that’s 30% wrong is infinitely more useful in a tender than a paragraph that says “we are committed to portability”.
Fourth, give it an owner and a review date. A tender is not the moment to discover that the map is a year old.
And then — this is the part vendors underestimate — write it up in language a non-technical evaluator can score. The whole point is that this goes into a bid. If it lives only in an architecture diagram, it doesn’t exist for procurement.
That’s a few weeks of work for a mid-sized company, not a year. And it’s a few weeks that, right now, get you scored above competitors who haven’t done it. In a few years it will be a few weeks that get you past the door, alongside everyone else.
I know which side of that line I’d rather be on.
Have you seen sovereignty or data-handling requirements show up in tenders you’ve bid on?
Were they scored, or just checked? And honestly — could your company prove its answer today, or would it be a two-week scramble? I’d like to hear how this looks from your side of the table.
Self-Promotion Part
This is the exact problem my Digital Sovereignty Risk Review is built for — a structured two-week look at your dependencies, the critical ones, and what an exit would cost, written up so it can go straight into a bid. If you sell to the public sector and want to turn this into a ranking advantage before it becomes a checkbox, get in touch.