- Digital sovereignty rests on three pillars, not one.
Data control, governance, technological independence. Public debate concentrates on the first two. The third is the least covered, and yet the most decisive. - Technological independence is the most neglected pillar, and that is no accident.
Suppliers have no interest in drawing attention to it. Lock-in is rarely explicit. It is structural: it settles in through data, configurations and team habits. - The risks of dependency go well beyond the cyberattack.
A prolonged outage, extraterritorial laws, a brutal price rise, a regulatory requirement forcing a fast migration. Without a way out, each of those scenarios becomes a crisis. - Reversibility is the forgotten pillar of sovereignty.
It is not the ability to export, it is the ability to start again elsewhere. Recovering your data, your configurations and your history, in a usable format and within workable timescales. - The right strategy is not to refuse the best SaaS tools, it is to stop them becoming dead ends.
Use the best tool, yes, but keep your data and your ability to leave. The real test of sovereignty is not the way in to a supplier. It is the way out.
Data sovereignty is discussed at length: where data sits, GDPR compliance, protection against extraterritorial laws. But an organisation is not truly sovereign until it can retrieve its data quickly and keep operating without its supplier. That is where the debate stalls: on reversibility. A strategic subject, and still too rarely addressed.
The three pillars of digital sovereignty
Digital sovereignty has become a keyword in tenders, in executive committees and in cloud policies. Behind the term, though, three complementary pillars need to be told apart.
Data control
Data control is the most visible pillar of digital sovereignty. Controlling your data means knowing where it is stored, who accesses it and how it is processed, and making sure all of that stays compliant with the regulations in force. It also means keeping legal and intellectual ownership of what you produce.
On this ground, the large SaaS vendors have made considerable progress. ISO certifications, SOC 2 reports, data residency, encryption: the guarantees have grown stronger and the level of maturity has risen.
Governance
Governance is the ability to define and enforce your own rules: who has access to what, on what criteria, with what audit trail. It covers access control, auditing, internal compliance and the ability to steer how systems are used without outside help.
Here too, the vendors have invested. Administration consoles, security policies, audit logs: IT departments now have powerful tools to keep their SaaS environments in check, at least for as long as those services remain available.
Technological independence
Technological independence is the least visible pillar of digital sovereignty, and often the most decisive. It is the ability not to be locked into a supplier, a proprietary format or a closed ecosystem. It is the option to migrate, to adapt, to replace.
It is also the point vendors communicate about the least. Their model rests in part on retention: the more your data, your configurations, your automations and your teams' habits are woven into their environment, the higher your cost of leaving. Lock-in is not always explicit. It is often structural.
The risks: beyond the cyberattack
Digital risk is usually pictured as hacking, a data leak or ransomware. But depending on a SaaS supplier exposes you to a good many other scenarios.
Technical risks
A major outage at a SaaS supplier is in no way hypothetical. When your project management tool, your wiki or your support platform becomes unavailable, it is not a mild inconvenience: it is a business interruption. And the more central the tool, the more visible the dependency becomes.
Geopolitical risks
Extraterritorial laws, such as the American CLOUD Act, are often cited, and rightly so. But the risk does not stop there: sanctions, embargoes, access restrictions, political trade-offs. A shift in the international context can call access to a critical service into question overnight.
Contractual and commercial risks
Sudden price rises, unfavourable changes to terms of use, restricted APIs, an acquisition followed by a product being discontinued: these situations are common in the software ecosystem. The problem is not only that they happen. It is that they leave you in a position of weakness if you cannot get out quickly.
Regulatory risks
A new sector requirement, an unfavourable audit or tighter rules on transfers outside the EU can force a change of tool at short notice. Without a reliable and recent extraction, the migration becomes a high-risk project.
Protecting yourself: the solutions for each axis
The levers against these risks differ from one pillar of digital sovereignty to the next.
On data control
Encryption with keys held by the organisation (BYOK), the choice of certified suppliers and hosting in jurisdictions compatible with your requirements all strengthen your position. Setting out data ownership explicitly in the contract remains essential too.
On governance
SIEM, IAM and automated audit tools now make fine-grained control possible. But technology is not enough: governance also rests on rules that are clear, documented and applied over time.
On technological independence
Technological independence is the least mature of the three areas. Favouring open formats and interoperable standards, and assessing portability before choosing a tool, is a good start. But you have to go further, with a concrete mechanism: reversibility.
SaaS reversibility: the forgotten pillar of digital sovereignty
What reversibility means
Reversibility is the effective ability, not the theoretical one, to recover your data in a usable format, within timescales compatible with business continuity, and then to reuse it elsewhere. And it is not only about raw data: you also have to be able to recover metadata, attachments, history, permissions, configurations, and even certain key automations and integrations.
In other words, the question is not only:
"Can I export?"
The real question is:
"Can I start again elsewhere and keep operating?"
Why it is so often neglected
Reversibility is neglected first of all because it does not serve the supplier's interests. Export functions exist, but they are often partial, slow or limited by the APIs. Then, because as long as all is well, the subject stays invisible. Like any insurance, its value is discovered at the moment it becomes urgent, which is to say too late.
Lastly, because it is technically demanding. A usable export is not just a CSV. You have to understand the data model, manage quotas, check consistency, organise storage, and verify that what comes back really can be reused.
A simple principle: use the best tool, but keep your ability to leave
Let us be pragmatic. An organisation has nothing to gain from denying itself a good tool on purely ideological grounds, barring a specific sector constraint (defence, healthcare, critical infrastructure). The right strategy is not to refuse the best SaaS tools. It is to stop them becoming dead ends.
Use the best tool, but keep your data and your ability to leave.
Reversibility is not an anti-supplier stance. It is business continuity hygiene.
The real test of sovereignty is not the way in to a supplier. It is the way out.
When reversibility becomes critical:
-
A prolonged supplier outage. If a critical tool is unavailable for 48 hours, a recent local copy can keep you running in degraded but viable mode.
-
A contractual break. If prices explode or the product disappears, having a usable base of your own saves you from negotiating under duress.
-
A regulatory constraint. If an audit forces a fast migration, the absence of a reliable extraction turns the subject into a crisis.
-
A merger or acquisition. Consolidating histories, projects, users and configurations first assumes you can recover them cleanly.
-
Archiving and compliance. When retention obligations outlast the life of a subscription, a local copy in a durable format becomes indispensable.
8 questions to assess your ability to leave
Before treating a SaaS environment as genuinely under control, you have to check your ability to leave it. These questions help you assess whether your organisation can recover its data and its essential configurations, and resume an acceptable level of activity within timescales that match its operational stakes.
-
Can the data be exported on a regular basis?
-
Is the export format genuinely usable?
-
Are attachments, history, permissions and metadata included?
-
Do the API quotas allow a fast extraction?
-
Does a recent copy exist outside the supplier's environment?
-
Has the exit scenario ever been tested?
-
Are the responsibilities documented internally?
-
Does the contract clearly set out the conditions for returning the data?
In summary
Digital sovereignty comes down neither to where data is located nor to legal compliance alone. Legal sovereignty, meaning the law under which my data is processed, has to be told apart from operational sovereignty: am I able to take back control and keep operating without my supplier?
That is where reversibility becomes central.
Data you cannot recover quickly, completely and in a usable format is not really under your control. Reversibility is not a luxury. It is a prerequisite.
Why not start with this question: in the event of a break with your main SaaS supplier, how long would it take you to recover your data and your essential configurations, and resume an acceptable level of activity?
If the answer makes you uncomfortable, it is time to deal with it.
FAQ
What is the difference between legal sovereignty and operational sovereignty?
Legal sovereignty answers the question: under which law is my data processed? Operational sovereignty asks a different question: am I able to keep operating without my supplier? Both are necessary, but the second is more rarely addressed.
Is a CSV export enough to guarantee reversibility?
No. A raw export covers neither metadata, nor attachments, nor history, nor configurations, nor automations. Real reversibility means being able to resume the activity, not just to read a file.
Does reversibility only concern large accounts?
No. Any organisation whose activity depends on a critical SaaS tool is exposed. Size changes the scale of the risk, not its nature.
How can you assess the reversibility of a SaaS tool before choosing it?
By examining the export formats available, how complete the extractable data is, the API timescales and quotas, the documentation of the data model, and the ability to reuse those exports in another environment.