Europe did not close its market. It re-priced the paperwork.
In 2016 a regulated European enterprise could select an American managed cloud provider after a disciplined vendor assessment against the EBA outsourcing framework. Data in the US or the UK raised few eyebrows. A decade later, every layer of the deal, data location, key custody, support staffing, corporate structure, is interrogated against a stack of EU and UK instruments that did not exist, or did not bite, when those first contracts were signed.
Scroll to begin ↓
From vendor assessment to sovereignty audit
The compliance question asked of a US provider has changed in kind, not just in degree. In 2016 the buyer asked: is this vendor well controlled? Today the buyer asks: can this vendor, as a matter of US and EU law, keep EU data beyond the reach of US authorities, survive a resilience audit under DORA, and qualify under national sovereignty schemes it cannot legally satisfy?
The 2016 baseline
The EBA’s outsourcing work (finalised as Guidelines EBA/GL/2019/02 in February 2019) gave banks a harmonised vendor assessment: due diligence, written contracts, audit rights, exit strategies. The EU-US Privacy Shield (Decision (EU) 2016/1250) legitimised transatlantic data flows for certified US firms. Remote support from the US or India was a commercial feature, not a legal event.
The 2026 reality
Privacy Shield fell in Schrems II (C-311/18). Every transfer now needs a case-by-case Transfer Impact Assessment and supplementary measures. The CLOUD Act reaches data held by US-controlled providers wherever stored. DORA, NIS2, the AI Act, the Cyber Resilience Act and the Data Act each add their own vendor-facing duties. France and Germany gate sensitive public workloads behind immunity requirements that a US-controlled entity cannot meet.
Why deals are slowing
None of these instruments individually prohibits buying from a US vendor. The friction is cumulative: each instrument adds an assessment, a contract schedule, a certification or a monitoring duty, and the burden lands on the buyer’s risk function, which rationally responds by demanding more evidence, more time, or a European alternative. The sections below map each instrument, then let you test architectural choices and compare buyer outcomes.
A decade of compounding constraints
EBA outsourcing framework and Privacy Shield era
Vendor selection driven by due diligence quality. EU-US Privacy Shield (Decision (EU) 2016/1250) covers transatlantic transfers. The UK is inside the EU. Data location is an operational detail.
GDPR applies; US CLOUD Act enacted
Regulation (EU) 2016/679 applies from 25 May 2018 with Chapter V transfer rules and Article 48 on foreign authority demands. In March 2018 the US CLOUD Act obliges US providers to produce data within their possession, custody or control, regardless of where it is stored.
Schrems II; EDPB Recommendations 01/2020 and 02/2020
The CJEU invalidates Privacy Shield and makes SCCs conditional on case-by-case equivalence checks. The EDPB publishes its six-step roadmap and its European Essential Guarantees for surveillance measures. The ICO regime diverges after Brexit.
New SCCs; UK adequacy; PRA SS2/21; France goes cloud au centre
Commission Implementing Decision (EU) 2021/914 modernises SCCs and embeds a transfer assessment duty in Clause 14. The EU grants the UK adequacy. The PRA issues SS2/21. France’s circulaire of 5 July 2021 requires SecNumCloud-qualified, non-EU-law-immune clouds for sensitive state data.
DORA and NIS2 adopted
Regulation (EU) 2022/2554 (DORA) and Directive (EU) 2022/2555 (NIS2) enter the books, adding ICT third-party risk, testing, incident reporting and supply chain duties across finance and 18 critical sectors, including energy.
EU-US Data Privacy Framework; EU Data Act
Decision (EU) 2023/1795 restores an adequacy route for DPF-certified US organisations. Regulation (EU) 2023/2854 (Data Act) adds switching rights, egress charge phase-out and safeguards against third-country governmental access to non-personal data held in the EU.
AI Act, Cyber Resilience Act and CER Directive; EDPB Article 48 guidance
Regulation (EU) 2024/1689 and Regulation (EU) 2024/2847 enter into force. Directive (EU) 2022/2557 on the resilience of critical entities applies from October, adding physical resilience duties for energy and other critical sectors. EDPB Guidelines 02/2024 confirm the two-step test before answering third-country authority demands. UK regulators update outsourcing expectations.
DORA applies; first critical ICT providers designated; DPF survives court challenge
DORA applies from 17 January. The ESAs designate the first critical ICT third-party providers under Article 31 in November. On 3 September the General Court dismisses Latombe v Commission (T-553/23), upholding the DPF while stressing continuous monitoring. EIOPA retires its cloud guidelines into DORA.
Commission publishes the Cloud Sovereignty Framework (SEAL)
DG DIGIT releases version 1.2.1 of the Cloud Sovereignty Framework: eight sovereignty objectives (SOV-1 to SOV-8), five assurance levels (SEAL-0 to SEAL-4) and a weighted Sovereignty Score used as an award criterion in EU public procurement. Tenders failing the minimum SEAL level on any objective are rejected outright.
UK adequacy renewed; CRA and AI Act phase in; EUCS unresolved; UK reporting rules land
The Commission renews EU-UK adequacy on 19 December 2025, valid to 27 December 2031. CRA vulnerability reporting starts 11 September 2026, full obligations 11 December 2027. AI Act high-risk duties phase in from August 2026, with a Digital Omnibus proposing timeline adjustments. The PRA finalises incident and material third-party reporting (PS7/26, March 2026). The EUCS sovereignty question remains contested.
The regulation atlas
Every instrument below is drawn from official publications: EUR-Lex, the CJEU, the EDPB, ENISA, BSI, ANSSI and DINUM, the Bank of England, the FCA and the ICO. Filter by layer, expand any entry for obligations, buyer impact and the ACME-specific consequence.
The buyer’s seven-step assessment, then your architecture
Before any EU regulated or public buyer signs with ACME, its DPO and risk function must complete a seven-step assessment built from GDPR Article 28 processor due diligence and Chapter V transfer rules, structured by the EDPB’s Recommendations 01/2020 roadmap. How much of that work actually applies depends on ACME’s operating model. Choose a profile below to see only the applicable steps, or compare the two profiles side by side with time and effort estimates.
Adequacy map: where the EU considers data safe
Article 45 GDPR lets personal data flow freely to countries the Commission has deemed adequate. Everything outside that list, and everything without a certified framework, is a Chapter V transfer that drags steps 3, 4, 5 and 7 into the deal. The United States is adequate only for organisations self-certified under the EU-US Data Privacy Framework; the United Kingdom adequacy runs to 27 December 2031.
Country boundaries: Natural Earth 110m (public domain), Miller projection. Small adequate jurisdictions not visible at this scale: Andorra, Faroe Islands, Guernsey, Isle of Man and Jersey. Canada’s adequacy covers commercial organisations subject to PIPEDA. Greenland, shown unshaded, is not part of the EU/EEA and holds no adequacy decision. The DPF was upheld by the General Court in Latombe v Commission (T-553/23, 3 September 2025), subject to continuous monitoring and a possible appeal. Sources: European Commission, adequacy decisions; Decision (EU) 2023/1795 (DPF).
If ACME supports from non-adequate countries: the compliance matrix
Every declared support location is a separate legal analysis under EDPB Recommendations 01/2020, because routine remote access to EEA data from a third country is itself a transfer (Use Case 7). Choose ACME’s support footprint to see the obligations each leg adds for the buyer and for ACME, and which of the seven steps each leg activates.
Step 7 is where US and global support models keep costing you
Monitoring is continuous, not a one-off. The buyer must re-evaluate, at appropriate intervals, the legal situation in every jurisdiction ACME has declared as a destination for data or a location from which support and administration are delivered, including the US, India and any other non-adequate country in the chain, and must watch for changes such as new surveillance legislation, the state of the EU-US Data Privacy Framework, and the effect of the CLOUD Act on each declared location. A shorter declared jurisdiction list is a standing commercial advantage.
Read the basis for this conclusion
Where we read it
EDPB Recommendations 01/2020, step 6 of the roadmap (“re-evaluate at appropriate intervals”), read together with Use Case 7 (remote access for support is a transfer) and the General Court’s insistence in Latombe that the Commission continuously monitors the DPF. EDPB Guidelines 02/2024 add the Article 48 duty to refuse direct third-country orders absent an MLAT.
Impact on the decision
A US or India support leg is never “solved” at signature: it is a compliance subscription the buyer renews for the life of the contract. Legal and risk teams therefore treat the declared jurisdiction list as a proxy for total cost of ownership, and EU-confined support as the single architectural decision that collapses it.
Atlas entry: EDPB Recommendations 01/2020 Atlas entry: Article 48 guidelinesDecision tree: architecting a compliant offering
Five architectural decisions determine most of ACME’s legal exposure and SEAL scoring in Europe: where data is stored, where it is processed (and in what form), who holds the encryption keys and where the HSM lives, where operational and application support staff are located, and which legal entity contracts. Storage, processing and support are separate questions: data can rest in Frankfurt while a US administrator or a clear-text processing pipeline turns it into a transfer anyway.
The buyer’s chair: four vendors, three buyer types
Same service, four sellers: ACME US (contracting from the United States), ACME EU (a US-controlled EU subsidiary), a Croatian d.o.o., and a French or German provider. Pick a buyer profile and see how the procurement conversation changes. Scores are indicative friction ratings on a 0 to 10 scale, built from the instruments in the atlas.
The SEAL lens: how EU public buyers now score sovereignty
The Commission’s Cloud Sovereignty Framework (version 1.2.1, October 2025) gives public contracting authorities an explicit calculation. Each tenderer is rated against eight sovereignty objectives on five Sovereignty Effectiveness Assurance Levels, SEAL-0 (no sovereignty, exclusive non-EU control) to SEAL-4 (full digital sovereignty, EU control only). Tender specifications set a minimum SEAL level per objective: fall below it on any one and the tender is rejected. Surviving tenders are then ranked by a weighted Sovereignty Score, which feeds the award decision as a quality criterion. Operational and application support delivered from outside the EU depresses SOV-4 directly and drags SOV-1, SOV-2 and SOV-7 with it, which is exactly where a US or follow-the-sun operating model scores low.
Worked example: support staff location is decisive
Two otherwise identical bids, EU data residency and customer-held EU keys in both, diverge only on SOV-4: bidder A runs operational and application support from the EU; bidder B runs it from the US and India. Under the framework’s contributing factors, operational support delivered from outside the EU and subject to non-EU legal frameworks caps bidder B at SEAL-1 on SOV-4, and the exposed legal channels lower SOV-2 as well. If the tender sets a minimum of SEAL-2 on SOV-4, bidder B is rejected before price is ever read. The same exclusion logic applies to follow-the-sun support: every non-EU jurisdiction ACME declares becomes a contributing-factor weakness the contracting authority must score down.
Read more: basis for the scoring
How we concluded this
The SEAL levels above apply the Cloud Sovereignty Framework v1.2.1 (October 2025) contributing factors per objective: strategic control and ownership for SOV-1; immunity from non-EU law for SOV-2; data residency and portability for SOV-3; the location of operations and support staff for SOV-4; non-EU technology dependencies for SOV-5 and SOV-6; certifications and audit rights for SOV-7. The weighted score follows the framework formula: sum over objectives of (SEAL level divided by 4) times the objective weight, out of 100.
Impact on the decision
The matrix converts sovereignty from rhetoric into arithmetic a procurement board must apply. SOV-4 carries 15 per cent of the total weight and is the objective ACME controls most directly: moving operational and application support into the EU is worth up to 15 points on the Sovereignty Score and, more importantly, removes the below-minimum cells that reject bids at the gate.
Atlas entry: Cloud Sovereignty FrameworkCompliance blockers and market entry friction, by jurisdiction
The specific gates ACME will meet, market by market. A blocker is a requirement ACME cannot currently satisfy as a US-controlled provider; friction is a requirement it can satisfy only with time, money or restructuring.
Comparative risk assessment
Residual commercial and legal risk of selling into EU regulated and public buyers, scored 1 (low) to 5 (severe) per domain, with each provider ranked overall. Read down a column to see one provider's profile; read across a row to compare all four on one risk domain. The matrix assumes competent execution in every case: it measures structural exposure, not effort.
Key takeaways: one-minute read
- Structure decides the ceiling, not effort. A US-direct and a wholly-owned EU subsidiary converge on the same risk profile wherever ownership is tested; only the licensed EU-controlled venture escapes the structural domains.
- Sovereignty-gated tenders are the sharpest edge. SecNumCloud immunity tests and SEAL minimum levels reject bids before merit, which is why that domain dominates the US-direct profile.
- Transfer legality is manageable, government-access conflict is not. SCCs and transfer impact assessments lower the first domain; no contract language removes the second while US control persists.
- Certification is the cheapest risk reducer in the matrix. C5, ISO and SOC evidence moves several domains by a full point without any structural change; they should precede, not follow, the venture decision.
How to read the ranking
Rank 1 is the lowest-risk seller. The Croatian d.o.o. and the French or German provider face identical regulatory duties under GDPR, DORA, NIS2, the CRA and the AI Act, which is why the product compliance row is level across all four columns. What the EU providers escape is the transfer and jurisdiction layer: no TIA, no Article 48 conflict, no CLOUD Act exposure, and eligibility for sovereignty-gated tenders. The ranking gap is legal geography, not compliance quality.
Emerging frameworks: what is proposed, and what it would do to ACME
Everything below is a live legislative file, not yet binding law (except where marked). For a US-headquartered provider the pipeline matters more than the statute book: each file is analysed against the same lenses used elsewhere in the atlas, with the Cloud and AI Development Act, CADA, examined in the same depth as the Cloud Sovereignty Framework.
CADA versus the Cloud Sovereignty Framework: same test, sharper teeth
The Commission’s Cloud Sovereignty Framework (v1.2.1, October 2025) is a procurement tool: it scores bidders on eight objectives and lets tenders set minimum SEAL levels. CADA would take the same logic and give it statutory force. The table maps the framework’s objectives to CADA’s sovereignty assessment pillars and shows what changes for each provider type.
Indicative CADA exposure scoring, same providers, same discipline as SEAL
Applying CADA’s proposed sovereignty assessment criteria (data location, exposure to third-country law, ownership and control, supply chain, operational resilience, security and compliance, prevention of third-country interference) to the four provider types produces the same rank order as the SEAL matrix, with one difference: CADA’s criteria are structural eligibility tests, not weighted scores, so the gap cannot be closed with certifications alone. ACME US (direct) fails the ownership and third-country-law pillars outright; ACME EU subsidiary passes data location but fails ownership insulation; the Croatian d.o.o. passes on substance with supply-chain caveats; only the French or German provider, or a genuinely EU-controlled licensed venture, clears every pillar. The consequence for ACME’s roadmap: CADA converts Phase 3 (sovereignty constructs) from an option for France into the default architecture for EU public sector cloud by the late 2020s.
Read more: basis for this analysis
Where we read it
COM(2026) 502 (3 June 2026), Article 1 subject matter and the annexes setting out the cloud sovereignty assessment criteria; the Commission’s impact assessment (SWD(2026) 502), which reports the EU-based providers’ share of the European cloud market falling from roughly 29 per cent in 2017 to about 15 per cent by 2022; and the joint institutional roadmap targeting political agreement by Q4 2027. The parallel to the SEAL methodology is deliberate: CADA’s autonomy pillar is described by the Commission as “a single EU-wide assessment framework for cloud and AI sovereignty, accompanied by a public sector adoption mechanism”.
How it impacts the decision
Procurement teams will not wait for trilogue. CADA’s criteria are already the reference vocabulary for sovereignty due diligence, exactly as the draft EUCS tiers were before adoption. Sellers should map their architecture against the seven pillars now, because the first tenders citing CADA by name will arrive years before the regulation applies.
Stress test: if Parliament hardens CADA in negotiation
A scenario simulation, not a report of agreed text. Four hardening levers are modelled against the same four provider types used throughout this atlas: mandatory sovereignty risk assessments extended to private entities in NIS2 Annex I sectors (including banking and financial market infrastructures); a 12-month duty to switch provider where the assessment identifies risk; compression of the four Union assurance levels into a two-level framework; and removal of the associated third country route.
Status check, October 2026: read before quoting
No JURI committee opinion on CADA has been published. Parliament’s file is assigned to the ITRE and IMCO committees, with Diego Solier (ECR) and Reinier Van Lanschot (Greens/EFA) as rapporteurs, and the committees had not voted at the time of writing. The only published institutional opinion is EDPS Opinion 14/2026, which seeks clarifications of the proposal rather than the changes described above. The scenario is nonetheless worth modelling because each lever has an anchor in the live text: Article 31(3) already empowers the Commission to make private-sector sovereignty risk assessments mandatory by delegated act; the proposal already caps any migration transition at 12 months where a risk assessment requires switching; Article 18’s associated third country mechanism is the lever whose removal is simulated; and compressing the four assurance levels of Articles 16 to 19 into two is a plausible simplification direction. Treat what follows as stress-testing, never as law.
Reading the simulation
Under the hardened scenario the distinction that matters stops being where data sits and becomes who controls the provider. ACME US (direct) and the US-controlled EU subsidiary converge on the same ceiling: confined to Level 1, commodity workloads, with a statutory exit clock running wherever a client’s mandated assessment identifies third-country control risk. The genuinely EU-controlled providers inherit the regulated market, including financial services, and the 12-month switching duty converts their sales motion from persuasion to migration capacity. For ACME the scenario sharpens the roadmap’s Phase 3 conclusion: the licensed EU-controlled venture is not a France-specific workaround but the only structure that survives the worst plausible trilogue outcome, and the migration tooling built for the Data Act becomes the venture’s primary commercial weapon.
Read more: basis for this simulation
Where we read it
COM(2026) 502: Articles 16 to 19 (Union assurance levels, recognition and self-assessment), Article 18 (associated third countries), Article 29 (Member State and Union entity risk assessments), Article 30 (procurement obligations), Article 31(3) (delegated-act power to extend mandatory assessments to highly critical private entities) and the 12-month ceiling on migration transitions; the European Parliament Legislative Train file for committee assignment and status; EDPS Opinion 14/2026 for the institutional response published so far; and the Commission impact assessment SWD(2026) 502 estimate that only about 10 per cent of public sector use cases need the highest tiers, the proportion a hardened text would expand.
How it impacts the decision
Scenario analysis of this kind is how risk committees price legislative tail risk: the question is not whether the hardened text is likely, but whether ACME’s structure survives it. A structure that only works if the negotiation goes well is not a compliant structure, it is a bet.
Official source: European Parliament Legislative Train, CADA file ↗Sovereignty, defined by regulator, decided by keys
Eleven jurisdictions across Europe, the Americas and the Gulf, and one technical fact underneath all of them: whoever can make the data readable controls it. This section maps what each regulator actually demands, tests the hyperscalers’ sovereign portfolios against those demands, and traces the questions that settle most of the debate: where the encryption keys live, who operates the HSM, and what changes when the cloud customer is itself a provider like ACME.
Key takeaways: three-minute read
- One structural regime, several behavioural ones. Only the EU tests ownership and immunity; the UK, Singapore, Switzerland and Australia test control evidence; the Gulf localises by sector; Latin America tests transfers and supervision. Price the difference, not the label.
- Engineering sovereign clouds clear behavioural regimes, not ownership tests. The AWS European Sovereign Cloud, Microsoft Sovereign Public Cloud and Google Data Boundary improve every evidential analysis, but only partner-operated clouds (S3NS, Bleu, Delos, T-Systems, the Thales-owned German entity) pass regimes that test who owns the provider.
- Custody beats geography. Encryption at rest is table stakes; under EDPB Use Case 1 the client’s test runs against whoever operates the KMS, which in ACME’s service is usually ACME itself.
- ACME cannot be custodian and sovereign provider at the same time. Sell custody products in the behavioural markets (UK, Singapore, Switzerland, Australia, most of the GCC and LATAM); in the EU sell HYOK connectors, controlled support access and the partner-venture structure.
Part A. What each regulator actually means by sovereignty
Only the European Union defines sovereignty structurally, as immunity from third-country law combined with EU ownership and operational control. The United Kingdom, Singapore, Switzerland and Australia define it behaviourally: no residency mandate, but hard duties around control, auditability, regulator access and exit. The Gulf states split the difference: sectoral localisation (hardest in Saudi Arabia for core banking and government data, and in the UAE for health data) plus provider registration and supervisory reach, but no ownership tests. Latin America defines sovereignty through transfer mechanics and central-bank cloud supervision, with no localisation for finance. The United States defines it in reverse: domestic enclaves for government data, and extraterritorial reach over US-controlled providers everywhere else. Read the differences before pricing them.
Part B. What AWS, Microsoft and Google sell as sovereign, and what it matches
Every hyperscaler now sells at least two tiers: a “sovereign by design” engineering tier (AWS’s term, launched with its Digital Sovereignty Pledge in November 2022; Microsoft’s Sovereign Cloud and EU Data Boundary; Google’s Data Boundary with External Key Management), and a partner-operated tier where an EU-controlled entity runs the hyperscaler’s technology (Microsoft’s Bleu and Delos Cloud; Google’s S3NS, T-Systems and the Thales-owned German entity announced in May 2026). Oracle made the same structural move with its EU Sovereign Cloud in 2023. The matrix below scores each offering against each regime on the published criteria, not the marketing.
The pattern underneath the portfolios
The engineering tier (AWS European Sovereign Cloud, Microsoft Sovereign Public Cloud, Google Data Boundary with EKM) is an engineering answer to an ownership question. It clears the behavioural regimes (UK, Singapore, Switzerland, Australia) comfortably and materially improves the EU private-sector transfer analysis, but it cannot clear regimes whose test is who owns and controls the provider: SecNumCloud 3.2 caps non-EU capital at 24 per cent for a single entity and 39 per cent in aggregate, the Cloud Sovereignty Framework caps SOV-2 for non-EU-controlled bidders, and CADA’s proposed high assurance tiers follow the same logic. The partner tier is the hyperscalers’ own admission of that limit: sovereignty at the top of the market is sold through EU-controlled operating companies, which is exactly the structure the roadmap in Section 10 recommends for ACME.
Read more: evidence for the matching matrix
Where we read it
AWS’s June 2025 announcement of the European Sovereign Cloud governance structure (new EU parent company, three German subsidiaries, EU-citizen leadership and advisory board, ESC-SRF control framework); AWS’s own sovereignty materials describing the four pledge pillars and the XKS kill switch; Microsoft’s Sovereign Cloud documentation (Sovereign Public Cloud with Data Guardian and external key management; Sovereign Private Cloud on Azure Local; National Partner Clouds); and the SecNumCloud 3.2 criteria as applied through the French State doctrine, under which S3NS’s PREMI3NS offering (Thales and Google Cloud) obtained qualification on 17 December 2025, confirmed in the ANSSI catalogue of 16 October 2026, while Bleu (Capgemini and Orange) remains in qualification with J1 passed in November 2025 and no wholly US-owned structure has qualified. AWS separately operated the European Sovereign Cloud without connection to its global network backbone for several hours on 24 October 2026, in a publicised exercise to demonstrate EU-independent operations.
How it impacts the decision
Marketing language is not portable across regimes. “Sovereign by design” satisfies a UK or Singapore supervisor and fails a French immunity test; a partner-operated cloud satisfies France but adds cost, reduced service parity and a slower feature cadence. Qualification status changes frequently: verify the current ANSSI list before relying on any cell of this matrix in a tender, noting that two further qualifications expire before end 2026 (Outscale’s IaaS Cloud on Demand on 30 November, OVHcloud’s Hosted Private Cloud on 29 December).
Official source: AWS European Sovereign Cloud governance announcement ↗ Official source: Microsoft Sovereign Cloud ↗Part C. Keys decide sovereignty
What is actually encrypted, and who can undo it
The envelope model
Data is encrypted with a data encryption key (DEK); DEKs are wrapped by a key encryption key (KEK) held in a KMS or HSM. Storage-level encryption at rest protects against stolen or decommissioned media. It does not protect against the provider: the provider’s KMS holds the KEK and decrypts on demand whenever its services, or anyone who can compel them, ask.
CMEK and BYOK
Customer-managed or customer-supplied keys: the customer generates or imports the KEK into provider-operated infrastructure (AWS KMS, Azure Key Vault or Managed HSM, Google Cloud KMS). The customer gains rotation, revocation and audit control, but the key material lives in systems the provider operates and the provider’s services call, so a compelled provider can still produce readable data.
HYOK and external key management
Hold your own key: the KEK never enters the cloud. AWS KMS External Key Store (XKS) proxies every decrypt to a customer-run key manager (Thales CipherTrust, Luna HSM); Google Cloud EKM does the same via Fortanix, Futurex, Thales or Virtru, adding Key Access Justifications; Azure Managed HSM external key management keeps the KEK in a customer-operated HSM outside Microsoft infrastructure, which Microsoft itself describes as a last-resort option where external key custody is mandated. AWS markets XKS as a kill switch: disable the external store and the cloud data becomes unreadable.
Application layer and in use
Client-side or application-layer encryption protects data before the cloud ever sees clear text; Microsoft Double Key Encryption applies this to Microsoft 365 with one customer-held key and one Azure-held key, though it requires Azure connectivity and is not air-gap capable. Confidential computing protects data in use. Only application-layer encryption with customer-held keys defeats the provider-access problem outright.
“At rest” is not the question regulators are asking
Every regime in Part A treats encryption at rest as table stakes. The decisive question is who can make the data readable: whoever controls the KEK controls the data. That is why the EDPB, MAS, DORA and the PRA all write key custody and key management, not ciphertext, into their expectations, and why a provider-encrypted workload with provider-held keys transfers no real protection against the provider’s own jurisdiction.
Read more: the doctrine behind this panel
Where we read it
EDPB Recommendations 01/2020, Use Case 1 (encryption is an effective supplementary measure for storage and backup only where the keys are retained solely by the exporter or a trusted entity in the EEA), Use Case 6 (where a cloud provider needs clear-text access and holds the keys, the EDPB is incapable of envisioning an effective technical measure) and Use Case 7 (routine remote access: transport and at-rest encryption together remain insufficient if the importer holds the keys); AWS’s sovereignty deck describing XKS as a kill switch; Microsoft Learn’s Managed HSM documentation describing external key management as a last-resort custody option.
How it impacts the decision
This is the cheapest sovereignty upgrade in the entire atlas: no corporate restructuring, just key architecture. For most EU private-sector transfers, moving the KEK out of provider custody converts a borderline Schrems II assessment into a defensible one.
Official source: EDPB Recommendations 01/2020 (PDF) ↗ Official source: Microsoft Learn, Managed HSM overview ↗What each regulator asks for, in substance
HSM: physical or as a service, and does location matter
Physical or dedicated HSM
Tamper-evident hardware validated to FIPS 140-3 Level 3 (or EN 419 221-5 for eIDAS qualified trust services), operated under m-of-n quorum custody. In practice mandatory for classified, defence and sovereign-qualified workloads, because it gives the key holder sole physical and logical custody. The costs are latency, capacity planning and round-the-clock key-management operations.
HSM as a service
Provider-dedicated HSMs (single-tenant, FIPS 140-3 Level 3, customer-specific security domains, as in Azure Managed HSM or AWS CloudHSM) are sound commercial assurance and satisfy MAS, PRA, APRA, FINMA and DORA expectations. But for sovereignty-tier workloads a dedicated HSM operated by an entity of the very jurisdiction being defended against changes nothing: custody, not hardware, is the test.
Custody beats geography
Should the HSM sit outside the country or region to preserve sovereign status? The question inverts the real test. The EDPB assesses who controls the keys, not where the box sits. An HSM in Frankfurt operated by a US-controlled entity stays reachable through the operator; moving the same HSM outside the country changes nothing if the same entity still operates it, and it costs latency, availability and supervisory access (MAS retrievability, PRA and APRA access rights, FINMA audit). Conversely, an HSM located outside the EU but operated solely by the customer, or by a genuinely EU-controlled trusted entity, can still satisfy the sole-custody condition of Use Case 1. Choose the operator first; then co-locate the hardware near the workloads it serves.
If ACME manages the HSM
Four plausible operating models for an ACME-branded key service, scored against the regimes. The rows assume competent engineering throughout; only custody changes.
The commercial conclusion for ACME
ACME cannot be the key custodian and the sovereign provider at the same time. In sovereignty-sensitive deals, custody belongs to the customer or to a genuinely EU-controlled partner; ACME’s product answer is first-class HYOK and external-key-management connectors, support workflows that never require clear-text access (EDPB Use Case 7), and an ACME-operated HSM service reserved for the United Kingdom, Singapore, Switzerland and Australia, where supervisors accept provider-operated key management subject to evidenced controls.
Read more: basis for the ACME custody rows
Where we read it
EDPB 01/2020 Use Cases 1, 6 and 7 (sole-custody condition; provider-held keys defeat the measure); the CLOUD Act’s reach over data within a US provider’s possession, custody or control regardless of where stored; SecNumCloud 3.2 ownership caps (24 per cent single non-EU entity, 39 per cent aggregate); DORA Article 9(4)(d) and Delegated Regulation (EU) 2024/1774 Articles 6 and 7 (encryption policy and key lifecycle duties sit on the financial entity, which may outsource operation but not accountability); MAS TRM chapter 9 and CPS 234, which test control effectiveness rather than the nationality of the key operator.
How it impacts the decision
The rows convert a legal doctrine into a product roadmap: the managed-HSM business is viable in four of the six jurisdictions studied, and in the EU it is viable precisely in the segments where sovereignty is behavioural rather than structural. Selling custody in Paris is a legal failure; selling custody in London, Singapore, Zurich and Sydney is a growth business.
Official source: US Department of Justice, CLOUD Act resources ↗ Official source: Delegated Regulation (EU) 2024/1774 ↗When ACME is the customer: the four-party key problem
Every CMK and BYOK feature the hyperscalers advertise answers one question: can the cloud provider’s customer keep the provider away from the keys? When ACME builds its managed service on AWS, Azure or Google Cloud, ACME is that customer, and ACME’s BYOK protects ACME from the hyperscaler. It does nothing for ACME’s client, whose regulatory question is different: can the client keep ACME, and everyone who can compel ACME, away from the client’s data? The chain runs client (controller) to ACME (processor) to hyperscaler (sub-processor), and custody is tested link by link. A client cannot bring its own keys to ACME’s platform unless ACME builds the capability, and most SaaS platforms never do.
Whose keys protect whom
ACME’s CMK or BYOK inside AWS KMS sets the trust boundary between ACME and AWS. The client’s EDPB Use Case 1 test runs one link up, against ACME: are the keys retained solely by the exporter or an EEA-trusted entity? If ACME operates the KMS account, ACME holds the keys in the client’s analysis, and a US-controlled ACME fails the sole-custody condition regardless of where the KMS sits.
The per-tenant illusion
Client-dedicated KEKs inside ACME’s tenancy give separation of data, per-client crypto-shredding and clean exit. They do not give separation of custody: custody follows whoever operates the KMS account and the IAM policies around it, not the label on the key. Ten key rings under one operator are one point of compulsion.
The chain the client must document
DORA Article 28(3) makes the client maintain a register of information covering the whole chain, with Delegated Regulation (EU) 2025/532 detailing subcontractor mapping for critical or important functions; GDPR Article 28(4) flows processor duties down to the sub-processor; CBUAE, the PRA, MAS and APRA demand audit and access rights that must flow down contractually. The client must assess AWS under Schrems II although it has no contract with AWS. ACME’s transparency pack is therefore a sales asset, not admin. Note the UK divergence: under the ICO’s January 2026 guidance, a processor returning data to its own instructing controller is not making a restricted transfer at all, which relaxes this chain in one jurisdiction while the EU analysis stays strict.
Support is the leak
EDPB Use Case 7: routine remote support that can see clear text defeats transport plus at-rest encryption even with customer keys. ACME’s support engineers troubleshooting client incidents are the access path the doctrine worries about. The fixes are architectural: just-in-time, client-approved key release; field-level application encryption for the most sensitive data; EU-only support pods for sovereignty-tier deals.
Where the regulations and the reality break
What this means for ACME’s product roadmap
Five build decisions follow. First, per-tenant KEKs as table stakes, so each client can be rotated, suspended and crypto-shredded independently. Second, a client-operated HYOK option: a key proxy the client runs (the XKS pattern one level up) that ACME’s platform calls for every unwrap, with Key Access Justifications-style logging the client can see. Third, support gated behind just-in-time, client-approved key release with tamper-evident logs, closing the Use Case 7 hole. Fourth, a DORA-ready transparency pack as standard: the full chain map with legal entities and LEIs, data locations, subcontractors and the exit plan, refreshed quarterly. Fifth, tiered custody: ACME-operated key services sold into the behavioural regimes (United Kingdom, Singapore, Switzerland, Australia, most of the GCC and LATAM), and in sovereignty-tier deals the EU-controlled venture operates the platform so the custody question dissolves at the structure level.
Read more: basis for the breaking-points analysis
Where we read it
EDPB Recommendations 01/2020, Use Cases 1, 6 and 7 (the exporter test runs against the entity that holds the keys; provider-held keys defeat the measure; routine remote access reopens it); DORA Articles 28(1)(a), 28(3) and 30 and Delegated Regulation (EU) 2025/532 (full-chain register and subcontractor mapping; the 2024 ESA register dry run, in which only 6.5 per cent of nearly 1,000 participating firms passed all 116 data-quality checks, with failures concentrated in subcontractor data); the CSA’s key-model taxonomy (CMK stores and uses keys inside the provider’s KMS; HYOK keeps keys in the customer’s KMS); Microsoft’s Double Key Encryption documentation (no search or co-authoring over DKE-protected content, requires Azure connectivity); AWS’s description of XKS as a kill switch; CBUAE subcontracting disclosure and advance-notification duties.
How it impacts the decision
Every breaking point above is a place where a competitor with weaker architecture will quietly misrepresent compliance to win the deal. ACME’s option is to make the breaking points explicit in its own materials: a provider that explains where HYOK hurts is more credible to a risk committee than one that claims keys solve everything, and the transparency pack converts a diligence cost into a differentiator.
Official source: EDPB Recommendations 01/2020 (PDF) ↗ Official source: Delegated Regulation (EU) 2025/532 ↗Roadmap for cross-border expansion
A phased programme that converts structural disadvantage into managed compliance, sequenced so that early phases unlock deals without waiting for the end state.
Official sources
Primary instruments and official guidance only. Where an instrument is contested or in transition, the entry says so.
What has changed in this atlas
- 5 November 2026 (later). Table usability: drag-to-resize handles on the first column of every wide matrix, widths persisted per device; evidence panels inside tables now expand as a full-width row beneath the row instead of inside the narrow sticky cell.
- 5 November 2026. November regulatory watch: COM(2025) 837 numbering corrected across the atlas; Bleu qualification status reconciled with the ANSSI catalogue of 16 October 2026; Chile Senate Bill 18.623-07 (15 October 2027 delay) added; UK Data (Use and Access) Act and ICO January 2026 guidance reflected; Saudi PDPL enforcement note; AWS European Sovereign Cloud disconnection exercise added. Three new source entries.
- 4 November 2026. Section 09 expanded to eleven jurisdictions with GCC and LATAM rows; new four-party key-chain analysis, breaking-points table and per-jurisdiction key-regulation rows; offering matrix and HSM scenario tables extended.
- 3 November 2026. First column and header row frozen on every wide matrix, with a scroll shadow so hidden columns are discoverable.
- 31 October 2026. Section 09 launched: sovereignty definitions by regulator, hyperscaler offering matrix, key-management doctrine (CMEK, BYOK, HYOK) and ACME HSM custody scenarios.