Digital sovereignty is the ability to change course

A local contract or regional data centre may satisfy a procurement requirement. Sovereignty appears when authority, continuity and exit remain under institutional control.

A service is hosted inside the country.

The supplier is locally incorporated. The contract says the data remains within the region. The procurement record marks the sovereignty requirement as satisfied.

Then the organisation needs to change provider.

Its identity model exists only inside the platform. Configuration was performed through a proprietary interface. Logs cannot be exported in a useful form. The data can be downloaded, but the schemas, access rules and event history required to operate it elsewhere are incomplete.

The service was local.

The dependency was not sovereign.

The central test

Digital sovereignty is the practical ability to govern a system, continue it through disruption and change its operators, platforms or policies without surrendering institutional purpose.

Sovereignty is not the nationality of a supplier

Supplier location matters.

Jurisdiction, legal process, support access, supply chains and public-policy objectives can all influence a technology decision.

But nationality is not an architecture.

A domestic provider can operate an opaque platform with weak export, concentrated expertise and no credible recovery path. A foreign provider can sometimes be used within a bounded design where identity, keys, configuration, data copies and exit evidence remain under organisational control.

Neither arrangement is automatically sovereign.

Common mistake

Treating local ownership, regional hosting or data residency as a complete sovereignty test.

Better framing

Review sovereignty across authority, data, technology, operations, supply chain and exit. Location is one property inside that model.

Sovereignty should not become a slogan used to avoid technical analysis.

The useful question is not whether a supplier can be described as sovereign.

It is which decisions the organisation can still make after the supplier has been selected.

Sovereignty has several control planes

A practical model separates six planes.

Legal authority and jurisdiction
              |
Identity and cryptographic control
              |
Data, metadata and retention
              |
Software, configuration and interfaces
              |
Operations, evidence and recovery
              |
Skills, suppliers and exit capacity

Legal authority determines which rules, contracts and external powers apply.

Identity and cryptographic control determine who can administer the system, recover access and read protected data.

Data control includes authoritative copies, schemas, lineage, retention and deletion—not merely storage location.

Technology control includes source, configuration, standards, APIs and the ability to reproduce essential behaviour.

Operational control includes monitoring, incident response, recovery and evidence.

Exit capacity includes skills, supplier alternatives, migration sequence and the ability to transfer responsibility.

A system can be strong in one plane and weak in another.

Data may remain in-region while encryption keys are controlled through an external service. Software may be open source while only one supplier can operate the deployment. Identity may belong to the institution while recovery depends on a proprietary control plane.

Sovereignty is not achieved by finding one reassuring property.

It is achieved by preventing one weak plane from controlling the whole system.

Data residency is not data control

Data residency answers where data is stored or processed under defined conditions.

That can be important for legal, security, latency and policy reasons.

It does not answer:

who can decrypt the data
which administrators can access it
whether support systems create copies elsewhere
where backups and logs reside
whether metadata can be exported
whether the data remains usable outside the service
how deletion is verified
which legal authorities can compel access

A database located nearby can still be operationally distant.

The organisation may possess the records but not the catalogue, identities, history or application logic required to use them independently.

Sovereign data architecture therefore needs more than a location statement.

It needs an authority map.

Who controls the keys? Who approves access? Which copy is authoritative? How are secondary uses governed? Which evidence survives the supplier relationship? What must be transferred for another operator to understand the data?

The bytes are only one part of the answer.

Switching is an architecture sequence, not a contract promise

The EU Data Act has applied since September 2025 and includes measures intended to support switching between cloud providers and the use of services from several providers. That policy direction is significant: portability and switching are being treated as conditions of a functioning digital market, not optional product features. (European Commission)

Regulation can create rights and obligations.

It cannot create architecture artifacts that never existed.

A provider may be required to assist switching while the customer has no current system inventory, no independent configuration record, no tested export, no replacement identity model and no understanding of platform-specific logic.

The right to leave does not shorten the work required to leave.

A real switching sequence includes:

preserving administrative authority
identifying authoritative data and configuration
exporting data with semantics intact
reproducing or replacing service behaviour
transferring identity and integrations
validating the replacement
redirecting users and dependent systems
revoking old access
verifying retention or deletion
preserving evidence of the transition

This sequence should be designed while the relationship is healthy.

Exit becomes most difficult when access, time and cooperation are already constrained.

Interoperability is more valuable than imitation

Sovereignty does not require every platform to behave identically.

An organisation rarely needs to recreate an entire supplier feature by feature. It needs to preserve the capabilities essential to its mission and maintain a credible way to replace the rest.

That makes interoperability more useful than perfect portability.

Interoperability allows systems to exchange data, identity and instructions through understood contracts. It supports federation, workload placement and gradual replacement. It reduces the need for one platform to become the permanent home of every function.

Current European initiatives increasingly connect sovereignty with open and federated infrastructure. The Commission-backed Simpl project, for example, is an open-source middleware effort for interoperable data spaces. (European Commission)

The important architectural pattern is not “everything must be European” or “everything must be self-hosted”.

It is:

No single platform should silently acquire authority over data, identity and service continuity merely because integration was convenient.

Federation can preserve local control while enabling shared capability.

It succeeds only when trust, identity, policy and evidence remain explicit.

Open source helps when the organisation can operate it

Open source can strengthen sovereignty.

It can make behaviour inspectable, allow independent operation, support several suppliers and preserve legal rights to continue software.

It does not automatically create sovereign capacity.

A platform may be open while its deployment depends on one integrator. A source repository may be available while the build, release and security processes are not. A community project may be globally governed in ways no single country or institution controls.

That may be desirable.

Sovereignty is not the same as unilateral control over every dependency. It is the ability to make informed choices and preserve continuity when dependencies change.

The European Commission’s cloud and edge work has explicitly connected open-source technologies with interoperable ecosystems and control over data-space access. That connection is strongest when openness is paired with skills, governance and operational transfer—not when procurement treats an open licence as sufficient proof. (European Commission)

Open source creates options.

Institutions still need the capability to exercise them.

Procurement should ask for executable evidence

Sovereignty requirements often appear as adjectives:

sovereign
trusted
European
secure
portable
open
independent

Adjectives are difficult to test.

Procurement becomes more useful when it asks for actions and evidence.

Instead of “The solution must be portable,” ask:

Which data, metadata and configuration can be exported?
In which formats?
How long does a complete export take?
Which service behaviour is not included?
Can the export be validated independently?
What assistance is available during transition?

Instead of “The customer retains control,” ask:

Which privileged identities belong to the institution?
Who controls encryption keys and recovery factors?
Can administrators regain access without supplier staff?
Which support roles may access the environment?
Which actions are recorded outside the supplier’s control?

Instead of “The platform is interoperable,” ask:

Which published interfaces are used?
Which extensions are proprietary?
Can another implementation pass the same tests?
Which integrations must be rewritten during replacement?

A requirement becomes sovereign when the organisation can verify it without relying solely on the supplier’s description.

Sovereignty must be proportional

Not every service needs the same degree of independence.

A temporary collaboration tool does not require the same sovereignty controls as national identity infrastructure, research archives, health systems or public financial services.

Attempting to eliminate every external dependency can make systems more expensive, less capable and harder to operate.

Sovereignty should therefore be tiered by consequence.

Level	Typical requirement
Replaceable service	Usable export, documented identity, ordinary exit process
Important institutional service	Independent recovery, configuration evidence, tested transfer
Critical service	Organisational keys and authority, separated failure domains, rehearsed exit
Strategic infrastructure	Multiple operating paths, durable standards, supply-chain and skills strategy

The exact levels will vary.

The principle is to match control to the damage caused by losing it.

Sovereignty without prioritisation becomes symbolic self-sufficiency.

Sovereignty with clear tiers becomes an engineering programme.

A practical sovereignty review

Plane	Weak signal	Stronger evidence
Jurisdiction	Data is hosted in-region	Applicable authorities, support access and contractual boundaries are understood
Identity	The organisation has administrator accounts	Root authority, recovery factors and privileged-role ownership are institutional
Cryptography	Data is encrypted	Key custody, rotation, recovery and supplier access are explicit
Data	Exports are available	Data, metadata, schemas, lineage and integrity can be validated independently
Technology	Open standards are mentioned	Interfaces and replacement implementations are tested
Operations	The supplier provides monitoring	The organisation retains required evidence and can coordinate recovery
Skills	Documentation will be delivered	Another qualified team can operate or transfer the service
Exit	Termination terms exist	A timed, tested transition sequence with completion evidence exists

The review should expose where control actually sits.

It should not be used to award a sovereignty badge.

Sovereignty is preserved through optionality

A sovereign organisation can still cooperate internationally, consume managed services and depend on global open-source communities.

The question is whether those relationships remain choices.

Authority should be recoverable.

Data should remain meaningful.

Configuration should survive the interface.

Operations should be transferable.

Exit should be possible before it becomes urgent.

Digital sovereignty is therefore less about where a platform was born than about whether the institution can change course without losing its ability to function.

A provider can be local and still become irreplaceable.

A service can be global and still sit inside a deliberately bounded architecture.

The difference is not branding.

It is control that has been designed, tested and retained.

One question for the next architecture review

Choose the platform most often described as sovereign and ask:

Which decision could the organisation no longer make if the current supplier, control plane or legal arrangement changed—and what evidence shows that decision can be recovered?