How to evaluate a sovereign cloud vendor: a 12-point checklist

Why this checklist exists

"Sovereign cloud" is the most overloaded term in 2026 storage marketing. Every hyperscaler resells regional capacity and labels it "sovereign." Most resellers add a flag and call it Canadian (or French, or German). The architectural test for sovereignty — can compelled disclosure under foreign law reach my data? — usually doesn't come up until contract negotiation, and by then the vendor selection is functionally locked in.

This checklist is for the technical buyer who wants to find out the answer at evaluation, not at incident.

1. Where is the encryption key derived?

Good answer: "On the customer's device, from a customer-controlled secret (password, recovery key, HSM). Never on our servers."

Bad answer: "In our KMS / HSM. We hold them but you control authorisation."

2. Is there an API path on your server that returns plaintext?

Good answer: "No. Our server has no code that derives the wrap key. Decryption happens client-side, after Reed-Solomon reconstruction of the shards."

Bad answer: "Yes, authorised reads through our compute plane decrypt and stream plaintext."

3. If a foreign court ordered you to decrypt a specific customer's data, what would you do?

Good answer: "We literally cannot. The platform does not possess the capability. We can produce ciphertext metadata and access logs; we cannot produce plaintext."

Bad answer: "We would resist on jurisdictional grounds, and if forced, we would comply."

4. How many distinct providers and jurisdictions does my data spread across?

Good answer: "RS(5,2)">Reed-Solomon RS(5,2) means each file is split into 7 shards across 7 distinct providers, in up to 7 distinct jurisdictions chosen by you. Any 5 reconstruct; any 2 can be lost. No single provider holds a readable copy."

Bad answer: "We replicate to 3 zones in our region of choice."

5. Can I see, per-file, which jurisdictions hold my data right now?

Good answer: "Yes. Real-time per-file map with confidence-graded endpoint resolution: probed (API-verified), declared (operator-typed), observed (traceroute), country-only, unknown. Each renders with a distinct visual treatment."

Bad answer: "Our region selector documents what region your data is in."

6. What FIPS-finalised post-quantum algorithms are in production?

Good answer: "ML-KEM-1024 (FIPS 203) hybrid key wrap on Sovereign tier. ML-DSA-87 (FIPS 204) signatures on every report and integrity certificate. Both shipping in production today, not on a roadmap."

Bad answer: "We're tracking the standards. PQ is on our roadmap for next year."

7. Are your signed reports offline-verifiable?

Good answer: "Yes. Our issuer public key is published at /security as a SHA-256 fingerprint for pinning and as raw base64 for use with any FIPS 204 verifier. A recipient can verify a signed report entirely offline without contacting our platform."

Bad answer: "Reports are signed; verification requires calling our API."

8. What does compelled access to your operator team yield?

Good answer: "Access logs, metadata, and ciphertext shards (which our operators host for delivery, not for decryption). The operator team has no path to unwrapped keys."

Bad answer: "Our operators have administrative access; we trust our hiring and access-control processes."

9. Can I bring my own storage providers?

Good answer: "Yes. Plugin SDK requires under 500 lines of code. We ship 14 providers (hyperscaler, S3-compatible, OAuth, on-prem). You can integrate a sovereign or regional provider not in the catalogue."

Bad answer: "We're built on AWS. The architecture is fixed."

10. Does your S3-compatible gateway exist?

Good answer: "Yes. SigV4, path-style addressing, full compatibility with Cyberduck, boto3, awscli, rclone, Veeam, AWS Backup. Multipart writes flow through the same encrypt-encode-scatter pipeline as native uploads."

Bad answer: "You can migrate to our proprietary SDK."

11. What's your tier-change behaviour?

Good answer: "Tier changes are recovery-neutral by construction. Both wrapped UMK variants are unwrap-attempted on every login; downgrades explicitly unwrap both before clearing. An organisation that leaves Sovereign tier retains access to every file it encrypted while on it."

Bad answer: "Downgrading might affect access; please contact support."

12. What's your AI/ML data-handling posture?

Good answer: "On-prem GPU embedding service (SkyeGXU) exposes OpenAI-compatible /v1/embeddings. RAG and semantic search run on customer hardware. No customer data ever reaches OpenAI, Azure OpenAI, or any external LLM provider — on Sovereign tier, end-to-end."

Bad answer: "We use Azure OpenAI for our AI features, hosted in your region of choice."

Scoring

• 10+ good answers: Vendor has built actual architectural sovereignty. Worth a deep evaluation.
• 5-9 good answers: Partial answer. Useful for some workloads, not for compelled-disclosure exposure.
• Fewer than 5: Marketing sovereignty. The vendor is reselling something else under a sovereign banner.

SkyeConnex scores 12/12 on this list — and we will demonstrate every answer live. Book a briefing; we will walk you through each point on a real configuration relevant to your use case.

---

Published April 2, 2026 · Written by SkyeConnex Inc. · More from the SkyeConnex blog