A government employee opens a spreadsheet.
It works.
A colleague joins a video call.
It works.
Someone edits a document, searches an email archive, approves an invoice, shares a presentation and schedules a meeting.
Everything works.
Thousands of people perform millions of small actions like these every day.
Nobody thinks about sovereignty.
And perhaps they should not.
Successful infrastructure is supposed to disappear.
The more reliable it becomes, the less attention we give it. The interfaces become familiar. The workflows become habitual. Other systems connect to it. Knowledge accumulates around it. New employees learn it. Procedures assume it exists.
Eventually it stops feeling like a technology choice.
It simply becomes how the organisation works.
That is the moment when a different question becomes important.
Not:
How well does the system work?
But:
What would happen if we had to stop using it?
That is the Exit Test.
Switzerland is asking the right question
The Swiss Federal Administration currently provides an unusually useful example.
Its BOSS proof of concept is examining open-source alternatives for office automation as part of a broader objective to strengthen digital sovereignty. The project is not framed as an ideological rejection of commercial software. It investigates emergency office automation, the secure handling of sensitive information and the feasibility of maintaining alternatives to the existing environment.
That distinction matters.
Microsoft 365 does not need to be bad for dependency on Microsoft 365 to be strategically relevant.
In fact, the opposite may be true.
The better a system becomes, the easier it is to depend upon.
Convenience attracts workloads.
Workloads attract integrations.
Integrations create procedures.
Procedures create skills.
Skills create organisational habits.
And habits gradually become assumptions.
Dependency therefore rarely arrives as a bad decision.
It accumulates through thousands of perfectly rational ones.
This is why sovereignty cannot be measured only at procurement.
The real question appears years later.
Can you still leave?
Owning the data is not enough
The simplest version of the Exit Test concerns data.
Can everything be exported?
Documents.
Email.
Databases.
Audit records.
Configuration.
Metadata.
Identity information.
Logs.
Model artefacts.
Knowledge repositories.
That is important.
It is also only the beginning.
Imagine an organisation successfully exports twenty years of documents from one platform.
Excellent.
Now what?
Can another platform interpret the permissions?
Can it reproduce the workflows?
Do document links survive?
Do macros still execute?
Do templates work?
Are retention rules preserved?
Can historical audit trails still be inspected?
Do automation scripts continue?
Can authentication be reconstructed?
What happens to applications that relied on proprietary APIs?
Can employees still find anything?
The data may have left.
The organisation has not.
This is the difference between portability and replaceability.
Europe has started recognising this distinction.
The EU Data Act, applicable since September 2025, includes provisions intended to make switching between data-processing and cloud services easier. Cloud customers are supposed to be better able to move between providers or operate services from several providers in parallel.
That is useful regulation.
But regulation can provide a right to exit.
It cannot manufacture the capability to exercise it.
The six exit tests
A more useful way to examine dependency is to separate exitability into several layers.
1. The data exit
Can we retrieve the information required to continue operating?
Not merely files.
Relationships.
Metadata.
Configuration.
History.
Context.
Auditability.
A database dump that nobody can meaningfully reconstruct is technically an export and operationally a failure.
2. The technical exit
Can another technology actually perform the required functions?
A theoretical alternative is not enough.
Can the workload run there?
Can the interfaces connect?
Can identity be migrated?
Can security requirements still be met?
Can performance remain acceptable?
Can the organisation actually deploy it?
3. The operational exit
Can the organisation continue its essential processes during the transition?
Systems rarely exist alone.
Finance talks to identity.
Identity talks to HR.
Documents feed workflows.
Workflows trigger approvals.
Approvals trigger payments.
Monitoring depends on logging.
Reporting depends on everything.
Replacing one technology often means discovering how deeply it had become embedded in the surrounding organisation.
4. The competence exit
Do people still know how to operate the alternative?
This is one of the most underestimated forms of dependency.
Infrastructure can remain technically replaceable while becoming institutionally irreplaceable.
Knowledge disappears.
Administrators specialise.
Procedures decay.
Documentation becomes historical.
The alternative remains on an architecture diagram.
Nobody has used it for five years.
That is not redundancy.
It is archaeology.
5. The time exit
How long would leaving take?
This may be the most brutal test of all.
An organisation might possess the data, technology and expertise necessary to migrate.
But if the migration requires eighteen months and the dependency disappears in fourteen days, the distinction is academic.
Exitability therefore has a temporal dimension.
An alternative that cannot be activated within the time available is not an operational alternative.
6. The authority exit
Who can actually make the decision?
Technology organisations sometimes build alternatives that the institution lacks the authority to activate.
Contracts intervene.
Regulators intervene.
Budget cycles intervene.
Procurement rules intervene.
Governance bodies intervene.
Political responsibility intervenes.
The engineers may know exactly how to migrate.
That does not mean the organisation can.
Sovereignty therefore requires more than technical optionality.
It requires decision-making capacity.
Europe is beginning to measure the deeper problem
This broader understanding of dependency is increasingly visible in European policy.
The European Commission's proposed Cloud and AI Development Act introduces a sovereignty framework with several levels.
At its most basic level, sovereignty concerns data being processed and stored within the European Union.
But the framework does not stop there.
Higher levels introduce questions about independence from third countries, transparency of software supply chains, ownership and control.
This is an important conceptual shift.
For years, discussions about sovereign cloud often collapsed into geography.
Where is the data centre?
Where are the disks?
Where are the backups?
Location matters.
But geography alone tells us surprisingly little about control.
A server may stand in Europe while depending on software developed elsewhere.
A European subsidiary may operate infrastructure controlled by a parent company under another jurisdiction.
A local cloud may depend on foreign identity systems, processors, firmware, repositories, management software or security tooling.
A European AI service may ultimately depend on models, accelerators, libraries and platforms controlled outside Europe.
Physical location answers one question.
Sovereignty asks many more.
The stack beneath the promise
This becomes particularly obvious with artificial intelligence.
Europe wants more sovereign AI capability.
Switzerland does too.
In July 2026, ETH Zurich described Apertus 1.5 as another step towards a longer-term sovereign AI infrastructure—an open alternative to proprietary commercial models intended for research, education, public administration and industry.
That is strategically interesting.
But even a fully open model does not remove dependency.
The model needs compute.
Compute needs accelerators.
Accelerators need firmware.
Clusters need networking.
Networking needs equipment.
Equipment needs supply chains.
Training needs frameworks.
Frameworks need libraries.
Libraries need repositories.
Operations need identity, monitoring, storage and security.
Everything needs electricity.
And eventually someone must understand how all of it works.
This is why sovereignty cannot be purchased as a product.
There is no sovereign-model button.
No sovereign-cloud SKU.
No sovereign operating system that magically confers sovereignty on the organisation using it.
Every layer may improve the situation.
None is the whole system.
The useful question remains:
If this component disappeared tomorrow, what would we no longer be able to do?
Dependency is not failure
There is a temptation at this point to reach the wrong conclusion.
If dependency creates risk, perhaps the answer is independence.
Build everything ourselves.
Host everything ourselves.
Use only domestic suppliers.
Avoid foreign technology.
Avoid platforms.
Avoid external services.
That is not sovereignty.
That is usually inefficiency disguised as principle.
Modern economies are networks of dependency.
So are modern companies.
So are modern states.
Switzerland does not manufacture every semiconductor it uses.
Europe does not control every software library running inside its infrastructure.
The United States depends on foreign manufacturing.
China depends on technologies and markets beyond its borders.
Nobody meaningful is self-sufficient.
Nor should they try to be.
The question is not whether dependency exists.
The question is whether dependency remains governable.
Can we see it?
Can we evaluate it?
Can we reduce concentration?
Can we preserve competence?
Can we build alternatives where the consequences justify them?
And can we leave when circumstances change?
That is sovereignty.
Convenience spends optionality
The difficult part is that optionality has a cost.
Two systems are more expensive than one.
Multiple suppliers complicate procurement.
Portable architecture can require compromises.
Open standards may not expose every proprietary feature.
Training people on alternative systems takes time.
Maintaining unused capability feels inefficient.
Exit exercises interrupt productive work.
Redundancy looks wasteful while nothing is wrong.
Optimisation therefore pushes naturally in the opposite direction.
One provider.
One platform.
One identity system.
One preferred architecture.
One operational model.
Standardise everything.
Reduce duplication.
Improve efficiency.
And each decision makes perfect sense.
Until the conditions change.
This is how sovereignty is usually lost.
Not through surrender.
Through optimisation.
The organisation gradually exchanges optionality for convenience, and because every individual trade looks rational, nobody notices how much freedom disappeared in aggregate.
An exit clause is not an exit capability
Most serious enterprise contracts already consider termination.
There are clauses.
Notice periods.
Data-return obligations.
Transition assistance.
Deletion certificates.
Service continuity provisions.
Lawyers can review them.
Procurement can approve them.
Boards can be reassured.
We have an exit strategy.
Perhaps.
But contractual exit and operational exit are different things.
A supplier can fulfil every contractual obligation and the customer can still be unable to leave.
The files arrive exactly as promised.
The organisation cannot reconstruct the system.
The licence ends exactly on schedule.
The replacement is six months behind.
The supplier provides transition support.
Nobody internally understands the legacy architecture well enough to direct it.
The contract worked perfectly.
The exit failed.
This is why exitability cannot remain a document.
It has to become a capability.
Rehearse the exit
Organisations already understand this principle elsewhere.
We do not call a backup reliable because the backup job says SUCCESS.
We restore it.
We do not call disaster recovery credible because a secondary environment exists.
We test failover.
We do not assume emergency procedures work because someone wrote them.
We exercise them.
Exit strategies deserve the same discipline.
Move a real workload.
Restore real data elsewhere.
Operate an alternative identity system.
Rebuild an application from documented dependencies.
Measure how long it takes.
Record what breaks.
Discover which knowledge exists only in people's heads.
Find the contract nobody remembered.
Identify the proprietary format everyone assumed was open.
See which alternative looked convincing in PowerPoint and collapsed under production load.
Then fix it.
A rehearsed exit is expensive.
An unrehearsed exit is imaginary.
The paradox of the unused alternative
There is another problem.
Alternatives decay when they are not used.
This happens everywhere.
A second supplier exists but receives almost no orders.
A disaster-recovery environment exists but runs old configurations.
An open-source alternative is installed but nobody works with it.
A manual procedure survives in documentation but no employee has performed it for years.
A second cloud account exists but all automation targets the first.
Formally, redundancy remains.
Operationally, it slowly disappears.
This produces a strange requirement.
If an alternative is important enough to preserve, it must occasionally be used.
Not because it is better.
Because capability requires practice.
This is exactly why a project such as Switzerland's BOSS experiment is more interesting than a simple procurement debate.
The important question is not whether open-source office software should replace Microsoft 365 tomorrow.
The important question is whether Switzerland retains enough knowledge, infrastructure and practical experience to have a meaningful choice if circumstances change.
That is a much more mature objective.
The geopolitical layer
For most organisations, technology procurement used to be treated primarily as a commercial decision.
Price.
Performance.
Features.
Security.
Support.
Integration.
Those remain important.
But technology now sits increasingly close to geopolitical power.
Semiconductors can be restricted.
Cloud services are subject to jurisdiction.
Software distribution can be disrupted.
Supply chains can become instruments of policy.
Acquisitions can change ownership.
Governments can impose sanctions.
Export controls can redefine what technology may be sold, to whom and under which conditions.
The probability of any individual dependency disappearing tomorrow may remain small.
The consequence can still be enormous.
That changes the architecture question.
When critical systems depend on technologies beyond an organisation's control, geopolitical risk becomes a technical property of the system.
Not because foreign suppliers are inherently unreliable.
Because external control exists.
A dependency can remain entirely rational while still requiring an exit path.
The ultimate architecture review
Perhaps we therefore need a different question in architecture reviews.
We spend enormous effort asking whether a proposed system can scale.
Can it handle ten times the traffic?
Can it survive a server failure?
Can it recover from a database outage?
Can it remain secure?
Can it meet the SLA?
All sensible questions.
But perhaps one more belongs beside them.
How do we stop using it?
What has to be extracted?
What has to be rebuilt?
What knowledge has to survive?
What standards matter?
What dependencies sit underneath it?
How much time would migration require?
Who has the authority to trigger it?
What would continue operating during the transition?
What would not?
And when did we last prove any of this?
Suddenly exit architecture stops looking like procurement hygiene.
It becomes resilience engineering.
The Exit Test
Take any important dependency.
Your cloud.
Your AI provider.
Your identity platform.
Your ERP.
Your payment network.
Your chip supplier.
Your communications infrastructure.
Your code repository.
Your office suite.
Your logistics provider.
Your energy source.
Then imagine that tomorrow the relationship changes.
Perhaps the supplier fails.
Perhaps the product is discontinued.
Perhaps prices become unacceptable.
Perhaps an acquisition changes the risk.
Perhaps regulation changes.
Perhaps geopolitical relations deteriorate.
Perhaps the technology simply stops being the right choice.
Now ask six questions.
Can we retrieve what matters?
Can something else perform the function?
Can we operate during the transition?
Do we still possess the competence?
Can we move in time?
Do we have the authority to act?
If the answer to all six is yes, the dependency may be deep.
But it remains governable.
If several answers are no, the organisation may still own the contracts, the servers and the data.
It may still be extraordinarily efficient.
It may still have excellent suppliers.
It may still believe it is in control.
But it has transferred something important.
The ability to choose differently.
Sovereignty begins where convenience ends
There is nothing wrong with choosing the best technology available.
There is nothing inherently sovereign about inferior domestic technology.
There is nothing noble about rebuilding commodity infrastructure simply because someone else built it first.
Sovereignty does not require avoiding dependency.
It requires understanding what the dependency costs beyond money.
Every convenience creates an assumption.
Every assumption can become a dependency.
Every dependency transfers some degree of control.
Most of those transfers are perfectly acceptable.
Some are enormously beneficial.
The mistake is allowing them to become invisible.
A sovereign organisation can use American cloud services, European infrastructure, Chinese hardware, Swiss software and open-source libraries from people it has never met.
The origin is not the decisive question.
The decisive question is whether enough alternatives, knowledge and authority remain to change course.
That is harder than procurement.
Harder than localisation.
Harder than regulation.
Harder than writing an exit clause.
Because genuine optionality must be maintained while everything is working.
And there is always something more urgent to do while everything is working.
That is precisely why it matters.
We tend to discover dependencies when they fail.
We should discover them while they succeed.
The ultimate test of a dependency is not whether it works while the relationship is good.
It is whether you can still function when the relationship ends.
You are not sovereign because you own the contract.
You are sovereign when you can leave.