Residency & Sovereignty Checklist
Translate legal, contractual, operational, and technological control requirements into workload-placement questions.
Start with the actual decision
Residency, privacy, and sovereignty are related but not interchangeable. Data location, operator control, legal jurisdiction, network dependence, cryptographic control, and technology portability may lead to different architectures.
Start with the actual data and action path. Labels such as “private,” “sovereign,” or “local” do not prove that a workload meets a requirement.
Intended user
Enterprise architects, data and security leaders, legal or compliance partners, and business owners translating requirements into a placement decision.
Collect before comparing
- 01Data inventory across prompts, context, embeddings, logs, evaluations, outputs, backups, and support artifacts
- 02Applicable legal, contractual, policy, and customer requirements supplied by the accountable specialists
- 03Allowed jurisdictions, subprocessors, operators, support paths, and administrative access
- 04Connectivity, latency, availability, continuity, and offline-operation needs
- 05Encryption, key control, identity, audit, deletion, retention, and portability requirements
- 06Model, service, update, telemetry, and supply-chain dependencies
Test every material criterion against the workload
Data path
Where does every data class travel, persist, replicate, appear in logs, and become accessible to support?
A local model does not create local processing if adjacent services export the workload.
Jurisdiction and operator
Which entities can administer or compel access to each component?
Physical location alone may not satisfy an authority or control requirement.
Operational independence
What must continue when a provider, control plane, license service, or network connection is unavailable?
Continuity needs can justify local capability even when steady-state economics do not.
Technological control
Can the organization inspect, update, replace, export, or operate the relevant component on acceptable terms?
Sovereignty may concern portability and operating authority as much as hosting location.
Evidence and accountability
Can the accountable owner verify the requirement and the implementation that is meant to satisfy it?
A vendor label is not a substitute for documented evidence and review.
Place each component at the least restrictive boundary that still satisfies the verified legal, contractual, data, continuity, and control requirements. Escalate ambiguous requirements to the accountable legal, security, privacy, or compliance owner before treating them as architecture facts.
This checklist is not legal advice, a regulatory interpretation, a data-protection impact assessment, or security approval. Requirements vary by jurisdiction, contract, data class, and organization. Do not infer compliance from the words local, private, dedicated, regional, or sovereign.
Editorial version 1.0
Initial public checklist reviewed August 2026. Re-review when jurisdictions, contracts, subprocessors, architecture, telemetry, support access, or data classes change.
StandardsUse the hybrid architecture reference
Map the resulting boundaries to local, private-core, and managed-service components.
Continue