Something has shifted in how organizations talk about technology. The conversations that once lived deep in engineering departments are now appearing in board presentations, government white papers, and procurement guidelines. The word at the center of almost all of them is the same: sovereignty.
Digital sovereignty is moving from abstract ambition to concrete priority. Governments, enterprises, and public institutions alike are asking a more urgent version of a question they have always carried:
How do we maintain meaningful control over our digital systems in an era of increasing complexity, evolving threats, and rising expectations from citizens and customers?
The stakes are real. Dependencies on hyperscale cloud providers, proprietary platforms, and foreign-owned infrastructure have made regulators nervous. Supply chain vulnerabilities, unexpected vendor lock-in, and the spiraling cost of maintaining aging systems have made executives uncomfortable. And architects and engineers of a generation of teams are exhausted, as they’re buried under the weight of systems they inherited but cannot fully understand.
Yet, despite all the attention it is receiving, sovereignty is still widely misunderstood.
The term digital sovereignty is used broadly today. Depending on who is speaking, it can refer to data residency requirements, national cloud infrastructure, open-source mandates, procurement policy, or simply the vague desire to be less dependent on large American or Chinese technology companies.
|
«Digital sovereignty is the freedom of choice – now, and especially later.» Stefan Minder |
|
Before sovereignty can be architected, it needs to be defined. A widely referenced starting point comes from the Swiss Federal Government:
«Digital sovereignty means that the state possesses the capacity to act in the digital space and has the ability to monitor it, thereby ensuring it can fulfil its tasks.»
This definition is deliberately broad. A more rigorous definition, rooted in the German Digital Summit 2018, has been adopted by the Netzwerk SDS as its guiding orientation:
«The digital sovereignty of a state or organization requires complete control over stored and processed data, as well as the independent authority to decide who may access it. It also includes the ability to independently develop, modify, and control technological components and systems, and to complement them with other components.»
Two things in the definition of Netzwerk SDS are worth examining carefully:
First, sovereignty is not satisfied by data residency alone. Storing data on servers located within national borders does not automatically mean an organization controls who can access that data under what legal conditions or through which technical pathways. Keeping full control over stored and processed data (and the independent authority to decide who may access it) is significantly more demanding than most compliance checklists acknowledge.
Second, and perhaps more importantly for architects and engineers, the definition explicitly includes the capacity to independently develop, modify, control, and extend technological components and systems. This is not a legal or procurement standard. It is a fundamentally operational and architectural one – asking whether an organization can act on its own systems and not just own them on paper.
This distinction matters enormously in practice. An organization can hold the source code license for a system and still be completely unable to evolve it. It might be because the internal knowledge has left, the architecture is too entangled to change safely, or the cost of operation consumes every available resource. In that situation, sovereignty is a legal fiction rather than an operational reality.
Digital sovereignty, properly understood, has three inseparable dimensions:
Technological sovereignty
This is the ability to understand, modify, extend, and replace systems as needs evolve, without being held hostage by technical debt, vendor lock-in, or irreplaceable complexity. Ownership without comprehension is not sovereignty. A system whose architecture is too entangled to change safely owns its organization, not the other way around.
Data sovereignty
This refers to the ability to control what data is collected, where it is stored, how it is processed, and who can access it under what conditions. Regulatory compliance does not equal genuine data sovereignty. The Schrems II ruling in 2020 illustrated precisely this: organizations that had built their data arrangements on legal agreements rather than architectural decisions found themselves exposed overnight.
Operational sovereignty
This is the ability to run, monitor, and maintain systems while retaining the knowledge and authority to intervene, change direction, or replace any service or vendor at any time. This is the quietest dimension and the most dangerous to neglect.
No organization operates in complete independence – every data center, every network, every supply chain introduces some external dependency. The question is not whether dependencies exist, but whether they are understood, bounded, and replaceable.
Organizations routinely discover they have lost control not during a crisis, but during a procurement renewal, when the knowledge and capability required to operate their systems turns out to live entirely outside their walls.
|
|
«If your data cannot move peer-to-peer under your control, it is not sovereign, it is mediated. Mediated data cannot deliver full value in a digital economy. Sovereignty requires digital agency, anchored in control over identity - driving competitiveness, autonomy, and resilience.» Daniel Saeuberli |
|
Sovereignty is a structural property. Therefore, all three dimensions must be present simultaneously. Losing any one of them erodes the others over time. Systems that cannot be modified become systems that cannot be maintained. Data arrangements that depend on external infrastructure create leverage that constrains architectural choices.
Digital sovereignty is not autarky. The goal is not to build everything in-house or reject external services and partnerships on principle. It is not anti-cloud. Cloud platforms can be used sovereignly if the dependencies are well understood and the exit options are real. It is not a one-time certification either. Rather than a state you achieve and then maintain passively, sovereignty is a property that requires active, ongoing architectural and governance decisions to preserve.
The real question sovereignty forces every organization to confront is: If your primary vendor disappeared tomorrow, if your key architect left next month, or if your budget was cut by a third, what would actually break, and how quickly could you recover?
The answer to that question reveals more about an organization's true sovereignty than any compliance document or technology strategy ever will.
Most organizational processes are optimized for solving discrete, bounded problems. A security audit has a scope. A migration project has a deadline. A compliance review has a checklist. Sovereignty has none of these affordances. It is a condition you either maintain or gradually lose – a meta-requirement. This is what makes it difficult to address.
The definition above makes this concrete. An organization is sovereign when it has full control over its data, the authority to decide who may access it, and the practical capacity to develop, modify, control, and replace its own systems. All three of these conditions must hold simultaneously. Each one can be eroded without triggering an obvious alarm.
That erosion tends to be invisible until it becomes irreversible.
A decision to adopt a proprietary integration layer seems reasonable in the context of a quarterly delivery pressure. A hiring freeze that is never fully reversed leaves a team dependent on a single architect who holds the operational knowledge for a critical system. A licensing model that seemed affordable at ten thousand users becomes structurally impossible to exit at one million. None of these moments announces itself as a sovereignty failure. Each decision is just a pragmatic trade-off at the time it is made.
This is why sovereignty is so often misunderstood. Organizations assess it at a point in time, usually during procurement and occasionally during audit. They later treat a satisfactory result as durable. But sovereignty is not a state. A system that scores well on every sovereignty criterion today can be deeply compromised in three years if the decisions being made now are systematically trading long-term control for short-term convenience.
The question is never «Are we sovereign?», but «In which direction are we moving, and how quickly?»
This reframing has practical consequences: sovereignty can neither be delegated entirely to a legal or compliance team, nor can it be resolved by a single architectural decision, however well-considered. Instead, it requires ongoing, cross-functional attention: from engineers making daily design choices, from architects setting structural patterns, from procurement teams evaluating vendor relationships, and from governance bodies that understand the cumulative cost of constrained decisions.
Sovereignty is the sum of a thousand smaller decisions. And that is exactly what makes it worth getting right. Its most common threat is not foreign dependence. It is your own systems quietly becoming too complex, too expensive, and too fragile to evolve.
For many organizations, sovereignty is not lost in a sudden event. It fades slowly, decision by decision, release by release.
Over years, custom-built systems grow heavier. Change requests take longer. Expertise narrows to a handful of individuals. And even when the code is «owned», the ability to evolve it is not. The result is what many public and private sector teams recognize today: systems that shape strategy instead of supporting it.
A key warning sign is budget allocation. When most of the IT budget is consumed merely by keeping legacy systems alive, there is little space left for strategic change. Innovation stalls. Risks accumulate. The system (not the organization) takes the driver's seat.
This quiet dependency is sovereignty's most underestimated enemy. And it has a name: complexity.
Complexity accumulates through individually rational decisions. A custom integration here. A proprietary service there. A framework chosen for speed that now requires specialists. A database that became the de facto API for a dozen surrounding systems. None of these felt dangerous at the time. Together, they create a system that nobody fully understands, that nobody wants to touch, and that consumes an ever-increasing share of resources just to remain operational.
If most of your budget goes to keeping the lights on, you are not sovereign. You are trapped.
Sovereignty is often framed as a legal or political concept. In practice it is also, and primarily, an architectural property, i.e. the long-term ability to steer what you have built.
The difficulty is that this ability does not appear on a dashboard. There is no sovereignty metric, no audit that returns a clean score. What you can measure are the signals: the structural properties of a system that, taken together, reveal whether you are gaining or losing freedom of action.
Every architectural choice influences that ability. To evaluate this, organizations can look at a set of strategic signals:
| Strategic signal | The question to ask |
| Total cost of ownership |
|
| Complexity |
|
| Replaceability |
|
| Operational surface |
|
| Interoperability |
|
| Observability |
|
These signals do not produce a binary answer, they reveal a direction. This direction matters more than any individual measurement, because sovereignty – like technical debt – is a trajectory, not a state.
No single dial tells the full story. A system can score well on replaceability but poorly on operational surface. It can be observable but deeply complex. The point is not to optimize each dial in isolation. It is to read them together as a pattern, understanding which way the pattern is moving.
Frameworks and tools to support this kind of assessment are beginning to emerge. Platforms like soversanity.ch offer a structured starting point for organizations that want to move from intuition to a more systematic reading of these signals. The field of sovereignty-as-architecture is young, and no tool yet captures its full complexity. But the direction is clear: organizations that start measuring today will be better positioned to act tomorrow.
Switzerland has taken meaningful legislative steps in the direction of open source. The Federal Act on the Use of Electronic Means to Carry out Official Tasks (EMBAG) mandates that the Confederation release software as open source wherever possible. This is a significant and welcome development, as it signals a clear direction and promotes independence.
|
«Increased digital sovereignty through open source technologies does not only strengthen our national resilience, but also provides the opportunity to improve competitiveness of the ICT sector, create attractive jobs and keep value creation in Switzerland.» Prof. Dr. Matthias Stürmer
|
|
Yet, open source alone does not mean «sovereign».
A system can be fully open source and still be:
too complex for any team of reasonable size to operate
so tightly coupled that replacing one component requires rewriting five others
dependent on a single vendor's operational expertise to run in practice
governed by a foundation whose roadmap does not align with your organization's needs
Open source addresses the legal dimension of sovereignty: the right to inspect, modify, and redistribute. It does not automatically address the operational, architectural, or governance dimensions. A codebase you own but cannot understand, run, and evolve is not a sovereign asset. It is a liability with an open license.
What is needed beyond open source is a commitment to modular, replaceable building blocks. Systems that any organization can adopt, operate, and evolve without requiring the original authors or a specific vendor to remain involved. This sets a higher bar, requiring architectural discipline from the very beginning.
Architecture and technology choices create the conditions for sovereignty. But conditions alone are not enough. What sustains them are governance decisions: how systems are funded, how evolution is prioritized, how teams are structured, and how dependencies are evaluated over time.
Governance is the glue. In most organizations, this is where sovereignty quietly breaks down.
Sovereignty-conscious governance requires:
Explicit dependency audits
Regularly evaluating which dependencies have become irreversible and what it would cost to exit them
Budget allocation discipline
Protecting a meaningful portion of IT investment for strategic evolution, not just operational maintenance
Capability preservation
Ensuring that internal teams retain the knowledge and skills to operate core systems, even when external providers are involved
Decision and knowledge documentation
Ensuring that decisions, system configurations, and operational procedures are explicitly recorded and shared across the organization
Procurement criteria that reflect architectural values
Evaluating vendors not just on features and price, but on the sovereignty properties of their components such as portability, interoperability, operational transparency, and exit feasibility
Continuous architecture review
Treating sovereignty as a living property that must be actively maintained, not a status that was achieved once and can be assumed to persist
Sovereignty lives in how we fund and evolve our systems, not just in the tools we choose.
This is why the conversation about digital sovereignty must reach beyond engineering teams into procurement, finance, and executive leadership. The architectural decisions are important. The governance decisions determine whether those architectural properties are actually maintained across time.
Organizations that sustain sovereignty over time share a recognizable discipline: they treat operational cost as an architectural concern, not an operational one. They make deliberate choices at design time that keep systems understandable, manageable, and evolvable. Some practitioners have begun calling this cluster of principles operational lightness or, more tersely, LowOps. The label matters less than the discipline it describes.
That discipline rests on five principles:
Secure by design
Security cannot be something you maintain. It must be something you build in. Systems with fewer moving parts have fewer failure points. When security properties depend on continuous manual intervention, they degrade the moment attention shifts elsewhere.
Sovereign systems are architected so that the secure path is also the default path.
Minimum operational surface
Every component added to a system carries a cost that extends far beyond its initial deployment: monitoring, maintenance, upgrade cycles, failure modes, and the specialist knowledge required to keep it healthy.
Sovereign systems are designed to minimize this surface deliberately. If a component requires a dedicated team to operate, it is a candidate for simplification or replacement.
Automation first
Manual processes are the enemy of sustainable operations. They require human availability, introduce variability, and accumulate as unwritten knowledge that disappears when people leave.
The goal is a system where routine operations require no human decision-making at all. Pipelines replace procedures. Automation replaces rituals.
Replaceable by design
Every component should be designed with the assumption that it will eventually be replaced. This means clear interfaces, documented contracts, stateless design where possible, and data ownership separated from processing logic.
A system designed for replaceability is a system that can evolve without organizational trauma.
Observable by default
You cannot govern what you cannot see. Monitoring, logging, and tracing must be present from day one.
Observable systems reduce the expertise required for incident response, make capacity planning tractable, and provide the evidence base that governance decisions require.
These principles protect long-term budget flexibility, reduce systemic fragility, and ensure that the cost of operating a system remains proportional to the value it delivers rather than to the complexity accumulated during its construction.
The question worth asking of any system is simple: Does operating it require heroics? If the answer is yes, sovereignty is already under pressure.
Digital sovereignty is a meta requirement.
It is not achieved through statements of intent, regulatory alignment, or isolated technology decisions. It emerges, or erodes, through the structures organizations build and the choices they repeat over time. The decisive factor is not where systems are hosted or how they are licensed, but whether they remain understandable, operable, and evolvable under real-world constraints.
Sovereignty holds when architecture limits complexity, preserves replaceability, and keeps operational effort proportional to value. It survives when governance protects these properties against short-term pressure.
The relevant question is therefore not whether sovereignty has been declared, but whether today’s decisions are increasing or reducing the organization’s freedom to act tomorrow.