Data Sovereignty as a Service Doesn't Exist. Except It Does.

It is not a bad definition. It is just not a useful one.

Data generated within a country's borders is governed by that nation's laws and regulatory frameworks. Clean. Authoritative. Written with the confidence of something that has never had to survive a procurement meeting, a CLOUD Act request, or a federal court deciding that your emails in Dublin are technically reachable from Washington.

The definition describes what data sovereignty should mean.

It does not describe what anyone has actually built.

This is the gap the cloud industry has been quietly living in for twenty years. We got very good at describing sovereignty. We built regions, certifications, compliance frameworks, and architecture diagrams with tasteful national flags on them. We got considerably less good at delivering the thing itself — because delivering the thing itself requires answering questions that are awkward for companies whose business model depends on you not asking them.

Who holds the keys.

Who owns the platform.

Who can be compelled by a government that is not yours.

Who can hand over your data with a nondisclosure order attached so you never find out it happened.

These are not hypothetical questions. The CLOUD Act is real. FISA Section 702 is real. The Microsoft Ireland case ran for four years, went to two courts, and ended with Congress passing a law that made the whole argument moot. The lesson was not subtle: if the company you trust with your data answers to a different legal system than you do, then your data answers to that legal system too.

Geography does not fix this. A Canadian data centre owned by an American company is an American legal exposure with a Canadian postal code. This is not a loophole. It is the architecture. It is working exactly as designed.

So what would actual Data Sovereignty as a Service look like?

Not a region. Not a certificate. Not a promise in a master services agreement that three lawyers negotiated and nobody reads.

It would look like this. Your data fragmented so that no single provider ever holds a meaningful piece. Encryption keys decoupled from storage entirely, so that the entity holding your data is not the entity holding the ability to read it. Distribution across jurisdictions designed so that no single government, no single court order, and no single nondisclosure-attached warrant to a foreign parent company produces a complete picture.

Storage. Encryption. Key control. Separated. Architecturally. Not as a toggle in a settings menu.

That is not a compliance posture. That is actual sovereignty. The kind where the answer to "who controls this" is unambiguously you.

For a long time, that architecture existed as a concept. It existed in whitepapers. It existed in the "future roadmap" section of vendor presentations. It existed in the same place as all the other things the cloud industry agreed were important and did not build because convenience was more profitable.

Then SkyeCONNEX built it.

Data Sovereignty as a Service. Not as a marketing position. As an architecture. The fragmentation, the distributed key management, the multi-cloud design that ensures no single jurisdiction ever holds the complete picture — built, available, and running.

Wikipedia will catch up eventually. It usually does, about a decade after someone has already solved the problem.

In the meantime, the infrastructure decision is yours to make.

The definition exists.

Now, finally, so does the product.

Originally published by Ross Norrie, founder of SkyeConnex, on LinkedIn.

Published March 15, 2026 · More from the SkyeConnex blog