Plain-English summary
A workload can remain subject to administrative overreach even when data is stored in a preferred country. The relevant questions are who can change policy, read or decrypt data, issue credentials, inspect memory, correlate telemetry, override logs, compel migration, and prevent exit.
Five sovereignty dimensions
Data and metadata
Location, access, encryption, inference, retention, backup, and secondary-use boundaries.
Identity and keys
Who can issue, recover, rotate, revoke, escrow, or use credentials and decryption authority.
Administrative power
Who can change infrastructure, policy, telemetry, access, evidence, and exception rules.
Jurisdiction and contracts
Declared legal, contractual, and provider obligations that affect access, disclosure, transfer, or retention.
Portability and exit
Whether workloads, identity, keys, logs, evidence, memory, and configuration can move or retire without capture.
Control patterns
Key custody separation
Overreach risk: A provider or administrator can access protected data unilaterally.
Architecture pattern: Separate data operations from key custody; document recovery, rotation, emergency access, and revocation.
Confidential computing
Overreach risk: Data is exposed to infrastructure administrators while being processed.
Architecture pattern: Consider hardware-backed isolated execution and attestation where the threat model justifies it.
Remote attestation
Overreach risk: A workload runs in an unexpected or modified environment.
Architecture pattern: Verify declared software and environment measurements before releasing secrets or authority.
Infrastructure-as-code checks
Overreach risk: Manual configuration drift silently broadens access or public exposure.
Architecture pattern: Version network, identity, logging, retention, and key policies; lint for broad routes, public exposure, and missing expiry.
Administrative separation
Overreach risk: One role can change policy, read data, approve exceptions, and erase evidence.
Architecture pattern: Separate administration, security, privacy, key management, review, and appeal authority where feasible.
Resilient exit
Overreach risk: Provider dependence turns migration or termination into loss of data, identity, keys, or evidence.
Architecture pattern: Test export, key transition, workload redeployment, endpoint revocation, evidence retention, and provider offboarding.
What these controls do not prove
- Encryption does not eliminate metadata leakage, endpoint compromise, key misuse, or governance failure.
- Confidential computing does not prove application correctness, policy legitimacy, or absence of side channels.
- Attestation proves only the declared measurement relationship under the chosen trust chain; it is not a general safety certificate.
- Data residency does not by itself create participant consent, portability, repair, or exit.
- VNWO does not provide legal advice or guarantee sovereignty, privacy, compliance, or provider independence.
Cloud-sovereignty worksheet
Record the controls and dependencies that determine whether a workload can resist unilateral provider or administrator power. Country location alone is not enough.
| Provider administration | Who can change policy, access data, alter logs, recover accounts, or approve exceptions? |
|---|---|
| Key custody | Who can issue, rotate, escrow, recover, or use decryption keys? |
| Attestation scope | What measurement is checked, under which trust chain, and what does it not prove? |
| Infrastructure drift | Which IaC rules detect broad routes, public exposure, permanent credentials, or missing retention limits? |
| Jurisdiction and portability | Which obligations apply, and can workloads, keys, memory, logs, and evidence move? |
| Offboarding | How are provider access, credentials, endpoints, backups, evidence, and residual dependencies retired? |
Copyable sovereignty profile JSON
{
"artifact_type": "cloud_sovereignty_profile",
"schema_version": "3.0.8",
"created_utc": "2026-06-21T02:42:50Z",
"deployment_scope": "example-workload",
"data_residency": {"regions": ["declared-region"], "cross_border_transfer_review": true},
"key_custody": {"provider_can_decrypt_unilaterally": false, "rotation_days": 90, "emergency_access_review": true},
"confidential_computing": {"used": false, "attestation_required": false, "threat_model_reference": "docs/threat-model.md"},
"administrative_roles": ["platform-admin", "security-review", "privacy-review", "key-custodian", "appeal-review"],
"iac_checks": ["no-public-admin-ports", "no-global-route", "credential-expiry", "logging-retention-bounds"],
"exit_tested_utc": "2026-06-21T02:42:50Z",
"claim_boundary_notes": "VNWO documents a review profile; it does not guarantee sovereignty, confidentiality, compliance, or attestation correctness."
}Cloud sovereignty QA checklist
- Provider and customer administrative powers are documented separately.
- Key custody, emergency access, backup recovery, and revocation are tested.
- Infrastructure changes are versioned and checked for broad routes, public exposure, permanent credentials, and missing retention bounds.
- Attestation and confidential-computing claims are scoped to what is actually implemented.
- Exit tests include workload migration, key transition, endpoint revocation, memory and evidence handling, and provider offboarding.