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.

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:

1. A legal definition of sovereignty
   Including jurisdiction, location of control, and key ownership.
2. Restrictions on providers subject to non-EU extraterritorial laws
   Or legally binding mitigations, verifiable in contracts.
3. EU-only administrative access and support
   With traceable, immutable logging.
4. EU based key custody and HSM infrastructure
   Including split-key or threshold encryption.
5. Mandatory supply chain transparency
   SBOM, audit rights, sub processor disclosure, and exit rights.
6. A harmonised severity and notification model
   Incident response must be consistent across all sectors.
7. 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.

Update 24 October 2025:
AWS has published its Root Cause Explanation (RCE) for the October outage. The disruption was traced to a race condition in DynamoDB’s DNS automation that created an empty Route 53 entry, confirming that resilience starts with architecture, not SLAs.
Scroll to the end of this article for TechGourmet’s full analysis of the RCE and what it means for cloud architects.

On 20 October 2025, parts of the internet went dark.

An outage in Amazon Web Services (AWS) — specifically in the US-EAST-1 region, one of its largest and most interconnected data center regions — caused widespread errors and latency across multiple services, including Amazon DynamoDB.

Within minutes, global platforms like Slack, Zoom, Canva, Xero, and even government portals such as HMRC (UK) began showing signs of disruption.

Millions of businesses across Europe and the Netherlands noticed it immediately: chats stalled, meetings froze, and dashboards went blank.

This was not a cyberattack or a global power failure — it was a single-provider dependency unfolding in real time.

The Hidden Single Point of Failure

Public clouds are often seen as the ultimate solution for resilience. But resilience isn’t automatically inherited from the provider — it must be designed by the customer.

When a region like US-EAST-1 experiences issues, the impact isn’t limited to that geography. Many global applications route authentication, data, or logging through that region by default.

In this case, the failure of DynamoDB, AWS’s NoSQL database, triggered cascading errors across multiple dependent services.

From a business perspective, the outage illustrates a recurring theme:

Cloud dependency can easily become cloud fragility when risk is not actively managed.

Even organizations that think they are multi-region or multi-zone may still rely on control planes or managed services concentrated in one location.

Five Architectural Paths, and Their Trade-offs

No architecture is risk-free. But every architecture makes a choice about where risk lives.

Each model comes with trade-offs, not just in cost, but in governance, compliance, and recovery maturity.

That’s why a risk-based cloud strategy is essential.

Designing for Risk: From Dependency to Resilience

Moving to (or scaling within) the cloud should start with a risk assessment, not a migration plan.

A few guiding questions can make all the difference:

• Impact: What happens to our business if this workload becomes unavailable for 2 hours?
• Dependency: Which managed services (e.g., DynamoDB, S3, Lambda) are single points of failure?
• Sovereignty: Where is data physically stored and what are our legal obligations under GDPR or NIS2?
• Recovery: What are our RTO (Recovery Time Objective) and RPO (Recovery Point Objective) targets?
• Detection: Are our observability tools distributed, or do they fail with the same provider?

True resilience means expecting failure and designing pathways around it.

It’s not just about backup. It’s about continuity of service under degraded conditions.

From Awareness to Action: Build, Design, and Plan for Resilience

The AWS outage reminded everyone that reliability is never absolute — it’s engineered.

Building true resilience means moving beyond reactionary incident response and embedding risk thinking into every stage of design.

Here are the three core principles that every organization should apply to cloud architecture, regardless of scale or provider:

1. Build for Failure

Assume that components, zones, and even providers will fail.

Design systems so that a single point of failure. Whether it’s a DNS resolver, a managed service, or a region that fails, it should not take down your business.

• Distribute workloads across availability zones and regions.
• Use redundant DNS, storage, and message queues.
• Implement graceful degradation, your system should bend, not break.
• Test failure scenarios regularly (chaos engineering, simulated outages).

Building for failure isn’t pessimism, it’s maturity.

2. Design for Recovery

Outages happen. The differentiator is how fast and how completely you can recover.

Recovery design means understanding both technical restoration and service continuity:

• Automate redeployment and data restoration via Infrastructure-as-Code.
• Predefine Recovery Time Objectives (RTO), Recovery Point Objectives (RPO) for each workload and for the stack as a whole
• Validate identity, observability, and automation pipelines — they are often dependencies for recovery.
• Ensure customers experience gradual degradation rather than sudden loss of service.

The goal is not just uptime, it’s recoverable capability.

3. Plan for Disruption

Not every disruption is technical.

A comprehensive Business Continuity Plan (BCP) connects the dots between technical recovery and organizational response.

• Define clear communication playbooks for customers and partners.
• Map critical business processes to their supporting IT services.
• Include cloud service dependencies in continuity testing.
• Align with ISO 22301 and NIS2 continuity requirements for operational resilience.

Disruption planning ensures that your organization continues to operate, even when your cloud doesn’t.

Moving Forward: Cloud Maturity Through Risk Awareness

Cloud computing remains transformative.

But the responsibility for resilience sits with the architecture, not within the provider SLA.

Organizations adopting or expanding their infrastructure, private cloud and/or public cloud usage should:

• Establish cloud governance frameworks based on risk categories.
• Implement multi-region or hybrid patterns for critical workloads.
• Use observability platforms that monitor dependencies across providers.
• Regularly test failover and incident response playbooks.
• Align architectures with ISO 27001, SOC2, and NIS2 resilience requirements.

Conclusion

The AWS outage wasn’t an anomaly — it was a reminder.

Cloud enables agility, scalability, and innovation, but true reliability must be engineered.

As architects and business leaders, we should ask ourselves with every new deployment:

“If this fails — how do we continue to serve our customers?”

The answer defines not only your architecture, but your business resilience.

Update – AWS Root Cause Explanation (RCE)

Four days after the outage, AWS released its official Root Cause Explanation (RCE) for the N. Virginia (us-east-1) disruption.
It confirms that the event was not a generic DNS issue but a latent race condition inside DynamoDB’s automated DNS management system.

What Actually Happened

Two independent DNS Enactors were updating Route 53 plans for dynamodb.us-east-1.amazonaws.com.

One was delayed, still applying an older plan; another had already applied a newer one and started cleanup.

Because of timing delays, the old plan overwrote the new plan just before cleanup removed it, leaving the Route 53 entry empty (no A/AAAA records).

Automation stalled in an inconsistent state and required manual recovery.

This single defect cascaded through AWS’s control and data planes:

• Internal services relying on DynamoDB stalled
• EC2 instance management (DWFM) leases expired, blocking new launches
• Network Manager lagged propagating network state
• NLB health checks flapped and removed healthy nodes
• Lambda, STS/IAM, and other dependent services throttled or degraded

The combined effect lasted roughly 14 hours before full recovery.

What It Teaches Us

his RCE reinforces our core message: cloud reliability is an architectural responsibility, not a provider guarantee.

Even highly redundant automation can become a single point of failure.

Implications for Architects

• Re-evaluate dependency mapping: identify internal or SaaS services that rely on AWS control-plane APIs or managed DNS.
• Test partial impairments: simulate endpoint-resolution failures and observe retry/back-off behaviour.
• Include control-plane failures in DR exercises: ensure scaling, IAM, and provisioning can degrade gracefully.
• Review DNS TTLs and caches: make sure propagation delays don’t extend outage windows.

Build · Design · Plan is still the Foundation

1. Build for Failure – design for automation faults and redundant resolution paths.
2. Design for Recovery – automate fallback to replicas or read-only modes.
3. Plan for Disruption – integrate SaaS and control-plane dependencies into your BCP.
   

Further Reading

• AWS RCE: Summary of the Amazon DynamoDB Service Disruption in us-east-1
• Yan Cui’s analysis on LinkedIn

TechGourmet continues to monitor and document major cloud incidents to translate lessons into practical architecture guidance for European enterprises.

Ready to strengthen your cloud resilience?

TechGourmet helps organizations design hybrid and multi-cloud architectures built for failure, recovery, and continuity.
Let’s assess your current cloud risks and translate them into actionable architecture improvements.

Get in touch to schedule a Cloud Resilience Assessment