compliancesovereigntyaudit

Compliance Controls for Sovereign Clouds: Encryption, Logging and Subprocessor Governance

UUnknown

2026-02-15

12 min read

A concise 2026 checklist for security and legal teams to verify sovereign cloud claims—testable controls for encryption, audit logs and subprocessor governance.

Stop trusting marketing — verify. A practical compliance checklist for sovereign cloud claims in 2026

If your organization depends on cloud-hosted, mission-critical systems for regulated workloads, the promise of a "sovereign cloud" raises a simple question: can the provider prove it? In 2026 the market has moved from marketing blurbs to technical and legal proofs — hyperscalers launched independent sovereign regions in late 2025 and early 2026, and sovereign offerings are now a baseline ask from regulators, auditors and procurement. Security and legal teams need a concise, testable compliance checklist that focuses on the three most consequential controls: encryption, auditability and subprocessor governance.

Why this matters now (short)

Regulators and customers expect demonstrable controls, not slogans. In January 2026, major providers announced regionally isolated cloud platforms designed for national and regional sovereignty needs. At the same time, adoption of confidential computing, customer-controlled keys (BYOK/CYOK), and supply-chain security rules have accelerated. That combination raises the bar: you must be able to request, verify and retain evidence that the provider enforces locality, key ownership, tamper-evident logs and tight subprocessor controls.

How to use this article

This guide gives a prioritized, actionable checklist you can use during vendor evaluation, RFP responses, legal review and operational testing. Each checklist item contains three columns of guidance: what to ask, what to test and what evidence to collect. Use it to structure vendor questionnaires, DPA clauses and technical proof-of-concepts.

Core principles that drive the checklist

Least trust, maximum verifiability — prefer customer-controlled keys and cryptographic proofs over provider attestations.
Proof over policy — require artifacts (signed logs, certificates, audit reports), not just statements.
End-to-end responsibility — ensure obligations flow down to subprocessors and are enforceable contractually and technically.
Testable controls — every claim should be provable through configuration, API evidence or an independent test.

2026 trends to incorporate into evaluations

Hyperscalers releasing dedicated sovereign regions and controls — expect stronger contractual assurances and network isolation options.
Wider adoption of confidential computing and hardware-based Trusted Execution Environments (TEEs) as part of sovereignty strategies.
Increased regulatory focus on cloud supply chains and subcontractor transparency; expect requests for subprocessor lists and flow-down clauses.
Demand for customer key control models (BYOK, HYOK) and cryptographic attestation from HSM vendors certified to FIPS 140-2/3 or equivalent.

Concise compliance checklist: Encryption, Auditability & Subprocessors

Section A — Encryption and Key Management

Encryption is the primary technical leverage you can use to reduce trust in the provider. Focus on who controls keys, how keys are stored and how deletion or export is constrained by location and policy.

Key ownership model
- What to ask: Does the provider support customer key control (BYOK or customer-managed KMS)? Can keys be created, rotated and revoked by the customer without provider intervention?
- What to test: Perform a POC that requires provider-managed service keys vs customer-managed keys. Verify data encrypted with a customer key becomes unreadable after key revocation.
- Evidence to collect: API logs showing key creation/rotation, signed KMS configuration export, and a proof-of-destruction test result demonstrating the provider cannot decrypt after key revocation.
Hardware protection and attestation
- What to ask: Are keys protected by HSMs certified to FIPS 140-2/3 or equivalent? Does provider supply HSM certifications and remote attestation capability?
- What to test: Request HSM attestation artifacts and run a remote attestation or attestation flow where the HSM signs a nonce to prove runtime environment and key residency.
- Evidence to collect: HSM certs, attestation logs, and vendor statements about HSM multi-tenancy boundaries.
Key export and escrow controls
- What to ask: Is key export prevented by default? If escrow or support access exists, what are the legal/technical controls (dual-approval, escrow location within jurisdiction)?
- What to test: Simulate a support escalation and examine the workflow and approvals required to access keys or plaintext in your environment.
- Evidence to collect: Support workflow diagrams, legal commitments in the DPA, and signed screenshots of approval steps during a controlled test.
Encryption in transit and at rest
- What to ask: Does the provider use modern TLS for transit and AES-256 (or agreed cipher suite) for storage? Are symmetric keys protected with envelope encryption?
- What to test: Packet-level capture of egress traffic during a POC to verify TLS/TLS1.3 and strong ciphers. Inspect storage layer metadata to confirm envelope encryption is in use.
- Evidence to collect: TLS configuration report, storage encryption metadata, and a catalog of ciphers used across services.

Section B — Auditability, Logging and Evidence

Audit logs are the primary mechanism for demonstrating chain-of-custody, privileged actions and compliance. Ask for technical guarantees about immutability, retention, and signed logging.

Comprehensive logging coverage
- What to ask: Which control planes and data planes are logged (admin API calls, KMS access, storage access, network flows)? Are logs delivered to customer-owned destinations?
- What to test: Generate representative administrative actions and data access events during a POC. Confirm logs are emitted with sufficient detail (who, what, when, where) and can be forwarded to your SIEM.
- Evidence to collect: Sample log entries, field descriptions, API timestamps and a mapping of log sources to compliance requirements (e.g., who accessed keys, who exported data).
Immutability and tamper-evidence
- What to ask: Are logs stored in WORM or equivalent immutable storage? Is there cryptographic signing or hashing of log sequences to detect tampering?
- What to test: Request a signed log segment and verify the signed hash chain. Introduce a controlled change and verify the system detects the tamper.
- Evidence to collect: Signed hash chains for log segments, WORM storage certification, and processes for replay and verification.
Retention, access controls, and legal holds
- What to ask: What are default retention periods and how can retention be extended for legal hold? Who may access logs and how are privileged requests authorized and recorded?
- What to test: Execute a legal hold request during a POC and verify retention extension. Run a privileged access request and confirm multi-factor authorization and logged approval trails.
- Evidence to collect: Retention policy text, legal hold procedures, and example access request logs showing approvals and timestamps.
Independent audit reports and continuous assurance
- What to ask: Ask for recent SOC 2 Type II, ISO 27001, PCI, or other relevant audits covering the sovereign region and services you will use. Are there continuous control monitoring feeds or attestations specific to the sovereign offering?
- What to test: Validate that the audit scope covers the physical location, network isolation, and key services. Confirm auditors' reports include description of exceptions and remediation timelines.
- Evidence to collect: Full audit reports or auditor attestations, Management Response summaries, and continuous assurance feed documentation if available.

Section C — Subprocessor Governance

Subprocessors (subcontractors) are a frequent source of sovereignty risk. Your DPA and vendor management must provide transparency and enforceability across the supply chain.

Complete subprocessor inventory and mapping
- What to ask: Request a current list of subprocessors, their roles, and their physical locations. How often is the list updated and how will you be notified of changes?
- What to test: Cross-check the list against service diagrams and verify that subprocessors performing critical tasks (KMS, logging, physical access) are identified and within the required jurisdiction.
- Evidence to collect: Subprocessor register, notification policy, and examples of prior change notices.
Flow-down obligations and contractual parity
- What to ask: Do subprocessors inherit the same security and privacy obligations as the primary provider? Can the provider supply redacted subprocessor agreements to prove flow-down clauses?
- What to test: Request a redacted subprocessor contract for a critical supplier and confirm terms mirror the provider's obligations for key handling, breach notification, and audit rights.
- Evidence to collect: Redacted subprocessor contracts, flow-down clause examples, and an affirmation that obligations are enforceable.
Approval and exit rights
- What to ask: What approval rights does the customer have over new subprocessors? Are there migration or termination rights if a subprocessor introduces non-compliance?
- What to test: Request a contractual commitment for advance notice and a right to object to new subprocessors in critical functions. Verify contractual exit and migration support for decommissioning data if you object.
- Evidence to collect: DPA clauses granting notice and objection rights, and examples of how the provider handled prior objections.
Operational controls for subprocessor staff
- What to ask: What background checks, access controls, and privileged access governance are in place for subprocessor personnel who may access your data or keys?
- What to test: Request evidence of role-based access reviews, privileged access logs for personnel, and separation-of-duty controls. Where possible, require MFA and PAM solutions for privileged accounts.
- Evidence to collect: Access control policies, example privileged access logs with ID and approval chain, and third-party penetration or staff security audits.

Contractual and DPA checkpoints (practical snippets)

Your vendor agreement and DPA should operationalize the technical expectations above. Below are concrete clauses to request or adapt in negotiation.

Key control clause
The customer shall retain exclusive control over customer-managed cryptographic keys. The provider shall not export, access, or use customer-managed keys except where explicitly authorized by the customer in writing. Provider support access to encrypted customer data requires prior, auditable dual-approval and shall be logged and delivered to the customer within 7 days.
Subprocessor flow-down clause
Provider shall ensure all subprocessors comply with materially equivalent security and privacy obligations. Provider will supply evidence of such obligations and allow the customer to review redacted subprocessor agreements on request. Provider shall notify the customer of any planned subprocessor changes at least 30 days before engagement and provide a right to object.
Audit and evidence clause
Provider will provide access to relevant audit artifacts (SOC 2, ISO 27001, HSM attestations), operational logs (where permitted), and will allow an independent third-party assessment under mutual NDA once per year. Evidence delivered will include signed log extracts and HSM attestation statements.

Operational validation tests to run in a POC

Key revocation test: Encrypt data with a customer key, revoke key, verify irrecoverability.
Attestation test: Request and verify HSM attestation chain for the region.
Logging tamper test: Generate a sequence of events, collect signed log segment and verify hash chain; attempt to modify stored log and validate detection.
Subprocessor trace test: Map a service action to the subprocessor involved and request documentary proof of contractual flow-down.
Incident response simulation: Trigger a simulated breach or data access event and verify notification timelines, evidence delivery and remediation steps.

Evidence catalogue — what you should receive

At the end of your evaluation you should have a packet of artifacts that together form the evidence base for compliance decisions.

Redacted DPA and subprocessor flow-down clauses.
List of subprocessors with locations and roles.
Recent audit reports and scope statements (SOC 2 Type II, ISO 27001).
HSM certification and attestation evidence for the sovereign region.
Signed log extracts and hash-chain verification samples.
POC test results: key revocation, log tamper detection, and incident simulation outputs.
Support escalation and key-access workflow diagrams demonstrating dual-approval for exceptional access.

Red flags that should pause procurement

Provider refuses to provide subprocessor inventory or limits disclosure to vague categories.
No support for customer-managed keys or inability to demonstrate key non-exportability.
Logs cannot be exported to customer-controlled SIEM or are editable without proof of detection.
Audit reports exclude the sovereign region or relevant services from scope.
Support access pathways that allow reading of plaintext without logged, auditable approvals.

Real-world example (anonymized)

A European financial services firm required strict sovereignty for payment data. They insisted on: customer-managed keys with HSM-backed BYOK, logs forwarded to a customer SIEM in the EU, and contract clauses giving right to object to subprocessors. During the POC they revoked a BYOK key and confirmed data became unreadable; they also ran an attestation proving keys resided in HSMs located in-country. The combination of contractual rights and technical proofs satisfied auditors and reduced the need for expensive dedicated infrastructure.

Checklist summary (one-page view)

Encryption: BYOK/HYOK support, HSM attestation, no-export guarantees.
Logging: signed immutable logs, SIEM export, legal hold capability.
Subprocessors: complete inventory, flow-down clauses, objection and exit rights.
Contracts: DPA with explicit KMS and subprocessor language, right-to-audit.
Tests: key revocation, attestation, log tamper-detection, incident response simulation.
Evidence: audit reports, attestation artifacts, signed logs, POC outputs.

Next steps — practical playbook for security and legal teams

Embed this checklist into your RFP and vendor questionnaire.
Assign technical owners to run the operational tests and collect artifacts during evaluation.
Negotiate DPA and subprocessor flow-down clauses up front; require artifact delivery timelines.
Schedule an independent third-party assessment for the final selection phase and retain auditors to validate high-risk claims.

Final thoughts — position for 2026 and beyond

In 2026, a sovereign cloud offering without verifiable encryption controls, signed immutable logs and enforceable subprocessor governance should be treated as marketing only. The combination of technical proofs (HSM attestation, BYOK, signed logs) and contractual protections (DPA, flow-down clauses, right-to-audit) provides measurable assurance. Make vendors demonstrate these capabilities in a POC and collect the evidence — auditors and regulators will expect it.

Call to action: Use this checklist as the baseline for your next vendor RFP. Request the artifacts listed in the Evidence Catalogue and run the operational tests in a controlled POC. If you need a vendor-ready checklist template or a negotiable DPA/KMS clause package tailored to your sector, download our procurement pack or contact our editorial team to arrange a technical review of your shortlisted providers.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.