Sovereign by Default
A CEO asks her SaaS for an export of three years of customer history. She gets back a confirmation email: a “data extraction request” has been opened. Estimated delivery, six to eight weeks. The export will be a ZIP of CSVs, but (a polite note adds) the relational joins will not be preserved. Reconstructing the link between customers and their interactions will be “the customer’s responsibility post-export”.
She forwards me the email with one line above the quote: We don’t own this, do we?
We don’t.
What sovereignty actually means
“Digital sovereignty” has, in the last few years, been claimed by everyone who needed a flag. National champions promised it. Cloud providers promised regional availability. Trade ministries promised compliance frameworks named after constellations.
For an SMB, none of that is the point.
For an SMB, sovereignty is a much smaller and much more practical thing. It is the answer to four questions:
- Can I extract my data, in a usable form, today?
- Do I know where it is physically stored?
- If the vendor disappears tomorrow, am I out of business?
- If the vendor doubles the price, do I have an option?
A “yes” to all four is sovereignty. A “no” to any of them is dependency.
That is the whole vocabulary. It does not need a treaty.
Transformation, before sovereignty, is upholstery
The standard pitch reverses the order. Transform first. Modernise the stack. Move to the cloud. Layer AI on top. Then, once everything is digital, consider governance.
This is upholstery on a structure you do not own.
In my fractional-CIO practice, I have rarely been asked to audit sovereignty before being asked to “modernise” the IS. The two requests should be the other way round. You map your dependencies first. You decide what you are willing to depend on. Then (and only then) do you spend money making those dependencies more efficient.
A €50,000 cloud migration onto a platform you cannot leave is not progress. It is a more expensive captivity.
The non-souverainist case
Let me say what this is not.
It is not a call to “buy French”. It is not a call to swap AWS for OVH because of the headquarters address. It is not a moral position on data localisation. The European hosts I use, I use because they offer a cleaner exit, not because their head office is closer to mine.
The sovereignty I am pushing is operational, not political. A self-hosted Postgres on a German VPS owned by Hetzner is more sovereign than a French SaaS that owns your schema and rents you back queries. The flag matters less than the exit clause.
Anyone framing sovereignty as a national project is selling you something. Usually that something is themselves, or a procurement programme, or a tax rebate dressed up as a strategy. Real sovereignty is a property of your stack, not of your supplier’s nationality.
What sovereign by default looks like
The phrase is borrowed, on purpose, from “secure by default” and “private by default”, disciplines we already accept. We do not ship a server with admin as the password and patch it later. We do not put unencrypted customer data on the open web. We do not collect telemetry without consent.
Sovereignty deserves the same default treatment.
Concretely, in an SMB stack, sovereign by default means four things:
Open formats over proprietary ones. Markdown, CSV, JSON, SQLite, plain SQL. Not because they are fashionable. Because they outlive their tools. A Markdown file from 2010 still opens. A proprietary database from 2010 may not.
Owned compute over rented platforms, where it fits. A €9 VPS you control beats a €99 SaaS you do not, for the long tail of small workloads. Not for everything. For the things that look like a script, run them as a script.
Auditable code paths. If a tool processes your data, you should be able to read, in plain English, what it does. Not skim the marketing page. Read the code, the API contract, or the schema. If none of those is available, you do not own the workflow: you rent the right to run it.
Single-vendor risk, named. For each vendor that holds critical data, write down what happens if they vanish. If the answer is “we close”, they hold too much. The fix is not always migration. Sometimes it is a weekly export to a directory you control. But the question has to be asked, in writing, by someone who would have to deal with the answer.
None of this is exotic. None of it requires a sovereign cloud strategy. It requires a Sunday afternoon, a spreadsheet, and the willingness to call the dependency by its name.
The audit, in one morning
I run this exercise alongside the SaaS audit I described in the post just before this one.
For each tool in the stack, three columns: where the data lives, what the export format is, and what the time-to-exit is. The third column is the one most companies have never filled in.
A typical SMB, on a first pass, has between three and six tools where the time-to-exit is “unknown” or “weeks to months”. Each of those is a contingent business. Not a broken business: a contingent one. One whose continued operation depends on a third party staying alive, staying friendly, and staying priced where they were when you signed.
You do not have to fix all six in a quarter. You do have to know they exist.
The right to leave
In the engagements I can talk about, the simplest sovereignty win is also the most boring. It is not changing vendors. It is asking the existing vendor for the export, today, and seeing what comes back.
When the answer is a tidy ZIP delivered in an hour, with a schema that maps to your own, the dependency is reasonable. Keep paying. When the answer is a six-week ticket and a tabular dump that drops the joins, you have learned something. You are not, today, going to migrate. But you are going to behave differently the next time that vendor proposes a new module.
A team that knows it can leave negotiates better. A team that has never tested the exit is, by default, captive.
Before the transformation
There is a sequence here, and I think it matters.
You audit the dependencies. You take stock of what is sovereign and what is not. You decide, line by line, what you are willing to depend on. Then (and only then) you transform what remains.
This order is unfashionable because it does not produce a roadmap with a single vendor name on it. It produces a small list of decisions made by the founder, in a quiet room, with a printed bank statement and a notebook.
It is the order that protects the company.
The corporate vocabulary loves to talk about digital transformation as if it were a one-way upgrade. In my notes, the companies that will still be themselves in ten years are the ones that did the boring step first: the ones who knew, before the upgrade, what they actually owned.
Sovereign by default. Then, transform.
We shape our tools, and thereafter our tools shape us. — John M. Culkin, The Saturday Review, 1967