Data Residency & Control

Enforcing where government data resides, how it is accessed, and how it moves

For governments and public sector organizations, data residency is not a preference — it is a legal, regulatory, and constitutional requirement.

A sovereign government cloud must ensure that data location, access paths, and data movement are explicitly defined, technically enforced, and auditable.

This page describes how data residency and control are implemented in a government cloud built on whitesky.

Data residency as an architectural property

In a sovereign cloud, data residency cannot rely on policy statements or contractual assurances alone.

It must be enforced through:

  • infrastructure placement
  • network boundaries
  • platform controls
  • operational procedures

whitesky is designed so that data residency is a result of architecture, not convention.

Explicit definition of data location

Government data must have a clearly defined physical and legal location.

With whitesky:

  • data is stored only in approved cloud locations
  • cloud locations correspond to specific datacenters or facilities
  • each location operates under a defined jurisdiction
  • placement rules are explicit and reviewable

This allows governments to map data directly to jurisdictional and regulatory boundaries.

Controlled data access paths

Residency is meaningless without access control.

In a sovereign cloud:

  • access to data is governed by identity and role
  • administrative access is restricted and auditable
  • data access paths are explicitly defined
  • indirect or implicit access routes are avoided

whitesky supports identity-driven access models aligned with public sector governance structures.

Controlled access paths to government dataUsers reach government data in an approved location only through identity and role; administrators only through restricted, audited access. Indirect or implicit access routes are avoided. Every administrative access is logged and auditable.Paths to data in an approved locationGovernmentdataapprovedlocation onlyUsersIdentity and roleAdministratorsRestricted, auditedIndirect routeavoidedEvery administrative access is logged and auditable
Controlled access paths to government dataUsers reach government data in an approved location only through identity and role; administrators only through restricted, audited access. Indirect or implicit access routes are avoided. Every administrative access is logged and auditable.Paths to data in an approved locationUsersIdentity and role✓AdministratorsRestricted, audited✓Indirect routeavoidedEvery administrative accessis logged and auditable
Data is reached only through defined, identity-driven paths; administrative access is restricted and logged, and implicit routes are avoided.

Prevention of uncontrolled data movement

Uncontrolled data replication and transfer undermine sovereignty.

whitesky enables governments to:

  • define where data may be replicated
  • restrict cross-location data movement
  • prevent automatic cross-border synchronization
  • require explicit approval for data transfers

This applies to:

  • virtual machine storage
  • object storage
  • backups and snapshots

Data movement becomes a governed action, not a side effect.

Residency across storage and compute layers

Data residency must be consistent across all layers of the platform.

whitesky enforces residency across:

  • block storage
  • object storage
  • virtual machine disks
  • container workloads

Compute workloads are placed close to data to avoid unnecessary data movement.

Data residency in hybrid and multi-location environments

Government environments often span multiple locations.

In hybrid or multi-location deployments:

  • each cloud location enforces its own residency boundary
  • inter-location connectivity is policy-controlled
  • data replication between locations is explicit and auditable
  • workloads can be constrained to specific locations

This enables federated government architectures without compromising data control.

Residency boundaries per cloud locationTwo cloud locations, each under its own jurisdiction and residency boundary, covering compute placed close to the data, block storage, object storage, VM disks, container workloads, and backups and snapshots. Between the locations, an explicit, approved and logged transfer is allowed, while automatic cross-border synchronization is blocked.Cloud location Ajurisdiction ACompute, close to dataBlock storageObject storageVM disksContainer workloadsBackups and snapshotsCloud location Bjurisdiction BCompute, close to dataBlock storageObject storageVM disksContainer workloadsBackups and snapshots✓ explicit transferapproved, loggedautomatic syncblockedPlacement and every data movement are traceable for audit
Residency boundaries per cloud locationTwo cloud locations, each under its own jurisdiction and residency boundary, covering compute placed close to the data, block storage, object storage, VM disks, container workloads, and backups and snapshots. Between the locations, an explicit, approved and logged transfer is allowed, while automatic cross-border synchronization is blocked.Cloud location Ajurisdiction ACompute, close to dataBlock storageObject storageVM disksContainer workloadsBackups and snapshotsCloud location Bjurisdiction BCompute, close to dataBlock storageObject storageVM disksContainer workloadsBackups and snapshots✓ explicittransfer,approved,loggedautomaticsyncblockedPlacement and every data movementis traceable for audit
Each cloud location enforces its own residency boundary across all storage and compute layers; data leaves it only as an explicit, approved and logged transfer.

Operational enforcement and auditability

Residency controls must be verifiable.

whitesky supports:

  • logging of administrative actions
  • traceability of data placement and movement
  • operational transparency for audit and oversight
  • alignment with public sector reporting requirements

This allows internal audit teams and regulators to validate compliance.

Relationship to data protection and regulation

Data residency and control underpin compliance with:

  • national data protection laws
  • sector-specific regulations
  • public sector security frameworks
  • contractual and inter-agency obligations

The platform enables governments to implement these requirements through technical controls rather than procedural workarounds.

Relationship to other sovereign cloud topics

This page builds on the Sovereign Cloud Foundations and connects directly to:

Together, these define a coherent sovereign cloud architecture.

Next steps

  • Identify data classifications and jurisdictional constraints
  • Define approved cloud locations and access models
  • Map residency requirements to technical controls
  • Validate enforcement through audit and testing