Digital Sovereignty: It's Not Where Your Cloud Runs. It's Who Can Read Your Code.

December 2020. Eighteen thousand organizations discovered their infrastructure had been compromised for nine months. Among them: the US Treasury, the State Department, dozens of Fortune 500 companies. None of them were storing data in Russia. Their servers were on-premise, in national datacenters, or on certified clouds. Everything was, on paper, "sovereign."

The attack vector? A software update. A DLL file in a network monitoring tool called SolarWinds Orion. Code.

The infrastructure was in order. The code was not.

The debate we had, and the one we should be having

For a decade, the conversation about digital sovereignty has circled around a single question: where are your servers? Billions have been invested in certified datacenters, SecNumCloud-labeled hosting, ANSSI-audited infrastructure. That's useful. It's necessary.

It's not enough.

A certified datacenter running software whose source code you don't have access to doesn't belong to you. It belongs to the vendor who can push an update tonight. Change their terms of service next year. Decide to exit the European market and leave you without continuity.

The sovereign cloud paradox: you pay to keep your data in France while depending on a software stack you don't control.

The real question isn't geographic. It's: if the vendor behind your critical system disappears tomorrow, what happens?

The black box that's been running for fifteen years

Most critical systems in an organization aren't recent applications on a modern cloud. They're software built fifteen years ago, sometimes twenty, where the original teams have left and the documentation belongs to another era.

These systems run. They're often reliable. But no one in the organization can answer three simple questions:

What does this code actually do, module by module?
Who can modify it if a regulatory incident or security flaw surfaces?
What happens if the contractor or vendor who holds the keys stops existing?

A system you don't understand is a dependency. Regardless of where it runs.

We call this the sovereignty debt: the gap between infrastructure you formally control and code you genuinely understand. That gap is, in the majority of organizations we work with, far larger than it appears.

What NIS2 and DORA actually require

The NIS2 directive, transposed into French and European law, requires essential and important entities to demonstrate audit capabilities, traceability, and risk management for their information systems. It's not a localization requirement. It's a control requirement.

Practically: if your critical infrastructure runs on software that no one in your organization can independently read and verify, you'll struggle in a NIS2 audit. Not because of geography. Because of control.

DORA, for the financial sector, is even more direct: it requires provable operational resilience, regular penetration tests, and the ability to restore critical functions after a major incident. All of this assumes you understand your systems, not just where they run.

The regulator isn't asking where your cloud is. They're asking whether you can guarantee the continuity, traceability, and security of your systems. These are technical questions, not geographic ones.

Open source as a sovereignty tool, not an ideology

Open source is often framed as an ideological or economic choice. It's primarily an instrument of operational sovereignty.

Open-source software can be audited independently. It can be forked if the maintaining organization changes direction or disappears. It can be adapted to specific regulatory constraints without depending on a private vendor's roadmap. And it can be subjected to a full security audit: not a surface review, a code audit.

This is why GnuCOBOL, the open-source COBOL compiler we develop, became the choice of the French tax authority (Direction Générale des Finances Publiques) for systems handling 40.7 million taxpayers. Not because it was cheaper than IBM COBOL. Because the French state could read the code, verify its behavior, and guarantee continuity without depending on an American vendor whose commercial decisions are beyond its control.

That's not a political choice. It's a governance choice.

Three questions to ask about every critical system

Real digital sovereignty comes down to three concrete criteria, applicable to any system in your organization:

Is the source code accessible and readable? Not "do we have the files somewhere": can an independent technical team audit it today, in a reasonable timeframe?

Can you modify this system without depending on the vendor? If a security incident surfaces, a new regulatory requirement lands, or your context shifts, do you have the ability to react, or do you have to wait for the vendor's update cycle?

What happens if the vendor changes its terms or disappears? This is the question no one asks until the problem has already occurred. And when it occurs, it's too late to plan.

If you can't answer these three questions clearly for your most critical systems, you have a sovereignty problem, regardless of your servers' postal address.

What sovereignty actually costs

There's a standard objection to all this: real sovereignty costs more. It means investing in understanding existing systems, adopting auditable solutions, building teams capable of maintaining that understanding over time.

That's true. But the calculation should include the other side of the balance sheet: the cost of a dependency that materializes. The cost of a vendor that doubles its pricing because you have no alternative. The cost of a security incident on a system no one truly understands. The cost of a NIS2 or DORA audit you can't pass because your provider won't give you code access.

SolarWinds cost its victims hundreds of millions of dollars, and their infrastructure was, on paper, perfectly in order.

The real digital sovereignty debate isn't geographic. It's technical. And it starts with a question few organizations have seriously asked: who actually understands the code running your critical systems?

If you're not certain of the answer, that's where to begin.