Data and system sovereignty is a concept that has come to the fore recently, as a response to various emerging challenges as well as government and regulator requirements.
From a data perspective, there are several questions that need to be answered. Where exactly does sensitive data reside and who can operate the underlying system? Alongside this, can the organization continue functioning around its data if a region, provider, or control plane becomes unavailable?
Each organization will have its own set of answers to those questions, based on technical and business decisions made months or years in the past. Today, organizations have to balance the systems that are already in place and the need to make them more resilient with the approach to sovereignty and the requirement to have more control over infrastructure in order to reduce risk.
Sovereignty is a nebulous concept that can mean different things to different people. Key areas include:
- Data sovereignty covers how an organization controls where its data exists and is located, as well as how and where it gets backed up and encrypted. Most importantly, organizations have to prove that they are following their own rules
- Operational sovereignty defines who can access and operate organizational systems. This covers internal teams and should not rely on any third party or external support to work effectively.
- Technological sovereignty covers how the organization runs and uses workloads on alternative infrastructure. The key requirement here is that the organization should be able to run without vendor-specific APIs, formats, or control planes.
With those three different elements in mind, organizational leaders can then examine where the organization is in terms of dependency on external suppliers. This is particularly important for organizations that have made a big shift over to public cloud for their infrastructure already.
Many enterprises today use public cloud because it is fast and convenient. However, these organizations then become dependent on their external cloud providers. From an architecture perspective, these services use multi-tenant designs so the cloud provider can stack up multiple workloads concurrently while still keeping them isolated. This keeps customer data separate, but workloads will tend to run on vendor-specific forks of open source projects.
On the operational side, updates and patching will be carried out on the vendor’s timescales, and the management tools will tend to be owned and operated by the supplier. This approach is effective, but it is at the most risk from a sovereignty perspective. It also needs the most work if an organization does decide to move away. Often, there is no viable exit path without a substantial application rewrite.
Other enterprises will have more control over their deployment. While they use public cloud, they have led the design and implementation phases. For example, they may use virtual private cloud instances to run their own location on the provider’s cloud, while operationally they provide the encryption keys for the service. These decisions provide the appearance of sovereignty from a residency perspective, but they can fail due to issues around operational compliance in practice. For example, if the vendor can still access the control plane used to run the cloud, then they can effectively access the whole environment.
For sovereign deployments, using open source for infrastructure and for workloads provides more control. Kubernetes, for example, can run across multiple locations including public, private, and hybrid cloud, as well as on more traditional on-premises data centre hardware. The customer has to operate the control plane and access control as well. This requires a more skilled internal team to manage platforms and ensure reliable operations, but it also meets operational sovereignty requirements.
To take this one step further, organizations can look at how to use open source and standards-based components alongside Kubernetes to be fully agnostic on infrastructure. In essence, this provides the ability to run any workload, anywhere that is suitable to host it. Alongside this flexibility, organizations still have to validate that data resilience processes work effectively and independently. For example, will data backups work on the open source stack that has been cultivated, even when it is deployed in a different environment or location? Being able to restore to a different provider that meets the same sovereignty requirements keeps the organization independent on a personnel level, not just a technical one.
The main reason for this independence is that the organization can then meet the requirements that exist around the ‘Mandatory Exit Strategy’ standards present in the European Union’s Data Act, Chapter VI around switching providers and in Article 28 of the Digital Operational Resilience Act (DORA), on avoiding potential disruption to business activities.
Proving the point on sovereignty
It is not enough to design systems that appear to meet sovereignty requirements; instead, organizations have to prove that those processes work effectively over time. For example, the ability to prove who can access a system relies on running a set of audit logs and verifications around identity.
Taking this further, organizations may also want to remove any kind of vendor-specific API as part of the data management process. The European Central Bank (ECB) explicitly identifies the inability to substitute different solutions as a critical risk to resilience. In practice, backup approaches have to work with alternative infrastructure and without significant re-engineering to meet regulatory requirements around ‘functional equivalence’.
Evidence will be needed to confirm that the approach taken works. Documents like restore-from-backup validation and Software Bill of Materials verification (SBOM) can demonstrate that processes work based on a specific set of software components. For an SBOM, this can show that an organization only uses open source software rather than specific vendor or provider versions.
Building the route to resilience and sovereignty
Organizations do not need to move all their data in order to build a sovereign and resilient approach. The starting point is assessing what is in place and what the organization depends on. Once this is in place, an evidence-based approach can be taken to focus on what risk actually exists, how to reduce the potential impact, and then considering what is needed next.
For those responsible for decisions around data and sovereignty, the path ahead involves working with their organization around risk. Reducing reliance on third-party companies and using open source software is an effective approach to retaining control over how the organization hosts its data.
The author
Laura Czajkowski is Head of Community at Percona, an open source database company that supports thousands of organizations worldwide. Her work involves collaborating with open source communities on data, applications and deployment to share knowledge and insight.
