This is a preview article from my upcoming book:
Digital Sovereignty in Europe - Architecture and Strategies for Technological Independence
In the public sector, sovereignty is a practical necessity. When governments depend on digital systems they do not control, they risk losing the ability to function, protect citizens, and maintain the rule of law. This chapter covers five connected areas: democratic accountability, continuity of services, data privacy, national security, and public procurement.
Democratic accountability
Democratic power comes with responsibility, and responsibility requires control. When a public organization hands control of critical IT systems to a foreign third party, accountability does not transfer with it. Ministers and elected officials remain responsible to parliament, the courts, and the public for how systems work, how data is handled, and anything that goes wrong.
A government can outsource the running of a system, but it cannot outsource the consequences if that system fails. If a cloud provider goes offline, if a foreign government forces a vendor to hand over data, or if a vendor simply stops offering a service, the political responsibility falls on the public institution. This means governments must maintain real operational and legal sovereignty over critical digital infrastructure – not just rights written into a contract.
The obligation to keep services running
Public sector organizations cannot pause or shut down services when things get difficult. Their duty to deliver services is written into law. Benefits must be paid, emergency services must respond, courts must operate, hospitals must treat patients, and public records must stay accessible.
Keeping services running is a legal requirement. A vendor outage, a contract dispute, a cyberattack, or a disruption caused by a foreign supplier can quickly become a political crisis. Citizens who cannot access services they are legally entitled to do not distinguish between a government IT failure and a government policy failure. To the public, they are the same thing. The reputational and political damage can be serious, and the level of acceptable risk is much lower than in any commercial setting.
Protecting privacy as a public duty
Public institutions hold large amounts of sensitive personal data, including tax records, health information, social benefit histories, immigration status, and court records. Strict laws govern how this data is handled – including national legislation and, across Europe, the General Data Protection Regulation (GDPR).
But beyond legal compliance, there is a deeper point. The public sector exists to serve and protect citizens, and that includes protecting their privacy. Sovereign control over data infrastructure is essential to this. When data is processed by foreign cloud providers or software vendors, governments may lose sight of where it is stored, who can access it, and under what conditions foreign authorities can compel its disclosure. Some countries have laws that allow their governments to access data held by their companies – regardless of where the servers are physically located.
Protecting defense secrets
For defense ministries and security agencies, sovereignty over data is extremely important. Military operations, intelligence reports, strategic plans, personnel files, and weapons data all need strong protection. They must be kept safe from spying, interception, and unauthorized access. If this data is exposed, people can die, alliances can be damaged, and a country can lose its advantage in a conflict.
This means the security standards must be very high. Defense systems need complete data separation: the infrastructure must run only within national or allied borders, controlled by trusted staff, and meet strict security classifications that commercial cloud services often cannot provide.
Using foreign technology creates serious risks. It can open the door to spying through hidden backdoors built into the technology, legal pressure on foreign companies to hand over data, or attacks on the supply chain.
This entry was posted on Thursday 09 July 2026
This is a preview article from my upcoming book:
Digital Sovereignty in Europe - Architecture and Strategies for Technological Independence
Digital sovereignty doesn't have a universally accepted definition. Therefore, this is the definition that is used in the context of my book:
Digital sovereignty is the ability of a state, organization, or individual to exercise meaningful control over digital infrastructure, data, platforms, and the rules that govern them. It is the right to decide who accesses data, under what conditions, and under whose laws.
It should be kept separate from a related but distinct concept: digital autonomy. Sovereignty means enforceable authority, usually backed by law and political power. Autonomy means the practical ability to act independently within digital environments.
For instance, a country can have digital sovereignty through legislation while depending entirely on foreign infrastructure to carry it out. Germany enforces strict data storage and privacy rules under the European GDPR, yet its cloud infrastructure runs largely on U.S.-based providers – specifically Amazon's AWS and Microsoft's Azure.
Sovereignty is about permission, where autonomy is about power. And you can have one without the other. For example: a hacker has no legal authority over anything, but is still capable of taking down a government website.
Sovereignty includes the principle of self-determination – the right of a people, institution, or individual to govern themselves according to their own values and interests. In IT systems, this produces specific requirements: where data is stored and processed, who may access it, and which technical standards are used for communication.
Technological self-determination isn't purely a technical problem, it is also a political one. When a government can't audit the algorithms executing its own laws, something has gone seriously wrong. When critical national infrastructure runs on servers that are subject to foreign jurisdiction, the country loses real independence. In both cases, political power quietly slips away.
This entry was posted on Thursday 09 July 2026
This is a preview article from my upcoming book:
Digital Sovereignty in Europe - Architecture and Strategies for Technological Independence
Digital sovereignty can be discussed based on a structured model (shown below) that captures the full scope of this complex topic in several building blocks.
The outermost building block defines the Sovereignty Context: the overarching environment in which all digital sovereignty decisions get made.
Laws and Regulations describe legislation relevant to sovereignty across Europe and U.S. and – in less detail – in other countries. Regulatory landscapes differ significantly by geography. For instance, rules about data residency in Europe bear little resemblance to those in force across Southeast Asia or the U.S.
The core of the model consists of the Sovereignty Building Blocks – seven foundational building blocks running from Hardware and Silicon up through AI. Together they form the technical pillars of a sovereign digital environment. These building blocks describe:
- Hardware and silicon form the physical foundation of digital sovereignty. Control over processors, open and trusted hardware, data centers, and the semiconductor supply chain determines whether critical digital infrastructure remains available, secure, and free from excessive dependence on foreign suppliers.
- Networking connects systems, users, and services across organizations and countries. Sovereignty at this layer depends on control over internet connectivity, routing, network services, and communication architectures.
- Compute and storage provide the infrastructure where applications run and data is processed. Sovereignty requires architectures that minimize vendor lock-in, support portability (containerization, infrastructure as code, portable cloud services), and ensure that critical workloads can continue operating regardless of changes in cloud providers or political circumstances.
- Identity and access determine who can use systems and what they are allowed to do. Every digital service needs to verify who users are and what they are allowed to do. To stay secure and independent, organizations must keep control over their identity systems. This means using open standards, connecting systems through federation, and carefully managing privileged access.
- Software provides the functionality that organizations rely on every day. Software sovereignty focuses on reducing dependency on proprietary ecosystems through open standards, open-source software where appropriate, secure software supply chains.
- Data is often an organization's most valuable digital asset. Data sovereignty is about maintaining control over where data is stored, how it is classified and protected (for instance using encryption), who can access it, and under which legal jurisdiction it is processed throughout its lifecycle.
- Artificial intelligence sits at the top of the sovereignty stack because it depends on every underlying building block. AI sovereignty involves controlling models, training data, AI-specific compute resources, and deployment choices so that organizations can benefit from AI while remaining compliant, transparent, and strategically independent.
Running alongside them is the Implementation building block, which reflects a straightforward but important point: digital sovereignty isn't just a concept. It has to be actively designed, built, and maintained.
This entry was posted on Tuesday 30 June 2026
Documenting an IT infrastructure is essential to maintaining a reliable, secure and effective IT environment. Without proper documentation, valuable knowledge about the IT infrastructure can be lost when systems managers leave the organization. Documenting preserves this knowledge and allows it to be transferred to new team members.
Documentation shows how an infrastructure is configured and how it is supposed to work, which helps with troubleshooting and maintenance tasks. And in the event of a disaster, documentation helps ensuring that the infrastructure can be restored to its previous state as quickly as possiible.
CMDB
The most basic form of documentation is having an inventory of all hardware, software, and networking components in the infrastructure. Often this inventory is stored in a Configuration Management Database (CMDB).
A CMDB should include the make and model of each component, as well as its location and function. Many CMDB tools provide the ability to correlate components, such as all the components needed to run an application. This can be very helpful when making changes or finding the root cause of an application failure.
Since the CMDB is needed as a basis for ITIL processes, it should be kept up to date as much as possible, using automated tools if possible.
Diagrams
A visual representation of the infrastructure can help a lot in understanding its topology. A topology diagram shows the relationships between different components and how they are connected.
There is no widely accepted formal standard for documenting IT infrastructures. Often Microsoft Visio or Diagrams.net diagrams are used to provide an overview of parts of the infrastructure, usually the network configuration and groups of servers. Although these diagrams necessarily omit many details, they can provide a general overview of the entire environment in one view.
Tools such as Visio and Diagrams.net provide a comprehensive set of templates for infrastructure components, including servers, routers, firewalls, and components of public cloud environments.
The Enterprise Architecture modeling language ArchiMate includes a technical layer that can also be used to document infrastructures. ArchiMate is not an optimal way to document infrastructure, as it is designed to capture high-level concepts and relationships, rather than the detailed technical specifications that are important for documenting IT infrastructures. Also, ArchiMate is a complex modeling language that takes a lot of time and effort to learn and use effectively.
Please remember that pictures should always be explained to prevent readers from interpreting them themselves. Therefore, it is best to include the pictures in a document or (preferably) and set of wiki web pages in which the pictures are explained step by step. And it is important that this documentation, including the explanations, be updated with every change in the infrastructure.
IaC tools
Automation tools, such as IaC and configuration management tools can be used as a way to document how the infrastructure is built and the reason behind certain decisions. An important advantage of this method of documentation is that it can be done during modifications to the IaC code. For any future changes, the documentation in the code can easily be updated immediately.
A disadvantage is that the code must be read to get an understanding of the architecture of the infrastructure. It does not provide you with an instant overview of the setup, like diagrams do.
Below is an example of documentation in a Terraform code snippet.
############################################################
# This VM is needed to run the web server
############################################################
Resource "azurerm_windows_virtual_machine" "example" {
name = "myvm1"
location = "northeurope"
resource_group_name = "MyRG"
network_interface_ids = [ azurerm_network_interface.myvm 1 nic.id ]
size = "Standard_B1s"
admin_username = "adminuser"
admin_password = "Password123!"
############################################################
# The server must run the Windows Datacenter version
# to ensure it is compatible with the application libraries
############################################################
source_image_reference {
publisher = "MicrosoftWindowsServer"
offer = "WindowsServer"
sku = "2019-Datacenter"
version = "latest"
}
os_disk {
caching = "ReadWrite"
storage_account_type = "Standard_LRS"
}
}
Documenting procedures
At a minimum, written procedural documentation should include:
- Procedures for routine tasks, such as software updates
- An Infrastructure naming convention that describes how infrastructure components should be named
- An IP addressing plan that shows how IP addresses are distributed to devices based on the network architecture.
- A DNS naming convention that describes how DNS records should be named in the various network segments, such as internal DTAP segments and the DMZ.
- A fallback procedure that describes how to perform a fallback of the infrastructure to the secondary datacenter.
- A disaster recovery plan.
- Backup and recovery procedures.
Documentation should be updated regularly as changes are made to the infrastructure.
This entry was posted on Tuesday 16 December 2025
IT FinOps, also known as Financial Operations for IT, focuses on managing and optimizing the financial aspects of IT operations. The goal of IT FinOps is to maximize the value of IT investments and reduce unnecessary costs.
IT FinOps teams monitor costs, analyze usage patterns, identify inefficiencies and implement cost-saving measures. An IT FinOps team works with other disciplines such as finance, procurement, and operations to ensure that all IT spending is accounted for and optimized.
IT FinOps becomes even more important when moving to the public cloud, which can introduce complex cost structures. In a cloud environment, pay-as-you-go is the standard. However, most cloud providers also offer discounts if a certain number of resources are reserved in advance for an extended period of time. The types of charges can vary widely. For example, for a VM, you pay per second the VM is up; for a network connection, you pay for the number of bytes sent and received; and for storage, you pay for the amount of storage, the storage tier, and the number of reads and writes.
This entry was posted on Thursday 27 November 2025
Dutch
