Chapter 4:

A maturity model for sovereign operations

Every organization operates somewhere along a spectrum of dependency and control. As recent industry analysis reported by Computer Weekly emphasizes, sovereignty is not a binary state; instead, experts advocate for a "Minimum Viable Sovereignty."

Many teams assume they are protected because they select a compliant cloud region or apply strong security tools. However, these actions do not resolve the central architectural dependency: if the database cannot operate without a vendor’s proprietary control plane, the organization has tenancy, not sovereignty.

The table below outlines the Sovereign Operations Maturity Model, enabling IT leaders to benchmark their current posture against regulatory requirements for portability and control.

Maturity Level
Architecture & Control Plane
Operational Characteristics
Primary Risks
Strategic Outcome
Level 1: Dependent
(The Consumer Model)
Proprietary DBaaS.
Workloads run on multi-tenant infrastructure using vendor-specific forks (e.g., Aurora, Atlas, Cloud SQL).
Control Plane: Vendor-managed and opaque.

Black Box Ops.

Patching and failover are invisible. Vendor holds root access. Backups are in proprietary formats.

Identity: Governed by provider IAM.

High Concentration Risk.
Single point of failure for pricing, licensing, or regional outages. Classified by MDPI research as the highest tier of "Technical Debt."

Convenience.

Rapid provisioning, but zero sovereignty. No viable exit path without re-architecting.

Level 2: Guardrailed
(The Configuration Model)

Regional DBaaS.

Data pinned to specific zones/regions. Private networking enabled.

Control Plane: Global vendor logic still manages local data.

Policy-Based Control.

Customer manages keys (BYOK), but provider retains access to memory/processes. Support relies on globally distributed teams

Compliance Perception Gap.

Apparent sovereignty without operational independence. Exposed to foreign jurisdictional access via the control plane.

Tenancy.

Meets basic residency checkboxes, but fails "Operational Sovereignty" standards.

Level 3: Sovereign
(The Operator Model)

Portable Automation.

Databases run on Kubernetes (Public, Private, or On-Prem) or standard compute using open source operators.

Control Plane: Customer-controlled automation.

Verifiable Control.

Access via customer SSO/OIDC only. Logs exported to customer SIEM. Jurisdiction-scoped support. Encryption is "Hold Your Own Key" (HYOK).

Operational Responsibility.

Requires higher internal skill sets for platform reliability and site reliability engineering (SRE).

Sovereignty.

Meets IDC’s definition of "Operational Sovereignty. Capability to evidence isolation to regulators.

Level 4: Autonomous
(The Resilient Model)

Fully Portable Stack.

Standards-based engines (upstream open source). Infrastructure agnostic.

Control Plane: Fully decoupled from the cloud provider.

Proven Continuity.

Exit procedures are documented and tested. Backups are restored to alternate infrastructure regularly.

None.

Strategic risk is minimized. Focus shifts to optimization rather than defensive engineering.

Resilience and Compliane.

Full immunity to supplier changes, price hikes, or geopolitical disruption.

Meets the "Mandatory Exit Strategy" standards of EU Data Act (Chapter VI) and DORA (Article 28).

Strategic Analysis: The Critical Leap from Level 2 to Level 3

Most enterprises in regulated sectors believe they have achieved sovereignty because data is stored in a compliant region or because encryption keys are managed by the customer. However, the operational and technological layers remain outside their control.

This creates a material gap between policy and practice. As noted in Forrester’s analysis of sovereign cloud markets, hyperscaler offerings often focus on "data residency" while maintaining a globalized control plane. This exposes the "operational" layer to foreign jurisdictions, creating a discrepancy between compliance policy and technical reality.

The transition from Level 2 to Level 3 marks a definitive turning point, transforming sovereignty from a passive configuration setting into an active architectural property.

  1. Evidence over assurance: The ability to prove who accesses the system via their own audit logs, verified by their own identity provider.
  2. Immunity to foreign access: The ability to restrict vendor access without stopping the database.
  3. Platform decoupling: The removal of proprietary dependencies (such as vendor-specific APIs or backup formats), which establishes the technical foundation required to eventually achieve the Level 4 "Mandatory Exit Strategy."
Previous Chapter
Next Chapter