Tools

CSP is incorporated and governed in your target jurisdiction with no foreign parent that could trigger extraterritorial access. All operations, staff, and key decisions are local.

Verify: Check company register, contract signing entity, ultimate beneficial owner structure, and DPA governing law clause.

Examples: OVHcloud (France), IONOS (Germany), G42 Cloud (UAE), Yandex Cloud (Russia), Elastx (Sweden)

A foreign CSP has established a locally incorporated, ring-fenced operator entity. The operator controls the infrastructure, holds staff in-country, and is legally separated from the foreign parent for operational access.

Verify: Request the trusted operator agreement, ring-fencing documentation, and local entity registration. Confirm the parent cannot direct the operator to hand over data.

Examples: Azure via Bleu (France, Orange+Capgemini), Azure via T-Systems (Germany), Azure via Arvato (Germany sovereign)

CSP headquarters and ultimate parent are outside your jurisdiction. No sovereign operator model exists. Foreign law (e.g. US CLOUD Act, Chinese NSL) may compel disclosure without customer notification.

Verify: Check DPA for governing law, CSP transparency report for government access requests, and whether any local subsidiary exists with genuine operational independence.

Examples: AWS (standard), Microsoft Azure (standard, non-sovereign regions), Google Cloud (standard)

The DPA names a specific country/region and commits that data (including backups, telemetry, metadata, and support bundles) will not leave it. Region-lock is technically enforced by service design, not just policy.

Verify: Read DPA residency clause. Check CSP documentation for region-lock architecture, VPC Service Controls, Azure Policy region restrictions, or AWS SCPs with an explicit deny on cross-region operations.

Examples: OVHcloud (contractual + technical), AWS GovCloud (FedRAMP residency), Azure sovereign regions under trusted operator model

Technical controls exist to restrict data to a region (org policies, SCPs, region lock) but the DPA does not contractually commit to residency. Data may still move for support, incident response, or backup unless you configure and audit controls yourself.

Verify: Check whether the standard DPA has any residency language. Test org policies/SCPs in a non-prod environment. Review support access policy to confirm whether global staff can reach in-region data.

Examples: AWS (standard EU regions, no DPA residency guarantee), GCP (org policies available, no contractual guarantee), Azure (standard regions, no residency commitment without sovereign add-on)

DPA and service terms contain no data residency commitment. CSP may process or store data in any region for operational reasons. No technical enforcement mechanism is available or documented.

Verify: Review service terms for cross-border transfer carve-outs ("we may process your data globally"). Check if the service is even available in a local region.

Examples: Many SaaS providers (Salesforce standard, Zendesk standard), CDN-first services, global SaaS without regional data isolation

Customer operates an HSM outside CSP infrastructure. The CSP never receives or caches the root key. Double-key or hold-your-own-key architecture means the CSP cannot decrypt data even if compelled. HSM must be FIPS 140-3 Level 3+ or equivalent.

Verify: Request HYOK architecture diagram. Confirm the HSM is customer-owned or third-party operated (not CSP-managed). Check if the CSP has a "wrapping key" that could give them access. Verify FIPS certification of HSM.

Examples: Microsoft Azure Double Key Encryption (DKE) with customer HSM, Thales S3NS with customer-controlled HSM, IBM Hyper Protect with dedicated HSM

Customer generates and imports key material; the CSP stores and uses it on the customer's behalf. The CSP infrastructure touches the key during decryption operations and could theoretically be compelled to use it. Better than CSP-managed but not full key sovereignty.

Verify: Confirm the CSP uses customer-provided key material (not CSP-generated wrapping keys as the root). Check whether the CSP can access the key under a law enforcement request. Review key import and custody documentation.

Examples: AWS KMS Customer Managed Keys (CMK), Azure Key Vault CMK, Google Cloud CMEK, AWS CloudHSM (customer-managed in CSP datacenter)

The CSP generates, stores, and rotates all encryption keys. The customer has no custody or visibility. The CSP can decrypt your data at any time — including under legal compulsion.

Verify: Check default storage encryption documentation. If no key management option is offered or the service only supports platform-managed keys, this is the correct tier.

Examples: Default AWS S3 SSE-S3, default Azure Storage encryption (SSE with platform key), Google Cloud default encryption

All staff with access to customer environments are nationals of the jurisdiction, hold appropriate clearances, and are contractually barred from escalating outside the country. A specific sovereign support tier product exists.

Verify: Request the sovereign support tier documentation. Confirm personnel nationality and vetting requirements in the service description. Check whether the SLA limits who can access your environment during an incident.

Examples: AWS Dedicated Local Zone sovereign support (where offered), OVHcloud SecNumCloud support tier, Azure sovereign support under trusted operator model

Support is primarily based in your region with local staff, but no formal clearance requirement exists and global escalation is possible (e.g. a complex incident is escalated to a US-based engineer). No contractual restriction on international access.

Verify: Review CSP enterprise support documentation. Check whether support access policies restrict which engineers can view your data. Review lockbox/access approval availability.

Examples: AWS Enterprise Support (EU-based TAM, global escalation possible), Azure Business/Enterprise support (regional but no clearance bar)

Any support engineer globally may access your environment. No locality or clearance requirement. Standard for all hyperscaler support tiers without a specific sovereign add-on.

Verify: Check standard support tier terms. Confirm whether Customer Lockbox or equivalent is enabled (but note: this is an access-approval control, not a locality guarantee).

Examples: AWS standard support (no sovereign tier), Google Cloud standard support, Azure standard support outside sovereign regions

CSP holds a sovereign-specific certification recognised by the target regulator. These require independent assessment of data residency, access controls, cryptography, and operational sovereignty — not just security management processes.

Verify: Check ANSSI's SecNumCloud qualification list, ENISA EUCS certification registry (when live), the FedRAMP marketplace, or the ASD IRAP assessment register. Confirm the specific service (not just the company) is in scope.

Examples: OVHcloud SecNumCloud (France), Outscale SecNumCloud (France), AWS GovCloud FedRAMP High, Azure Government FedRAMP High

CSP holds cloud-specific security certifications demonstrating operational security maturity. These confirm security management processes and cloud controls but do not verify data residency, key sovereignty, or national personnel requirements.

Verify: Check CSP compliance documentation page. Confirm ISO 27017 (cloud-specific controls) and CSA STAR Level 2 (independent assessment) are current and in-scope for the services you are using.

Examples: AWS (ISO 27017, CSA STAR), Azure (ISO 27017, CSA STAR), GCP (ISO 27017, CSA STAR)

CSP relies on operational/availability attestations or self-published security documentation without independent sovereign or cloud-security certification. SOC 2 Type II confirms operational controls but has no residency, jurisdiction, or cryptographic sovereignty component.

Verify: Check whether any third-party cloud security certification exists. SOC 2 Type II reports are often shared under NDA — request one. Self-attestation is no substitute for independent certification.

Examples: Smaller cloud providers, niche SaaS platforms, regional hosting providers without formal cloud security certification

Contract explicitly commits to migration assistance, data export in open formats, waived egress fees on termination, and a documented exit plan. The CSP (or your organisation) has performed an exit test within an agreed recovery window.

Verify: Check contract termination and portability clauses. Confirm EU Data Act Article 23 compliance (if EU). Request exit plan documentation. Ask whether egress fees are waived at contract end. Check if a test migration has been performed.

Examples: Some EU sovereign CSPs with explicit EU Data Act portability SLAs; bespoke enterprise contract terms negotiated with hyperscalers

Export tools and APIs exist and data is in portable formats, but no contractual migration assistance is committed and no test has been performed. Egress fees may apply. You could theoretically exit but the effort and cost are unknown.

Verify: Test data export tooling for completeness (does it cover all data types, including metadata and backups?). Review egress fee schedule. Check data format documentation for open standard compliance.

Examples: AWS (S3 export, no contractual portability assistance), Azure (Data Factory export tools), GCP (Transfer Service)

CSP uses proprietary data formats, charges significant egress fees, offers no migration assistance, and has no contractual portability commitment. Moving away requires full re-architecture and significant cost.

Verify: Check egress pricing. Review whether services use open APIs or proprietary SDKs. Look for any migration tooling or SLA for data return after termination.

Examples: Heavy reliance on proprietary managed services (e.g. AWS DynamoDB with no open export, proprietary SaaS with no data portability)