Chapter 3:

The three pillars of sovereign operational resilience

True operational resilience depends on control. It is not achieved by selecting a sovereign region or adding perimeter controls around a proprietary service. It stems from a design that enables the organization to demonstrate where data resides, who can operate the system, and how it will continue to run if a supplier or jurisdiction changes.

The Sovereign Resilience Framework expresses this control through three outcomes:

  • Data sovereignty
  • Operational sovereignty
  • Technological sovereignty

As detailed in Forrester’s 2024 analysis of digital sovereignty trends, the industry has moved toward this three-pillar model encompassing data, operational, and technical control to mitigate geopolitical risk. Each pillar addresses a different dimension of risk, but they reinforce one another. Together, they define whether a database platform can meet modern expectations for security, compliance, and continuity under stress.

Data sovereignty: The “where”

Data sovereignty means the organization controls residency, backup targets, and encryption boundaries, and can evidence these controls. In practice, this goes beyond choosing a cloud region. Sovereignty requires that primary data, replicas, and backups are all pinned to jurisdictions that align with regulatory and contractual obligations, and that this placement can be evidenced rather than assumed.

A sovereign design for data must:

  • Pin storage and backups to defined regions through technical controls, not only through policy.
  • Constrain cross-border data movement for replicas, backups, analytics, and AI pipelines.
  • Ensure encryption keys are governed under the appropriate jurisdiction, particularly for workloads in regulated sectors.
  • Provide clear visibility into where data is stored and where it travels during normal operations and recovery.

Region selection alone is not sufficient if automated snapshots, telemetry, or support processes can move data or metadata outside approved boundaries. Legal analyses regarding the US CLOUD Act highlight that data stored by US-based providers is subject to US warrant requests regardless of physical location. As detailed in recent risk assessments (Gislen, 2024), without customer-managed encryption and strict technical pinning, "data residency" offers little legal protection against extraterritorial reach.

Assessment criteria: Data sovereignty

  • Can we produce a current map of all primary storage, replicas, and backup targets, aligned to specific jurisdictions and providers?
  • Can we show that no automated process moves production data or backups outside those jurisdictions without a documented and approved reason?

If the answer to either question is uncertain, data sovereignty is not yet achieved.

Operational sovereignty: The “who”

Operational sovereignty means the organization defines and evidences who can operate, access, and support the system, without relying on provider-controlled vendor pathways or global support models. It extends beyond residency to address reach-through access. A database that resides in a compliant region can still violate sovereignty expectations if privileged operations are performed by personnel in another jurisdiction or through vendor pathways that bypass customer controls.

A sovereign operational model must provide:

  • A clear “who can touch what” roster that lists named individuals and their corresponding roles with access, organized by jurisdiction.
  • Access control is enforced through customer-managed identity systems, such as SSO and OIDC, with role-based access control applied at the database and platform level.
  • Support models that respect jurisdictional boundaries, so that critical incidents do not automatically route to global “follow the sun” teams with unrestricted access.
  • Comprehensive audit logs for administrative, configuration, and support actions, exported to customer-governed SIEM or logging platforms.

In this model, neither a cloud provider nor a software vendor holds a master key or uncontrolled operational pathway into the environment.

Assessment criteria: Operational sovereignty

  • Can we provide an auditor with a current roster of individuals who can administer or support this system, along with their respective jurisdictions and roles?
  • Can we disable all vendor access without impacting our ability to operate or recover the system?

If either answer is “no” or depends on a vendor’s internal controls, operational sovereignty has not yet been achieved.

Technological sovereignty: The “how”

Technological sovereignty means the organization can restore and run workloads on alternative infrastructure without vendor-specific APIs, formats, or control planes. It addresses concentration and continuity risk. A platform that requires proprietary APIs, storage engines, or control planes to operate creates a one-way dependency.

The risks of this dependency were starkly illustrated by the massive US-EAST-1 outages, which froze operations for companies relying on centralized control planes. As noted by Bank Info Security, such events expose the fragility of "single-basket" cloud strategies. This is at odds with regulatory expectations that critical services should remain available if a third-party provider fails or changes terms.

Technological sovereignty requires that:

  • Core databases use open, standard engines rather than proprietary forks that only exist on a single cloud.
  • Automation for provisioning, upgrades, backups, and failover runs on infrastructure that the organization controls and can redeploy elsewhere.
  • Backups are stored in portable formats, on storage the organization governs, and can be restored to neutral environments.
  • Clear and tested exit procedures exist for critical workloads, including how to restore from backups on alternate infrastructure.

These conditions prevent licensing changes, pricing decisions, or control plane outages from becoming single points of failure. The industry is acutely aware of this tension. According to the Flexera 2024 State of the Cloud Report, 'cloud vendor lock-in' remains a top concern for enterprise IT leaders. This anxiety is driving a strategic shift; Forrester’s Predictions 2025 forecasts that users will increasingly seek sovereignty and security for sensitive workloads, moving toward portable stacks to insulate themselves from vendor concentration.

Assessment criteria: Technological sovereignty

  • If our primary cloud provider were to become unavailable or increase prices for database services, could we restore this workload to another environment using our current backups and automation?
  • Have we performed this restoration in a controlled exercise and documented the process and duration?

If the answer depends on a proprietary platform feature or an untested migration plan, technological sovereignty is still aspirational rather than proven.

How the pillars work together

The three pillars address different classes of risk:

  • Data sovereignty reduces legal and regulatory exposure by constraining where data can exist and how it moves.
  • Operational sovereignty reduces access and process risk by ensuring the organization defines and evidences who can operate the system.
  • Technological sovereignty reduces business continuity and concentration risk by ensuring there is always a viable path to continue operating on alternative infrastructure.

Organizations that address all three pillars gain a resilient foundation for compliance, security, and continuity. Those that address only data residency, while leaving operational and technological control with external vendors, remain exposed even if they appear compliant on paper.

Previous Chapter
Next Chapter