How independent do you want to be?
We’d be happy to help you with specific answers or a solution tailored to your organization.
Personalized advice tailored to your situation
In-depth information not included in the white paper
A no-obligation introductory meeting with one of our specialists
Please leave your contact information, and we’ll get in touch with you shortly. We look forward to working with you to find the best solution!
If you want to read the knowledge document as plain text, you can do so below:
Date: August 2026
Digital sovereignty is high on the European and Dutch agendas, but in practice, the concept remains vague. In this paper, we describe what digital sovereignty entails, the definition Pegamento uses, and why a “sovereign” cloud from an American hyperscaler is not automatically sovereign. Based on our own choices for open source and Dutch hosting, we demonstrate that a viable alternative exists. We conclude with an approach that allows every organization to determine for itself where dependence is acceptable and where it is not.
Digital sovereignty has quickly become a central theme in the European technology and policy debate. Governments, companies, and institutions want to reduce their dependence on foreign technology companies and gain more control over their data, digital infrastructure, and software. At the same time, dependence on a small number of large cloud and software providers—almost all of which are based in the United States—is actually increasing. Many European organizations now run their critical systems on platforms provided by Amazon, Microsoft, and Google.
This dependence raises questions about control and jurisdiction. Data that is physically located in Europe may still be subject to U.S. law. This issue is also becoming increasingly prominent in the Netherlands. Research shows that a large portion of the digital infrastructure on which public services run is provided by U.S. technology companies, resulting in legal and geopolitical risks regarding control over data (Strop & Verlaan, 2024).
The appeal of these platforms is easy to explain. They offer scalability, flexibility, and rapid access to new services such as advanced AI applications. Outsourcing helps organizations develop faster and reduce costs. On the other hand, with every layer outsourced, an organization also relinquishes some control over data, technology, and decision-making.
In this paper, we explore the concept of digital sovereignty, explain the definition used by Pegamento, and examine where the boundaries lie using real-world examples. The central question is: To what extent are organizations willing to sacrifice the convenience and widespread technological adoption offered by big tech in favor of a truly sovereign solution?
Chapters 3 and 4 address the concept itself and our definition. Chapter 5 uses a current example to demonstrate how flexible the term “sovereign cloud” is. In Chapter 6, we describe how we have implemented this ourselves, and in Chapters 7 and 8, we translate that into an approach and an answer to the central question.
In the context of digital technology, sovereignty refers to the extent to which an organization has control over its digital infrastructure, data, and software. This concerns not only the physical location of the data but also who develops, manages, and exercises legal control over the technology (European Parliament, 2020). We distinguish three dimensions.
Anyone who purchases cloud services from an international technology company is subject to the laws of the country where that company is based. U.S. legislation such as the CLOUD Act and FISA Section 702 gives U.S. authorities the power to compel companies to grant access to data they manage, regardless of where that data is located. Additionally, U.S. sanctions can force a provider to block access to systems and data. These are two different mechanisms with the same result. Control over the data lies outside the organization itself and outside Europe, even if the data is stored in Europe (Strop & Verlaan, 2024).
Modern digital services consist of chains of software layers, cloud platforms, and AI models. An application that appears European at first glance may, behind the scenes, depend on non-European infrastructure or components. Research into cloud-based contact center platforms, for example, shows that many European solutions run on international cloud infrastructure or use underlying technology developed outside Europe (ZipTone, 2025). This creates hidden dependencies in the infrastructure on which organizations rely.
Anyone who is dependent on a specific platform is also dependent on that platform’s pricing models, functionality, and contract terms. Switching to an alternative is often complex and costly, as systems become deeply intertwined with a specific cloud environment. This limits the organization’s flexibility and freedom of decision-making.
These factors make digital sovereignty a complex issue. In a global digital ecosystem, complete technological independence is often unattainable. Organizations therefore face a trade-off between, on the one hand, control over data, infrastructure, and technology, and, on the other hand, the benefits of scalability, innovation, and ease of use offered by international technology platforms.
Ultimately, the concept of digital sovereignty revolves around the question of to what extent organizations want and are able to maintain control over their digital infrastructure, and what dependencies they are willing to accept in exchange for access to innovative technology and scalable digital services.
Within the broad and sometimes abstract debate, Pegamento consciously opts for a pragmatic approach. We define digital sovereignty as the degree to which an organization actually has control over its data, infrastructure, and critical technology, and is able to manage dependencies in a conscious manner.
This vision is not about completely avoiding external technology. That is not realistic in today’s digital reality. Virtually every organization uses software, cloud platforms, or third-party components. The key lies in understanding and managing dependencies. An organization must know where these dependencies lie, what the risks are, and how much influence it still has over them.
We therefore view digital sovereignty as a spectrum. At one end are solutions where virtually everything is outsourced to large cloud providers and control lies largely outside the organization. At the other end are environments that run entirely under the organization’s own management, offering maximum control but also greater responsibility for management, security, and ongoing development.
Most organizations fall somewhere in between and make different choices for each system.
Figure 1. Digital sovereignty as a spectrum, with several recognizable positions. (available only in the PDF version)
To determine a position on this spectrum, we look at the three forms of control from Chapter 2: Which laws apply, and who can enforce or deny access to the data? What systems and dependencies lie beneath the surface of a solution, and who manages them? And to what extent can the organization itself steer, adapt, or switch when necessary?
This definition aligns with the practical realities in which organizations operate. It avoids an ideological debate about complete independence and allows for realistic choices. For each situation, it can be determined how much control is needed and where dependence on external parties is acceptable—for example, due to speed, innovation, or economies of scale. The key question thus shifts from whether an organization is fully sovereign to where it consciously wants to maintain control and where it does not.
The rise of the so-called sovereign cloud illustrates just how challenging this is in practice. In February 2026, Genesys announced that it would make its contact center platform available via the AWS European Sovereign Cloud, an environment specifically designed to meet European requirements regarding data residency and governance. The new region will be located in Brandenburg, Germany. Data is stored and processed within the EU, access is restricted to personnel within the EU, and the service complies with European regulations (Genesys, 2026; No Jitter, 2026).
At first glance, this appears to be a clear step toward sovereignty. However, this example shows that a sovereign cloud is not the same as full sovereignty. The underlying technology still comes from a U.S. hyperscaler. Control over the infrastructure layer and its ongoing development therefore remains outside the organization purchasing the service, and the companies involved remain part of a U.S. parent company. This also raises the question of how extraterritorial legislation affects these environments. The fact that suppliers are responding so emphatically to these concerns confirms that the risks remain part of the decision-making process.
Furthermore, there is a multi-layered dependency. Genesys Cloud runs on AWS infrastructure, which in turn is managed and further developed by Amazon. For the end user, this chain is rarely fully transparent, which means a solution can be marketed as “sovereign” while the underlying dependencies simply continue to exist.
Figure 2. The layered dependencies behind a hyperscaler’s “sovereign” cloud. (available only in the PDF version)
Sovereignty is therefore relative in the context of cloud usage. Vendors are taking steps to better align with European requirements, but the fundamental dependence on international technology platforms does not disappear. The question thus shifts from whether a solution is fully sovereign to whether it is sovereign enough for the specific application.
Software development involves a wide range of management tasks. Developers use tools that contribute to stability, development speed, data storage, backups, and application availability. Over the past few decades, this field has evolved from bare metal to virtualization, and subsequently, both the hardware and the virtualization layer itself have been outsourced.
Virtually everything has become a service—from infrastructure, platforms, networks, and databases to disaster recovery and serverless computing. Managing these types of solutions is easy to outsource, freeing organizations from having to deal with the underlying infrastructure.
That convenience has a downside. Anyone who entrusts business-critical systems entirely to a non-European provider runs the risk of losing access to data and intellectual property due to sanctions or other measures. This is not a hypothetical scenario. When the Amsterdam Trade Bank went bankrupt in 2022, Microsoft and Amazon shut down the bank’s cloud environments due to U.S. sanctions. The bankruptcy trustees could no longer access essential data. Only after an Amsterdam preliminary relief judge compelled Microsoft—under threat of penalties that could amount to as much as 100 million euros—did the data become available (Computable, 2022; Global Trade Review, 2022). The sanctions were aimed at the bank’s Russian owners, but regardless of one’s views on that target, the mechanism affected Dutch receivers and regulators, who were unable to carry out their legal duties.
The International Criminal Court in The Hague has shown that this can also affect organizations that have done nothing wrong. After the U.S. president imposed sanctions on Chief Prosecutor Karim Khan by executive order in February 2025, in response to arrest warrants issued by the court, Khan lost access to his Microsoft account and switched to a Swiss email service. Accounts of the exact circumstances vary, and Microsoft denies having suspended services to the court, but the lesson remains the same. A policy conflict with Washington was enough to strike at the core of an international institution based in the Netherlands. The court subsequently switched to openDesk, a European open-source alternative (Computer Weekly, 2025; Justice Info, 2025).
Just how relevant this mechanism is became clear once again in June 2026, this time in the context of AI. A few days after launching its latest models, Claude Fable 5 and Mythos 5, Anthropic received an export directive from the U.S. Department of Commerce. Because the company could not reliably determine users’ nationalities, it disabled the models worldwide. European organizations that had built their systems around these models found themselves without them overnight. In early July, the restrictions were lifted again, but that decision, too, was made in Washington. Anyone who has deeply integrated AI models from U.S. providers into their processes would therefore be wise to have an alternative or an exit strategy ready for such situations (VRT NWS, 2026; Techzine, 2026).
Our proprietary software, including our telephony platform and AI applications such as image recognition and transcription, must run in a cloud environment and be highly available. In setting this up, we made a number of choices. Some of those choices may have been more intuitive than deliberate at the time, but looking back, we’re happy with them.
The first choice was to use open source as the foundation. Our Phone System is built on Asterisk. We developed the entire front end—from the management application to the web softphone—ourselves on top of that open architecture. Asterisk was originally developed by an American company, but because the source code is open, we can manage and customize the software ourselves and, if necessary, continue operating it without the original vendor. Open source thus provides a level of control that is lacking in proprietary software.
The second choice is Dutch hosting. For hosting our solutions, we chose Uniserver, a Dutch cloud provider whose data centers are all located on Dutch territory. The environment runs at NorthC Amsterdam, Equinix AMS, and NorthC Almere, interconnected via dedicated dark fiber. Data remains in the Netherlands, is subject to the GDPR and NIS2, and is managed by people in the Netherlands. As a result, both legal and operational control are maintained locally. In addition, we wanted a partner who, in addition to hosting, also provides support and expertise in areas where we do not have all the necessary knowledge or capacity in-house.
Figure 3. The architecture of the Pegamento environment, from data center to application. (available only in the PDF version)
We are not alone in this. In April 2026, seven Dutch IT companies—namely Centric, Info Support, Intermax, KPN, Nebul, Previder, and Uniserver—presented a manifesto as the Open Cloud Alliance calling for a sovereign government cloud, supported by the DINL Foundation and TNO. Together, they represent twenty data centers, 13,500 employees, and approximately 6.5 billion euros in revenue (Open Cloud Alliance, 2026). These are not small players, and this is not a one-time marketing campaign, but a call to the government to align its procurement policy with sovereignty requirements. It is also telling that Atomic, Uniserver’s parent company, sold its public cloud subsidiary CloudNation to IG&H that same month so that, according to CEO Ronald Bezuur, it could focus entirely on sovereign cloud, data, and AI infrastructure for the Netherlands (IG&H, 2026).
This approach requires deliberate choices at the architectural level, and those choices require training and development of your own team. It’s understandable that organizations would rather purchase a service than take on the responsibility for managing, securing, and further developing the underlying infrastructure themselves. But it is indeed possible. It starts with understanding your own needs, your own infrastructure, and the services you use today. Based on that, you determine which software, data, or service to tackle first, and sovereignty becomes a key consideration in procurement policy and in collaboration with partners.
The question is not how far an organization should go in pursuing digital sovereignty, but for which components does dependence on external parties pose unacceptable risks. Not every application needs to be sovereign. A public website can likely run on a hyperscaler without major concerns. For business-critical data, email, and proprietary software, the assessment is different.
Start by conducting research and ask, for each system, what would happen if this data or system were no longer available tomorrow. Who would notice, and what damage would result? A contact center as a service might run perfectly well with a U.S.-based provider. But anyone with a legal obligation to remain accessible must know what alternative is available should a sanctions list render the service inaccessible, and what level of loss of functionality is acceptable in that scenario.
Composable architectures make it relatively easy to switch between services. With desktop applications like Word and Excel, the decision seems straightforward. If Word is no longer available, you simply switch to an alternative. However, these applications are part of an ecosystem, and anyone who loses access to that ecosystem also loses access to identities, permissions, and collaboration environments. The municipality of Groningen is working with the VNG to investigate whether the workplace can switch to Linux and other open-source software (Security.NL, 2026). The biggest challenge here likely lies not in technical feasibility, but in adoption within the organization. A transition is therefore not impossible, but it requires time, preparation, and a careful implementation process.
The same consideration applies to the documents themselves. You may want to store files containing critical information at a different location first. Should an SMB set up its own storage solution for this purpose, or should it opt for the convenience and integration offered by its existing application stack? Both choices are valid, as long as they are made deliberately and are reflected in the procurement policy and in agreements with partners.
The central question of this paper was to what extent organizations are willing to sacrifice the convenience and widespread technological adoption offered by big tech in favor of a truly sovereign solution. The honest answer is that most organizations are not yet willing to do so, as long as convenience, development speed, and availability remain the norm. That willingness will only grow when the risks become concrete, as in the cases of the Amsterdam Trade Bank and the International Criminal Court, or when legislation and procurement policies require it.
At the same time, this paper shows that the dichotomy is less absolute than it seems. Sovereignty is not an all-or-nothing choice but a spectrum, and there are choices to be made along that spectrum. A hyperscaler’s sovereign cloud pushes the boundary a little further, but leaves the fundamental dependency intact. Open source, Dutch hosting, and a growing ecosystem of reputable Dutch providers make it possible to organize local control for the systems that really matter, without giving up all the convenience.
Choosing between a European or Dutch alternative will sometimes be a difficult decision in the short term. In the long term, however, these choices will pay off. Knowledge will be retained, domestic industry can grow, and the organization will know who has access to its critical systems and who can shut them down. There are plenty of options, ranging from large to small. The question for every organization is which one it will tackle first.
Computable (2022). Court Orders Microsoft to Release ATB Data. computable.nl, May 4, 2022.
European Parliament, EPRS (2020). Digital sovereignty for Europe. Briefing PE 651.992.
IG&H (2026). IG&H Acquires CloudNation from Atomic Group. Press release, April 28, 2026.
Justice Info (2025). How sanctions can weaponize U.S. tech against the ICC. justiceinfo.net.
No Jitter (2026). Genesys to launch sovereign EU cloud. nojitter.com.
VRT NWS (2026). U.S. Forces Anthropic to Shut Down Its Best AI Models. vrt.be, June 13, 2026.
Business Consultant at Pegamento
Chief Information & Security Officer (CISO) at Pegamento
Deepen your knowledge with Pegamento’s white papers.