In a previous article, I analysed what I called the micro macro trap of digital sovereignty. Individual actors, such as consumers and companies, optimize for their own goals. These decisions can be perfectly rational at the micro level while, in aggregate, increasing dependencies at the macroeconomic level.

My core argument was that we will only become more sovereign over time and as an economy if we work with these microeconomic patterns rather than against them.

This raises a practical question: What support do we actually give microeconomic actors when they make these decisions?

How do we govern our companies?

What I found is a crowded landscape of tools, frameworks, standards and regulatory instruments designed to help organizations deal with security, risk, compliance, resilience and digital sovereignty. Broadly, these instruments look at two different subjects.

Digital services and systems: These instruments help assess or regulate cloud services, AI systems, digital products, data ecosystems and other technologies. Examples include the EU AI Act, CRA, Cybersecurity Act, Data Act, EUCS, BSI C5, BSI C3A, CISPE Sovereign & Resilient Cloud Services Framework, Sovereign Cloud Stack Standards, ES³, SEAL / SOV and the Gaia X Trust Framework.

The organization itself: These instruments focus on how organizations govern technology, security and risk. Examples include NIS2, DORA, BSI IT Grundschutz, ISO 27001, ISO 27005, ISO 31000, ISO 42001, NIST CSF, COBIT, FAIR, COSO ERM, OCTAVE and ISO/IEC TS 10866.

Together, they cover a remarkably broad range of topics: AI, cybersecurity, data protection, data sharing, operational resilience, information security, risk management, IT governance and digital sovereignty.

Control seems the way to sovereignty

A remarkable share of these instruments follows one dominant paradigm: control.

This becomes particularly visible in instruments explicitly addressing digital sovereignty:

• SEAL / SOV: Assesses who controls the provider, which jurisdiction applies, where data is processed, who can access it, and how dependent the service is on external technologies and suppliers.
• ES³: Translates sovereignty into measurable properties, including control over data, infrastructure, operations and provider dependencies.
• Gaia X Trust Framework: Creates control through transparency and choice. Providers disclose information about jurisdiction, data protection, security, portability and contractual conditions so customers can make informed decisions and switch services.
• BSI C3A: Examines ownership and control of the provider, jurisdiction, data location, encryption keys, operations and dependencies on external software, hardware and suppliers.
• Sovereign Cloud Stack: Focuses on technological control. Open standards, interfaces and portable workloads should reduce lock in and preserve the ability to switch providers.

Different instruments, different mechanisms, but a recurring idea:

Control the data. Control access. Control jurisdiction. Control technology. Control dependencies. Preserve the ability to leave.

The underlying assumption: more control means more sovereignty.

The typewriter test

In this case, I always apply what I call the typewriter test. Imagine a 1980s electronic typewriter equipped with a simple, European designed and manufactured network adapter. It can communicate over the internet using standard protocols, but all service execution (writing letters) happens locally.

If this setup qualifies as perfectly sovereign, then the authors of the instrument might have a one-sided definition of digital sovereignty:

• SEAL / SOV: The typewriter should score highly given its European control, local operation and non-existing external dependencies.
• ES³: The typewriter should score highly thanks to its controllability and limited technological dependencies.
• Gaia X: The typewriter should do reasonably well: it retains control while following open standards (e.g. QWERTY key setup and DinA4).
• BSI C3A: The typewriter should score highly by avoiding all jurisdictional, operational and technological dependencies.
• Sovereign Cloud Stack: Conceptually, the typewriter should do great. Formally, it fails: SCS requires Ubuntu VM images. Our typewriter has none.

This thought experiment reveals a strong bias in our sovereignty frameworks towards one particular understanding of sovereignty: more control and fewer dependencies. Thought through, this logic ends in autarky.

But only few actors optimize for control

Europe’s digital sovereignty problem is ultimately a problem of dependency. We worry about kill switches, foreign access to data and our inability to respond with credible European alternatives or meaningful counter leverage.

But these dependencies did not simply happen to us. They are the aggregate result of millions of individually rational decisions by consumers, SMEs and enterprises.

The first Trump term was almost ten years ago. Anyone who cares about digital sovereignty knows the risks by now. Yet most of us keep choosing what is easy, convenient, integrated and cheap. VMware is easier to install than OpenStack. M365 is more integrated than the dPhoenixSuite. AWS offers more capabilities than Hetzner.

Because microeconomic actors do not optimize for control. They optimize for their own goals, balancing capabilities, cost, risk and control based on their technical expertise

And that balance looks different for everyone. Some consumers build elaborate home clouds on cheap Hetzner servers seamlessly integrating Raspberry Pis at the edge living full sovereignty. Others happily lock themselves into the Apple ecosystem, pay a premium for convenience and drink their latte in Prenzlauer Berg while joining a Zoom call having a party life in dependency. Some companies sell 40 percent of their products to the US while sourcing 60 percent of their supply chain from China. Try selling them autarky.

What happens when our well-meaning sovereignty frameworks meet these actors?

They ignore them when they can. And when they cannot, sovereignty becomes another compliance task to manage. You publish your annual accounts in the Bundesanzeiger, conduct your GDPR impact assessment, tick the required boxes in your sovereignty check and then get back to what you actually wanted to do: make money or run your amateur football club.

Risk mitigation needs to be cheaper

If the sovereignty bubble wants to win the hearts of ordinary decision makers, it needs to make sovereignty cheaper. That means giving up on the idea that every sovereignty problem requires the ideal sovereign solution. Instead, we should ask which specific risk the decision maker actually cares about and find the cheapest effective way to address exactly this risk.

If somebody fears an M365 kill switch, he needs a workable backup only rather than a completely sovereign office suite. If vendor lock in is the problem, Kubernetes and portable workloads may provide enough optionality. If foreign access to sensitive data is the concern, encryption under our own control might be the answer. And 80% solutions of each of these mitigations may also be fine if you consider all other risks, the individual actor is carrying, too.

This is where RiskOps comes in. Like DevOps and FinOps, it means bringing the discipline into decisions early and making it an integrated part of how technology is designed and operated, rather than adding it as a control afterwards. Start with the concrete risk, determine how much of it we are willing to accept, and implement the smallest effective control. Sovereignty then becomes a series of early and pragmatic risk decisions that ordinary organizations can actually afford to make.

If we can make the sovereign choice cheaper than the dependency it mitigates, microeconomic actors might actually make it voluntarily. Do that often enough, and their individual risk decisions start reducing Europe’s aggregate dependency.

One more thing: ISO 10866

Researching all the governance instruments, I found something unexpected: ISO/IEC TS 10866:2024, a Technical Specification on organizational autonomy and digital sovereignty. Its logic is remarkably different. It starts with the organization’s objectives, considers the associated risks and risk appetite, identifies the digital capabilities needed, and only then determines the required degree of autonomy.Thereafter, it does consider what this means for digital platforms and services.

In fact, this unique governance instrument explicitly starts with the business outcome, not IT. Sovereignty becomes a trade off to manage, rather than a state of maximum control.

There is one catch though: 10866 is currently just a 16 page Technical Specification. But, who knows, maybe sometime in the 2030s we will all need to be ISO 10866 certified.