When Sovereignty Becomes Optional: The New Dutch Cyber Regulation and the Solvinity Acquisition
On 10 November 2025, the Dutch Ministry of Infrastructure and Water Management published a new draft cyber security regulation. The timing could not have been more consequential. Only days earlier, Kyndryl, a United States based corporation, announced its intention to acquire Solvinity, one of the Netherlands’ key managed cloud providers, long positioned as delivering sovereign cloud services for government, justice, healthcare, and other regulated domains.
In a single week, two developments collided. One should have safeguarded sovereignty. The other undermined it. Combined, they expose a structural weakness in the Dutch cloud landscape: sovereignty is being treated as a marketing attribute rather than a legal, architectural, and operational reality.
This article examines how the proposed regulation fails to protect sovereignty and why the Solvinity acquisition makes these gaps urgent.
Key Takeaways
- The new Dutch cyber regulation strengthens operational security but does not address sovereignty.
- The Solvinity acquisition by Kyndryl places Dutch public workloads under potential United States jurisdiction.
- Compliance in the Netherlands is not equivalent to sovereign control.
- Organisations need jurisdiction-aware architectures, EU-only administrative control, and EU-based key custody.
- The regulation must be updated before finalisation to protect national autonomy.
The Solvinity acquisition: a case study in sovereignty by dilution
For years, Solvinity served Dutch ministries, municipalities, and security-sensitive organisations with cloud platforms explicitly marketed as private and sovereign. Many public entities selected Solvinity precisely because it was Dutch owned, Dutch operated, and under Dutch jurisdiction.
The acquisition by Kyndryl changes this foundational assumption. The infrastructure may remain in Dutch data centres, but the ultimate ownership transfers to a United States corporation. This creates a direct legal nexus to United States jurisdiction, including the CLOUD Act and other forms of extraterritorial access.
From a sovereignty perspective, the acquisition has three immediate consequences:
- Loss of exclusive Dutch jurisdiction
A foreign parent means potential exposure to foreign disclosure obligations, regardless of physical data location. - Compromised key custody and access governance
Even if encryption keys remain in the Netherlands, administrative access controlled by a United States owned entity can be compelled. - Increased systemic dependency
The Netherlands loses one of its most prominent domestically controlled cloud providers at a moment when public debate emphasises the need for European autonomy.
This acquisition is not an isolated event. It is a trend. Dutch and European providers continue to be absorbed by global hyperscalers or large United States based infrastructure companies. Each acquisition reduces national optionality.
Against this backdrop, strong national regulation should provide counterbalance. Instead, the draft regulation does not mention sovereignty at all.
The draft cyber regulation fails to address sovereignty
The regulation introduces several operational requirements, but none of the structural safeguards required to ensure sovereign control. There is a clear disconnect between the political narrative of sovereignty and the legal text that should support it.
Three foundational components are missing:
No definition of sovereignty
The regulation does not define data sovereignty, operational sovereignty, or jurisdictional sovereignty. As a result, public organisations cannot determine whether a cloud service is sovereign in a regulatory sense, even when the government itself demands sovereignty in policy statements.
No protection against foreign extraterritorial access
There is no reference to foreign legal risks, no prohibition of non-EU parent entities for critical workloads, and no requirement for EU-only administrative control.
No requirements for key custody or cloud locality
Backups may be stored in any cloud provider. Key management is not addressed. Administrator location is unspecified. These gaps would allow fully compliant organisations to host critical data in a legally non-sovereign environment.
With the Solvinity acquisition happening in the same week, the importance of these omissions becomes undeniable.
Operational security without jurisdictional control is an illusion
The regulation emphasises MFA, logging, patching, network segmentation, and vulnerability management. All of these are important. None of them provide sovereignty.
The absence of jurisdictional safeguards means:
- An organisation may protect its systems against attackers, but not against a foreign court order.
- It may encrypt its data, but the key custodian may be compelled to unlock it.
- It may deploy segmented networks while the global operator retains the legal right to access the control plane.
In other words, technical measures cannot compensate for structural weaknesses in jurisdiction and governance.
Sovereignty is not a technical configuration. Sovereignty is a legal and architectural posture.
The regulation’s critical omissions
No EU-only administrative access requirements
The regulation mandates strong privileged access controls, but does not require that administrators are located in the European Union or employed by an EU based entity. This is where sovereignty is either protected or lost.
No jurisdictional restrictions on cloud or backup providers
Backups must include cloud environments, but the regulation does not prescribe EU-only providers or restrictions on foreign ownership.
No key management or HSM governance
There is no mention of key custody, HSM locality, or split-key models. Without these, encryption becomes a procedural safeguard rather than a sovereign safeguard.
No supply chain governance
There are no SBOM requirements, no audit rights for sub processors, and no visibility into cloud operator ownership structures.
No clear CSIRT designation and incomplete incident governance
The regulation mentions powerful reporting obligations but leaves the national coordination structure partially undefined.
Each omission would already be concerning. Together, they create a regulatory blind spot that directly affects national autonomy.
The Dutch public sector is now exposed
The combination of:
- a United States corporation acquiring a key cloud operator
- a national regulation that does not address jurisdiction
- increasing cloud dependency in government
- a geopolitical environment where digital autonomy is strategic
creates a perfect storm.
Unless the regulation is strengthened, Dutch public institutions will operate critical workloads in environments where compliance is satisfied but sovereignty is compromised.
Compliance and sovereignty are not the same. Compliance can be outsourced. Sovereignty cannot.
What the regulation must include before finalisation
To ensure national autonomy, the regulation must incorporate:
- A legal definition of sovereignty
Including jurisdiction, location of control, and key ownership. - Restrictions on providers subject to non-EU extraterritorial laws
Or legally binding mitigations, verifiable in contracts. - EU-only administrative access and support
With traceable, immutable logging. - EU based key custody and HSM infrastructure
Including split-key or threshold encryption. - Mandatory supply chain transparency
SBOM, audit rights, sub processor disclosure, and exit rights. - A harmonised severity and notification model
Incident response must be consistent across all sectors. - Designation of the responsible CSIRT
With defined escalation channels for national coordination.
Without these elements, the regulation cannot deliver on its implied promise of strengthening Dutch cyber resilience.
Sovereignty is an architectural decision, not a procedural checkbox
The Solvinity acquisition demonstrates how quickly the sovereignty of Dutch cloud infrastructure can shift. The draft cyber regulation shows how easily sovereignty can be overlooked when the focus remains exclusively on operational controls.
The Netherlands does not need stronger passwords. It needs stronger jurisdictional guarantees.
Sovereign cloud architectures require a non-negotiable foundation: Dutch or EU jurisdiction, EU-only administrative control, EU-controlled encryption keys, and complete transparency in the supply chain.
Until the regulation reflects these principles, organisations will remain compliant, but not sovereign.
TechGourmet will publish an extended architectural guide on sovereign cloud patterns and Dutch regulatory alignment early in 2026, including patterns for hybrid models that maintain sovereignty even when commercial clouds are used.
Frequently Asked Questions
Is the Solvinity cloud still sovereign after the Kyndryl acquisition?
No. Even if the infrastructure remains in the Netherlands, the acquisition places Solvinity under a United States parent company. This creates exposure to United States extraterritorial laws such as the CLOUD Act. Physical location of data is not sufficient to guarantee sovereignty.
Does the new Dutch cyber regulation address CLOUD Act concerns?
No. The regulation does not address jurisdiction, ownership structures, administrator location, encryption key custody, or foreign legal access. It focuses on operational controls while leaving sovereignty unprotected.
What makes a cloud environment sovereign?
A sovereign cloud requires exclusive Dutch or EU jurisdiction, EU-based key custody, EU-only administrative access, complete transparency in the supply chain, and no exposure to non-EU extraterritorial legislation. Without these conditions, sovereignty cannot be guaranteed.