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, on certified clouds. Everything was, on paper, sovereign.
The attack vector? A software update. A DLL file inside a network monitoring tool called SolarWinds Orion. Code.
The infrastructure was in order. The code was not.
The wrong debate
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. Necessary, even.
But 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. You pay to keep your data in France while depending on a software stack you have no real control over.
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, by teams who have long since left, with documentation from another era.
These systems run. They're often reliable, precisely because nobody touches them. But when nobody touches them, it's rarely out of caution. It's because nobody really knows what would happen if they did.
Ask your team three questions about each of these systems: what does this code actually do, who can modify it if a security flaw or regulatory requirement surfaces, and what happens if the contractor who holds the keys shuts down? If the answers are vague, you have a dependency. Regardless of where the servers run.
The gap between what you formally control and what you genuinely understand is what we call sovereignty debt. In most organizations we work with, that gap is far wider than it appears.
What NIS2 and DORA actually require
The NIS2 directive requires essential entities to demonstrate audit capabilities, traceability, and risk management across their information systems. It's not a localization requirement. It's a control requirement.
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, goes further: provable operational resilience, regular penetration tests, the ability to restore critical functions after a major incident. All of that 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 what you operate. That's a technical question.
Open source isn't an ideology
Open source is often framed as a political position or a way to cut costs. It's primarily an instrument of operational sovereignty.
Open-source software can be audited by an independent team. It can keep running if the organization maintaining it disappears or changes direction. It can be adapted to specific regulatory constraints without waiting for an editor to decide to do it. And it can be subjected to a real security audit, not a surface review.
That's why GnuCOBOL, the open-source COBOL compiler we develop, became the choice of the French tax authority 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 entirely beyond its control.
That's not a political choice. It's a governance choice.
The cost of dependency
There's a predictable objection: real sovereignty costs more. Understanding existing systems, adopting auditable solutions, keeping those skills in-house. That's a real investment.
But the calculation has to include the other side. What a dependency costs when it materializes. A vendor that doubles its pricing because you have no alternative. A security incident on a system nobody truly understands. 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 to manage. 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 genuinely asked: who actually understands the code running your critical systems?
If you're not certain of the answer, that's where to start.
About the Author
Titagone
Editorial Team
Expert in formal methods and software engineering at Titagone