Multi-Cloud DR for Data Sovereignty

I plan recovery around approved data locations - not provider count. Before choosing a second cloud, I confirm where data, backups, keys, and support access are allowed. Then I set recovery targets and block failover to unapproved destinations.

My checklist comes down to four things:

• Approve the full data path. Check storage, replication, logs, remote access, and contracts - not just the database’s region.
• Choose a recovery design you can test. Compare backup and restore, pilot light, warm standby, and active-active against downtime, data loss, cost, and location limits.
• Control who can act. Assign recovery owners, restrict access, and document approval steps for failover and failback.
• Prove the plan works. Test outages, measure recovery time and data loss, and keep records of approvals, access, and cleanup.

A second provider is not proof of compliance. If no approved recovery site remains, I use a preapproved degraded mode or stop processing. An outage does not permit a prohibited transfer.

Multi-Cloud DR: Sovereignty-First Recovery Workflow

Set Requirements and Approve Recovery Regions

Document each workload’s sovereignty requirements before choosing recovery regions. Start with the approved allowlist, then create a workload-specific brief covering customer and data-subject jurisdictions, data classes, applicable laws, contractual limits, retention, legal holds, deletion rules, approved jurisdictions, and provider support-access terms. A U.S. hosting designation alone isn’t enough. Assign engineering, legal, privacy, and security owners to approve the requirements in writing.

Match Data Classes to Recovery Targets

Inventory every recoverable asset: databases, object/file storage, queues, logs, analytics extracts, ML datasets, snapshots, backups, keys, certificates, configuration, and service metadata. For each asset, record its owner, classification, origin jurisdiction, permitted locations, retention, deletion rules, legal-hold status, encryption, approved operators, and transfer limits. Review logs and metadata separately - don’t give them the primary database’s classification by default.

Use business-impact analysis to set each workload’s recovery time objective (RTO) and recovery point objective (RPO), with approval from business, engineering, legal, privacy, and security. Record maximum tolerable downtime and acceptable data loss separately from the proposed recovery design.

Map dependencies, too: identity services, DNS, networking, secrets management, queues, and external APIs. A restored database doesn’t mean a restored service if authentication or key systems are still unavailable.

Check Provider and Region Eligibility

Review each service’s location, jurisdiction, feature set, fault isolation, latency, key control, subprocessors, support access, logging, auditability, backup behavior, deletion guarantees, contractual commitments, and replication controls. Require approval from engineering, legal, privacy, and security.

Use the table below to screen candidate regions before committing to a recovery design. It describes an approval workflow, not legal permission.

Candidate	Status	Decision basis	Approval owners
Primary provider, same-country secondary region	Approved, subject to controls	Meets the organization’s country requirement only if backups, keys, metadata, support access, and subprocessors stay within approved boundaries	Engineering, legal, privacy, security
Second provider, same-country region	Conditional	May improve resilience to provider failure; service availability, contractual terms, support access, key management, and data-transfer paths must be validated	Engineering, legal, privacy, security
Approved neighboring-country region	Conditional	Allowed only when the data owner, legal team, customer contract, and applicable law permit processing in that country	Legal, privacy, data owner
Global or multi-region storage option	Conditional or prohibited	Requires proof of actual storage, processing, backup, and support locations; a “multi-region” label is not sufficient	Legal, privacy, security
Region outside the approved jurisdiction	Prohibited	Blocked unless legal, privacy, contractual, and regulatory review expressly authorizes the destination and the required transfer mechanism	Legal, privacy, data owner

Design replication and backup paths only after a region passes this screen.

Build a Data Sovereignty Control Matrix

Maintain one row per workload or data category, with links to evidence and approvers. This matrix is the working record that connects legal approval to exact regions, approved operators, and failover limits.

The example below applies only after workload-specific approval. These categories don’t set universal location rules. Record exact region identifiers in the operational version, set approval expiration dates, and reopen review when services, subprocessors, contracts, keys, or customer requirements change.

Data category	Primary / replica / backup	Key location	Approved operators	Failover action	Required approvals	Prohibited destinations; basis; review owner
Customer personal data	Approved U.S. region / Approved U.S. region / Approved U.S. region	U.S.-controlled KMS	Approved support personnel	Fail over only to listed U.S. region	Legal, privacy, security, engineering	Unlisted regions; customer contract; data owner
Regulated health data	Contract-approved region / Same approved jurisdiction / Encrypted backup in approved jurisdiction	Customer-controlled key	Authorized workforce only	Execute preapproved runbook; no automatic foreign failover	Privacy, security, compliance, legal	Outside approved jurisdiction; workload legal and contract review; compliance owner
Export-controlled technical data	Restricted approved region / Restricted approved region / Restricted approved region	Restricted key-management boundary	Authorized persons only	Manual approval before recovery	Legal/export compliance, security, engineering	Unapproved locations or access paths; export-control review; export-compliance owner
Operational logs and metadata	Approved region / Approved region / Approved region	Organization-controlled key	Limited operations team	Restore only to approved region	Security and privacy	Unreviewed telemetry destinations; classification and policy; security owner

Use the matrix to choose replication, backup, and failover locations, then carry those choices into the recovery topology and backup design.

Design Recovery, Replication, and Backups

Compare DR Topologies by RTO and RPO

Once regions are approved, choose a recovery pattern that stays within the approved jurisdiction. Use the approved recovery-region matrix to select a topology that meets RTO and RPO targets. The table offers guidance - not guarantees. Timed, end-to-end recovery tests establish actual RTO and RPO.

Check database engine and version compatibility, replication protocols, backup formats, latency, and recovery tooling across providers. Set the maximum replication lag. For active-active writes, define ownership and conflict-resolution rules.

Recovery needs more than application data. Include identity, DNS, networking, encryption keys, signed artifacts, and infrastructure configuration in the plan. Confirm that standby quotas, licenses, and capacity support production load. Budget for networking, transfer charges, duplicated controls, and testing. These choices set what the runbooks and tests must prove.

Control Replication and Backup Locations

Enforce approved destinations through deployment policies, then monitor configuration drift. Apply location rules to managed backups, snapshots, logs, traces, secrets, diagnostic exports, artifact registries, and infrastructure state. Provider defaults aren’t proof of policy compliance. Treat logs, traces, secrets, and artifact stores as separate assets subject to sovereignty controls.

Alert on changes to destinations, retention, and key policies. Keep immutable recovery copies within approved boundaries, and separate recovery credentials and key permissions from production. Test restoration in an isolated environment, and verify that keys remain available during a provider failure. Before setting immutable retention periods, have legal review retention, deletion, and legal holds.

Restrict Failover and Cross-Border Transfers

Before promotion, check the provider, region, account, and key location against the allowlist and require the documented approval gate. Disable writes on the former primary before enabling secondary writes. Use quorum or lease controls where appropriate; changing DNS alone doesn’t prevent split-brain writes.

At promotion, record the last replicated transaction and assess missing writes against the RPO. If no compliant site remains, use approved read-only mode, local queuing, or outage procedures - not failover to an unapproved site.

Before activation, review transfer grounds, provider terms, subprocessors, and remote administrative access with legal and security. Enforce restricted egress, least-privilege access, encryption, and transfer logs. Emergency conditions, encryption, and private connectivity do not authorize prohibited transfers.

Treat failback as a separate change. Control writes and reconcile duplicates and conflicts against the authoritative record. Track temporary snapshots, staging files, and recovery media through cleanup. Preserve audit evidence and approvals for any deletion exception.

Put these requirements into runbooks, with assigned owners, approval roles, and compliance tests that retain test evidence.

Assign DR Ownership and Test Compliance

Define Approval Roles and Recovery Runbooks

Put one recovery authority in charge, name deputies, and keep approver and operator roles separate. Map every role to the jurisdictions and data classes approved earlier.

Keep offline, read-only runbook copies in each approved recovery region. Give every step an owner, decision criteria, expected duration, and escalation path. Cover declaration, destination approval, traffic redirection, restoration, validation, communications, failback, and evidence collection.

Record authorization before regulated-data failover. Name the security authority who can stop an unapproved transfer. Internal exceptions cannot override legal prohibitions. These roles also control access to keys, backups, and transfer approvals.

Limit Remote Engineering Access

Map platform, DevOps, SRE, and remote software engineers to approved work jurisdictions. Set separate permissions for production records, backups, logs, and keys.

Require least-privilege access that is task-specific and time-bound. Use approved access paths, phishing-resistant MFA, session recording where appropriate, and immutable access logs.

Keep jurisdiction-specific on-call rosters with primary and backup responders. For each protected environment, ensure at least one authorized responder can approve or execute recovery actions.

A change in physical work location must trigger a review of access policies, support contracts, transfer assessments, and runbooks before access continues. Remote staffing must follow the same jurisdiction, access, logging, and on-call rules. Apply those access rules during recovery tests to confirm that only approved responders can execute failover.

Test Recovery and Keep Compliance Records

Test provider outages, network partitions, credential compromise, ransomware, and loss of an approved site. Measure detection-to-validation time against RTO and the latest recoverable timestamp against RPO.

Verify backup and dependency recovery, data and key locations, blocked transfers, telemetry boundaries, failback, and handling of temporary copies. Check that every successful recovery stayed within approved jurisdictions. Meeting the recovery deadline does not mean passing compliance: if restricted data reaches an unapproved jurisdiction, the recovery is still a compliance failure.

Retain approvals, configuration snapshots, timestamps, access logs, validation results, and cleanup evidence. Give each failure an owner, a deadline, and a retest. Reassess before material changes to providers, regions, services, subprocessors, legal requirements, or personnel access take effect.

Conclusion: Verify Recovery Sites and Data Flows

The matrix, topology, and runbooks are in place. Final approval now requires proof that they match live configurations. Approve recovery paths, not provider count. Sign off only when the approved region, topology, and recovery targets align with the data-class and jurisdiction matrix.

Before sign-off, check the data-flow map against live settings for replication, backups, logs, keys, telemetry, and remote access. Attach measured recovery results and approved failover/failback runbooks to the approval record. Engineering, legal, and security own this evidence.

No approved destination means no automatic failover. Before an outage, define the response: reject writes, run in an approved degraded mode, or suspend processing until a lawful destination is authorized. Name who approves legally permissible exceptions, who owns customer and regulator notifications, and who escalates for legal review. An outage never makes a prohibited transfer permissible.