# Sovereign Cloud Architecture: [Workload portfolio or platform]

> Architecture document for workloads with digital sovereignty
> requirements: the drivers, a requirement catalogue across data,
> operational and software (technology) sovereignty, workload
> classifications, the design concerns of locality, access control,
> continuity, portability and transparency, the mapping from each
> requirement to controls, enforcement and evidence, key management and
> operator access, provider and deployment options, a gated evaluation,
> exit and switching under the EU Data Act Chapter VI, and the decision
> with residual risk. It draws on public provider guidance (Microsoft
> Cloud Adoption Framework sovereignty guidance, AWS Digital Sovereignty
> Lens, both checked October 2026) and on the European Commission's
> Cloud Sovereignty Framework, all cited by name. Replace every
> `[bracketed]` value and every row marked *Example*. This is a
> documentation format, not legal advice; check the current official
> texts and a qualified professional.

<!--
Guidance: How to use this template
- Use it for the architecture: which controls, which platform, which
  provider. The legal analysis of personal data transfers, transfer
  impact assessments and localisation laws belongs in
  `compliance/data-residency-sovereignty-assessment`; link to it and do
  not repeat it.
- Work in this order: 1 (drivers) -> 2 (requirements with sources) -> 3
  (classifications and inventory) -> 4 and 5 (design concerns and
  control mapping) -> 6 (keys and operator access) -> 7 and 8 (options
  and evaluation) -> 9 (exit) -> 10 to 13 (jurisdictions, evidence,
  decision, traceability).
- Base every requirement on a named driver. A requirement without a
  driver is a preference; record it as such or remove it.
- Product names, offerings and regional availability change often.
  Date every provider statement and check it on the day of the decision.
- The worked examples describe Calvera Pensions Agency, a fictional
  public pension administrator in an EU member state. Delete them once
  your rows exist.
-->

## Document control

<!-- Guidance: Identify the workloads in scope, the sovereignty sponsor who accepts residual risk, and the legal and security reviewers. A new requirement source or a new deployment model is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [SCA-001] |
| Scope | [Workloads, platform or business unit] |
| Executive sovereignty sponsor | [@sponsor] |
| Architecture owner | [@cloud-architect] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Approvers/reviewers | [@ciso], [@dpo], [@legal-counsel], [@platform-lead], [@procurement] |
| Last updated | YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Jurisdictions in scope | [EU member state, UK, US, other] |
| Linked assessments | [`compliance/data-residency-sovereignty-assessment` ID], [DPIA ID], [exit plan ID] |
| Provider documentation checked on | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Executive sovereignty sponsor | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Decision] | YYYY-MM-DD |
| Data protection officer | [@name] | [Decision] | YYYY-MM-DD |
| Legal counsel | [@name] | [Decision] | YYYY-MM-DD |
| Platform owner | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft from the requirement workshop |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Classifications agreed with legal, security and the pensions business |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Option S2 approved for class C workloads with residual risks accepted |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Scope, drivers and objectives](#1-scope-drivers-and-objectives)
2. [Sovereignty requirements](#2-sovereignty-requirements)
3. [Classifications and workload inventory](#3-classifications-and-workload-inventory)
4. [Design concerns](#4-design-concerns)
5. [Control mapping](#5-control-mapping)
6. [Key management and operator access](#6-key-management-and-operator-access)
7. [Provider and deployment options](#7-provider-and-deployment-options)
8. [Option evaluation](#8-option-evaluation)
9. [Continuity, portability and exit](#9-continuity-portability-and-exit)
10. [Jurisdiction examples](#10-jurisdiction-examples)
11. [Assurance and evidence](#11-assurance-and-evidence)
12. [Decision, residual risk and roadmap](#12-decision-residual-risk-and-roadmap)
13. [Traceability](#13-traceability)
14. [Glossary and references](#14-glossary-and-references)

## 1. Scope, drivers and objectives

<!-- Guidance: List the sources that create sovereignty obligations and the objectives that follow. Questions to answer: which laws, contracts, policies and risk decisions apply, and what happens if each is not met? Pitfall: treating sovereignty as a single yes or no property instead of a set of requirements of different strength. -->

### 1.1 Scope

[Workloads and data in scope, environments (production, recovery,
development), and what is out of scope.]

*Example:* Calvera Pensions Agency runs a member portal, a contributions
engine, a document archive and an analytics platform. Its board asks for
a target architecture that meets national public sector cloud policy and
keeps pension operations running if access to a non-EU provider is
disrupted.

### 1.2 Drivers

| Driver ID | Driver | Type | Jurisdiction | Consequence if not met | Owner |
|---|---|---|---|---|---|
| DRV-01 *(Example)* | National public sector cloud policy requiring data in the EU and customer key control for sensitive records | Government policy | [Member state] | Workload may not go live | [@cio] |
| DRV-02 *(Example)* | GDPR Chapter V on transfers of personal data | Law | EU | Fines and orders; see the residency assessment | [@dpo] |
| DRV-03 *(Example)* | Board risk decision: pension payments must continue for 90 days if a provider becomes unavailable | Internal risk policy | Organisation | Missed payments to members | [@coo] |
| DRV-04 *(Example)* | EU Data Act Chapter VI switching rights | Law | EU | Weaker exit position if contracts do not reflect them | [@procurement] |
| DRV-[NN] | [Driver] | [Law / Regulation / Policy / Contract / Risk decision] | [Jurisdiction] | [Consequence] | [@owner] |

### 1.3 Objectives

| Objective ID | Objective | Measure |
|---|---|---|
| OBJ-01 *(Example)* | Keep sensitive records and their keys under organisation control within the EU | 100% of class C data stores with customer-held keys in EU locations |
| OBJ-02 *(Example)* | No provider privileged access to class C data without approval | Every provider access request approved and logged |
| OBJ-03 *(Example)* | Sustain minimum pension operations through a provider disruption | Recovery of payment run within the agreed recovery time in an annual test |
| OBJ-04 *(Example)* | Retain a tested route to leave any provider | Exit test completed every two years |

## 2. Sovereignty requirements

<!-- Guidance: Translate each driver into specific, testable requirements, grouped as data, operational and software sovereignty. Questions to answer: what exactly must be true, for which workloads, and who owns the requirement? Pitfall: copying a provider's feature list as requirements, which makes the evaluation favour that provider. -->

The three groups below are a common way to organise sovereignty needs:

- **Data sovereignty**: where data and keys are, who can read them, and
  under which law.
- **Operational sovereignty**: who operates the platform, from where,
  with what oversight, and whether operations continue under
  disruption.
- **Software (technology) sovereignty**: dependence on specific
  software, supply chains and proprietary interfaces, and the ability to
  run or move workloads elsewhere.

| Req ID | Group | Requirement | Driver | Strength | Owner |
|---|---|---|---|---|---|
| SOV-REQ-01 *(Example)* | Data | Data at rest stays in approved EU locations, including backups and replicas | DRV-01, DRV-02 | Must | [@dpo] |
| SOV-REQ-02 *(Example)* | Data | Encryption at rest and in transit for all data | DRV-01 | Must | [@ciso] |
| SOV-REQ-03 *(Example)* | Data | Encryption keys for class C data are generated and held in hardware security modules the organisation controls | DRV-01 | Must for class C | [@ciso] |
| SOV-REQ-04 *(Example)* | Data | Data in use protected by confidential computing for the contributions engine | Risk decision | Should | [@ciso] |
| SOV-REQ-05 *(Example)* | Operational | Provider staff cannot access class C environments without approval by the organisation, and every access is logged | DRV-01 | Must for class C | [@ciso] |
| SOV-REQ-06 *(Example)* | Operational | Personnel with privileged operational access to class C environments are located in the EU | DRV-01 | Must for class C | [@cio] |
| SOV-REQ-07 *(Example)* | Operational | Minimum viable pension operations continue for 90 days without the primary provider | DRV-03 | Must | [@coo] |
| SOV-REQ-08 *(Example)* | Software | Workloads use open interfaces (Kubernetes, PostgreSQL, Apache Iceberg, S3-compatible object storage) where a choice exists | DRV-04 | Should | [@chief-architect] |
| SOV-REQ-09 *(Example)* | Software | Software bill of materials for platform components and a supplier register | Risk decision | Should | [@platform-lead] |
| SOV-REQ-10 *(Example)* | Software | Contracts reflect Data Act switching rights and a documented exit plan | DRV-04 | Must | [@procurement] |
| SOV-REQ-[NN] | [Data / Operational / Software] | [Requirement] | [Driver IDs] | [Must / Should / Could] | [@owner] |

## 3. Classifications and workload inventory

<!-- Guidance: Group requirements into a small number of classifications and assign each workload. Questions to answer: which combinations of requirements recur, and which workloads share them? Pitfall: one classification per workload, which multiplies controls and makes governance impossible. -->

Microsoft's CAF sovereignty guidance recommends a small set of
reusable classifications (three to five) so that workloads inherit a
control baseline rather than being assessed one by one. The
classifications below are an original example.

| Class | Requirements included | Typical data |
|---|---|---|
| A *(Example)* | SOV-REQ-01, SOV-REQ-02, SOV-REQ-08, SOV-REQ-10 | Public information, anonymised statistics |
| B *(Example)* | Class A plus SOV-REQ-07 | Internal operations, member communications |
| C *(Example)* | Class B plus SOV-REQ-03, SOV-REQ-04, SOV-REQ-05, SOV-REQ-06, SOV-REQ-09 | Pension records, contributions, bank details |

| Workload ID | Workload | Class | Current location | Gaps against class baseline | Treatment | Priority |
|---|---|---|---|---|---|---|
| WL-01 *(Example)* | Member portal | B | Public cloud EU region | No tested recovery outside primary provider | Mitigate (section 9) | 2 |
| WL-02 *(Example)* | Contributions engine | C | On-premises | End-of-life hardware; target platform needed | Migrate to chosen option | 1 |
| WL-03 *(Example)* | Document archive | C | On-premises | Keys in software key store | Mitigate (section 6) | 1 |
| WL-04 *(Example)* | Analytics platform | A | Public cloud EU region | None | Accept | 3 |
| WL-[NN] | [Workload] | [Class] | [Location] | [Gaps] | [Mitigate / Accept / Exception] | [1 to 3] |

## 4. Design concerns

<!-- Guidance: Check each class against the five design concerns and record the trade-offs between them. Questions to answer: where does a locality rule weaken continuity, and which concern takes precedence? Pitfall: maximising locality and isolation everywhere, which concentrates risk in one site or provider. -->

The AWS Digital Sovereignty Lens (last updated 15 September 2026) frames
sovereignty as five architectural questions: locality, access control,
continuity, portability and interoperability, and transparency and
auditability. The lens notes that these concerns trade off against each
other, and that transparency is the one that proves the other four. The
framing is useful with any provider.

| Concern | Question for this design | Requirements | Class A | Class B | Class C |
|---|---|---|---|---|---|
| Locality | Where do workloads run, data rest, and operators sit? | SOV-REQ-01, SOV-REQ-06 | EU region | EU region | EU locations, EU operators |
| Access control | Who can reach data and under what authority? | SOV-REQ-02, SOV-REQ-03, SOV-REQ-05 | Standard | Standard | Customer keys, approved provider access |
| Continuity | Does the workload keep running when conditions change? | SOV-REQ-07 | Provider resilience | Recovery outside primary provider | Recovery outside primary provider |
| Portability and interoperability | Can we move or run elsewhere? | SOV-REQ-08, SOV-REQ-10 | Exit plan | Exit plan | Exit plan, tested |
| Transparency and auditability | Can we prove the controls work? | All | Inherited reports | Inherited reports and own logs | Continuous evidence (section 11) |

Trade-offs recorded:

| TO ID | Trade-off | Decision | Accepted by |
|---|---|---|---|
| TO-01 *(Example)* | Strict EU locality limits recovery to EU locations | Recovery site must be in a second EU country | [@sponsor] |
| TO-02 *(Example)* | Customer-held external keys add a dependency: if the key service is down, data is unreadable | Run the key service in two sites with tested failover | [@ciso] |

## 5. Control mapping

<!-- Guidance: For every requirement, name the control, how it is enforced, the evidence, and who is responsible under the shared responsibility model. Questions to answer: is the control preventive or detective, and where does the evidence come from? Pitfall: controls without evidence, which turn sovereignty into an assertion. -->

| Ctrl ID | Requirement | Control (provider-neutral) | Enforcement | Mode | Evidence | Responsible |
|---|---|---|---|---|---|---|
| CTL-01 *(Example)* | SOV-REQ-01 | Deny resource creation outside approved locations | Organisation policy at the account or subscription root | Preventive | Policy compliance report | Organisation |
| CTL-02 *(Example)* | SOV-REQ-01 | Residency tag on every data store; drift alerts | Detective configuration rules | Detective | Configuration history | Organisation |
| CTL-03 *(Example)* | SOV-REQ-02 | Encryption at rest by default; TLS 1.2 or later; private endpoints | Platform defaults plus policy | Preventive | Policy report | Shared |
| CTL-04 *(Example)* | SOV-REQ-03 | Customer-managed keys in an HSM the organisation controls (managed single-tenant HSM or external key manager) | Policy requiring customer keys on class C stores | Preventive | Key inventory, policy report | Organisation |
| CTL-05 *(Example)* | SOV-REQ-04 | Confidential virtual machines for the contributions engine | Allowed SKU list | Preventive | Inventory | Organisation |
| CTL-06 *(Example)* | SOV-REQ-05 | Provider access approval workflow with time-bound sessions and logging | Provider access approval feature plus internal approver group | Preventive | Approval log | Shared |
| CTL-07 *(Example)* | SOV-REQ-06 | Contractual commitment on location of privileged operations staff | Contract clause and provider attestation | Contractual | Contract, audit report | Provider |
| CTL-08 *(Example)* | SOV-REQ-07 | Sovereign recovery environment for minimum viable operations | Recovery design and annual test | Corrective | Test report | Organisation |
| CTL-09 *(Example)* | SOV-REQ-08 | Open-interface services preferred in technology selection | Architecture review gate | Directive | Review records | Organisation |
| CTL-10 *(Example)* | SOV-REQ-10 | Exit plan, data export test, Data Act clauses in contract | Procurement checklist and exit test | Directive | Exit test report | Organisation |
| CTL-[NN] | [Req] | [Control] | [How] | [Preventive / Detective / Corrective / Contractual / Directive] | [Evidence] | [Organisation / Provider / Shared] |

Prefer preventive, automated controls where a deviation is not
acceptable, and detective controls with remediation where managed
exceptions are allowed. Build controls into the landing zone
(`architecture/landing-zone-design`) so workloads inherit them.

## 6. Key management and operator access

<!-- Guidance: Decide where keys live, who can use them, and how provider operator access is approved and audited. Questions to answer: can the provider decrypt data without our action, and what happens to availability if our key service fails? Pitfall: choosing external keys for every workload, which adds latency and outage risk where it is not required. -->

### 6.1 Key custody options

| Option | Who holds the key material | Sovereignty strength | Availability and cost impact | Use for |
|---|---|---|---|---|
| Provider-managed keys | Provider | Low | Simplest | Class A |
| Customer-managed keys in provider key service | Provider HSMs, customer controls lifecycle | Medium | Low | Class B |
| Customer-managed keys in single-tenant managed HSM | Dedicated HSM in provider facility, customer-only administration | High | Medium | Class C, default |
| External key manager or hold-your-own-key | HSM outside the provider, operated by organisation or a third party | Highest | Higher latency; key service outage makes data unreadable | Class C where policy requires keys outside the provider |

### 6.2 Operator access design

| Item | Design |
|---|---|
| Normal operations | Workloads designed so that neither provider nor internal operators need access to customer data in routine work |
| Provider support access | [Provider approval feature], approvers from [group], maximum session [hours], reasons recorded |
| Internal privileged access | Just-in-time elevation, phishing-resistant authentication, session recording |
| Logging | Provider access logs and internal privileged logs sent to [SIEM] in an EU location, retained [period] |
| Review | Monthly review of all approvals by [@ciso-delegate] |

## 7. Provider and deployment options

<!-- Guidance: Describe the deployment models available and the concrete offerings considered, each with the date it was checked. Questions to answer: which models meet the class C requirements, and what does each cost in responsibility? Pitfall: comparing marketing names rather than the controls and responsibilities behind them. -->

### 7.1 Deployment models (provider-neutral)

| Model | Description | Who operates | Typical fit |
|---|---|---|---|
| Public cloud with sovereignty controls | Global provider's regions in the jurisdiction, with policies, customer keys and access approval | Provider | Classes A and B; class C where operations-location requirements are met |
| Provider-operated sovereign partition | Separate infrastructure and control plane run by a provider entity and staff in the jurisdiction | Provider (local entity) | Class C with operator-location requirements |
| Partner-operated national cloud | Provider technology run by a local partner under national governance | Local partner | Class C where independence from the global provider is required |
| Private cloud on own or designated hardware | Organisation operates the infrastructure, connected or disconnected | Organisation | Class C, sovereign recovery environment, disconnected needs |
| Regional or national cloud provider | Provider headquartered in the jurisdiction | Regional provider | Any class, subject to service fit |

### 7.2 Offerings checked (examples, dated)

| Provider | Offering | Model | Notes | Checked on |
|---|---|---|---|---|
| Microsoft | Microsoft Sovereign Cloud: Sovereign Public Cloud, Sovereign Private Cloud (Azure Local, connected or disconnected), National Partner Clouds (limited geographies, eligible customers) | Public with controls, private, partner-operated | CAF sovereignty guidance gives a decision tree, requirement catalogue and control mapping per model | 2026-10-30 |
| AWS | AWS European Sovereign Cloud; Control Tower digital sovereignty controls; Outposts for on-premises | Sovereign partition, public with controls, private | Digital Sovereignty Lens available as a custom lens for the Well-Architected Tool | 2026-10-30 |
| [Other provider] | [Offering] | [Model] | [Notes] | YYYY-MM-DD |

Check service availability per offering: sovereign partitions and
partner clouds often carry fewer services than the global cloud, which
affects SOV-REQ-08 and the platform roadmap.

### 7.3 Procurement frameworks

The European Commission's Cloud Sovereignty Framework, used in the
Commission's Cloud III Dynamic Purchasing System tender (contract awarded
in April 2026, as reported on the Commission's explainer page), groups sovereignty criteria into eight categories
(strategic, legal and jurisdictional, data and AI, operational, supply
chain, technological, security and compliance, environmental
sustainability) and rates providers by Sovereignty Effectiveness
Assurance Levels (SEAL). Use the categories as a cross-check for
completeness of section 2. Check the current framework document and
level definitions on the Commission website before using them in
procurement.

## 8. Option evaluation

<!-- Guidance: Gate options on must-have requirements first, then score the remaining options with weights agreed before scoring. Questions to answer: which options fail a must, and what is the full-life cost of the rest? Pitfall: a weighted score that lets a high score elsewhere compensate for a failed must-have requirement. -->

### 8.1 Options

| Option | Description |
|---|---|
| S1 *(Example)* | Public cloud EU regions with sovereignty controls (CTL-01 to CTL-06) |
| S2 *(Example)* | Provider-operated EU sovereign partition |
| S3 *(Example)* | Partner-operated national cloud |
| S4 *(Example)* | Private cloud on agency-owned hardware in two EU data centres |

### 8.2 Must-have gate for class C

| Must requirement | S1 | S2 | S3 | S4 |
|---|---|---|---|---|
| SOV-REQ-01 EU locations | Pass | Pass | Pass | Pass |
| SOV-REQ-03 customer-controlled HSM keys | Pass | Pass | Pass | Pass |
| SOV-REQ-05 approved provider access | Pass | Pass | Pass | Pass (no provider) |
| SOV-REQ-06 EU-located privileged operators | Fail *(Example: global support model)* | Pass | Pass | Pass |
| SOV-REQ-07 90-day minimum operations without primary provider | Pass with recovery design | Pass with recovery design | Pass with recovery design | Pass with second site |
| SOV-REQ-10 Data Act clauses and exit plan | Pass | Pass | Pass | Not applicable (own platform) |

S1 fails the gate for class C and stays the default for classes A and B.

### 8.3 Weighted comparison

Scores run from 1 (poor) to 5 (strong); the weighted score is the sum of
weight times score divided by 100. S1 is shown for information only.

| Criterion | Weight | S1 | S2 | S3 | S4 |
|---|---|---|---|---|---|
| Coverage of should and could requirements | 35 | 3 | 4 | 5 | 5 |
| Service availability for the workload | 15 | 5 | 4 | 2 | 2 |
| Continuity and resilience | 15 | 5 | 4 | 3 | 2 |
| Portability and exit | 10 | 4 | 4 | 3 | 4 |
| Five-year cost (section 8.4) | 15 | 5 | 4 | 3 | 1 |
| Time to value | 10 | 5 | 4 | 2 | 1 |
| **Weighted score** *(Example)* | **100** | **4.20** | **4.00** | **3.45** | **3.00** |

### 8.4 Five-year cost

| Option | One-off cost (EUR million) | Annual run cost (EUR million) | Five-year total (EUR million) |
|---|---|---|---|
| S1 *(Example)* | 0.25 | 1.20 | 6.25 |
| S2 *(Example)* | 0.30 | 1.35 | 7.05 |
| S3 *(Example)* | 0.40 | 1.60 | 8.40 |
| S4 *(Example)* | 1.80 | 2.10 | 12.30 |

Five-year total = one-off cost + 5 x annual run cost. Include staff,
licences, hardware refresh and the recovery environment; see
`architecture/tco-analysis` for the full method.

## 9. Continuity, portability and exit

<!-- Guidance: Design how the workload survives disruption and how it leaves a provider. Questions to answer: what is the minimum viable operation, where does it run, how long does an exit take, and what do contracts guarantee? Pitfall: an exit plan that has never been tested. -->

### 9.1 Continuity

| Item | Design |
|---|---|
| Minimum viable operations | [Example: monthly pension payment run, member enquiries by phone] |
| Recovery environment | [Example: private cloud capacity in a second EU country able to run the payment run] |
| Data replication | [Example: daily encrypted export of contributions and payment data to the recovery environment, keys held by the agency] |
| Recovery targets | RTO [hours], RPO [hours] |
| Test | [Annual, scenario: primary provider unavailable for 30 days] |

Resilience design detail belongs in
`architecture/resilience-tiering-ha-dr-design`. Financial entities in
the EU also have exit strategy duties under the Digital Operational
Resilience Act (Regulation (EU) 2022/2554, Article 28, applicable from
17 January 2025); see `compliance/dora-ict-third-party-register`.

### 9.2 EU Data Act switching (Chapter VI)

Regulation (EU) 2023/2854 (Data Act) applies from 12 September 2025.
Chapter VI (Articles 23 to 31) gives customers of data processing
services rights to switch provider or move to on-premises. In summary,
as published (check the consolidated text and a qualified professional):

| Article | Topic | Summary in original words |
|---|---|---|
| Art. 23 | Removing obstacles | Providers must not impose obstacles that prevent customers from terminating, switching or porting data and digital assets |
| Art. 25 | Contract terms | Switching on notice of at most two months, then a transitional period of at most 30 calendar days (longer, up to seven months, only if the provider shows it is technically unfeasible; the customer may extend once), and at least 30 calendar days to retrieve data |
| Art. 29 | Switching charges | Reduced charges, not above the provider's direct costs, until 12 January 2027; no switching charges from that date |
| Art. 30 | Technical aspects | Duties on functional equivalence for infrastructure services and on open interfaces and export formats for other services |

The Commission's Data Act page states that switching and data egress
charges will be fully removed from 12 January 2027. The German
Bundesnetzagentur fact sheet summarises the notice and transitional
periods. These are dated summaries, not legal advice.

### 9.3 Exit plan summary

| Item | Value |
|---|---|
| Exit triggers | [Provider change of control, law change, failed audit, price change, strategic decision] |
| Target destination | [Second provider, private cloud, regional provider] |
| Data export formats | [Example: PostgreSQL dumps, Apache Iceberg tables, object storage in open formats] |
| Estimated exit duration | [Weeks] |
| Last exit test | YYYY-MM-DD, result [link] |

## 10. Jurisdiction examples

<!-- Guidance: Record the laws and schemes that shape requirements in each jurisdiction in scope, with dates and official links. Questions to answer: which rules apply, when were they checked, and which requirement do they drive? Pitfall: stating foreign-access law conclusions without legal review. -->

The rows below are dated examples, not a complete list and not legal
advice. Check the current official text and a qualified professional.

| Jurisdiction | Instrument | Relevance | Official source | Checked |
|---|---|---|---|---|
| EU | Regulation (EU) 2023/2854 (Data Act), Chapters VI and VII (Article 32 on international governmental access to non-personal data) | Switching rights; provider safeguards against unlawful third-country access | eur-lex.europa.eu, CELEX 32023R2854 | 2026-10-30 |
| EU | Regulation (EU) 2016/679 (GDPR), Chapter V | Transfers of personal data; analysed in the residency assessment | eur-lex.europa.eu, CELEX 32016R0679 | YYYY-MM-DD |
| EU | European Commission Cloud Sovereignty Framework | Procurement criteria and assurance levels | commission.europa.eu | 2026-10-30 |
| UK | NCSC Cloud Security Principles (14 principles, version 2.1, reviewed 7 June 2023) | Assurance questions for cloud services, including data location, personnel security and supply chain | ncsc.gov.uk/collection/cloud/the-cloud-security-principles | 2026-10-30 |
| US | 18 U.S.C. 2713 (CLOUD Act provision) | US providers may be required to preserve or disclose data in their possession, custody or control regardless of where it is stored | law.cornell.edu/uscode/text/18/2713 | 2026-10-30 |
| [Jurisdiction] | [Instrument] | [Relevance] | [URL] | YYYY-MM-DD |

## 11. Assurance and evidence

<!-- Guidance: Decide what evidence proves each control and how it is produced continuously. Questions to answer: which evidence is inherited from provider reports, which is produced by our own tooling, and who reviews it? Pitfall: relying on provider certifications for controls that are the organisation's responsibility. -->

| Evidence ID | Evidence | Controls | Source | Frequency | Reviewer |
|---|---|---|---|---|---|
| EVD-01 *(Example)* | Policy compliance report for location and encryption | CTL-01, CTL-03, CTL-04 | Cloud policy service | Continuous, monthly review | [@platform-lead] |
| EVD-02 *(Example)* | Provider access approval log | CTL-06 | Provider access approval feature | Continuous, monthly review | [@ciso-delegate] |
| EVD-03 *(Example)* | Provider audit reports (for example SOC 2, ISO/IEC 27001 certificate, C5) | CTL-03, CTL-07 | Provider trust portal | Yearly | [@risk-officer] |
| EVD-04 *(Example)* | Recovery and exit test reports | CTL-08, CTL-10 | Internal tests | Yearly and every two years | [@coo] |
| EVD-05 *(Example)* | Key inventory and rotation report | CTL-04 | HSM or key manager | Quarterly | [@ciso] |
| EVD-[NN] | [Evidence] | [Controls] | [Source] | [Frequency] | [@reviewer] |

## 12. Decision, residual risk and roadmap

<!-- Guidance: Record the decision per class, the residual risks and who accepted them, and the steps to get there. Questions to answer: what is accepted, by whom, until when? Pitfall: approval without a named risk owner and a review date. -->

### 12.1 Decision

| Class | Deployment model | Option | Reason | Decision record |
|---|---|---|---|---|
| A *(Example)* | Public cloud with controls | S1 | Meets all requirements at lowest cost | ADR-[NN] |
| B *(Example)* | Public cloud with controls and sovereign recovery | S1 plus recovery in S4 capacity | Meets SOV-REQ-07 | ADR-[NN] |
| C *(Example)* | Provider-operated sovereign partition | S2 | Passes all must requirements; highest score among gated options (4.00) | ADR-[NN] |

### 12.2 Residual risks

| Risk ID | Residual risk | Likelihood | Impact | Accepted by | Review by |
|---|---|---|---|---|---|
| RR-01 *(Example)* | Sovereign partition offers fewer services; some managed services unavailable | High | Medium | [@sponsor] | YYYY-MM-DD |
| RR-02 *(Example)* | Legal exposure of a provider's parent company to foreign orders cannot be fully removed by technical controls | Medium | High | [@sponsor] after legal advice | YYYY-MM-DD |
| RR-03 *(Example)* | Key service outage makes class C data unavailable | Low | High | [@ciso] | YYYY-MM-DD |
| RR-[NN] | [Risk] | [L] | [I] | [@name] | YYYY-MM-DD |

### 12.3 Roadmap

| Step | Scope | Due | Owner |
|---|---|---|---|
| 1 *(Example)* | Landing zone controls CTL-01 to CTL-04 for classes A and B | YYYY-MM-DD | [@platform-lead] |
| 2 *(Example)* | Sovereign partition landing zone and migration of WL-02, WL-03 | YYYY-MM-DD | [@cloud-architect] |
| 3 *(Example)* | Recovery environment and first recovery test | YYYY-MM-DD | [@coo] |
| 4 *(Example)* | First exit test for WL-01 | YYYY-MM-DD | [@procurement] |

## 13. Traceability

<!-- Guidance: Trace every driver to requirements, controls, evidence and the option that meets them. Questions to answer: does any requirement lack a control, or any control lack evidence? Pitfall: controls added because a provider offers them, with no requirement behind them. -->

| Driver | Requirements | Controls | Evidence | Option |
|---|---|---|---|---|
| DRV-01 *(Example)* | SOV-REQ-01 to SOV-REQ-06 | CTL-01 to CTL-07 | EVD-01, EVD-02, EVD-03, EVD-05 | S1 (A, B), S2 (C) |
| DRV-02 *(Example)* | SOV-REQ-01 | CTL-01, CTL-02 | EVD-01 | All |
| DRV-03 *(Example)* | SOV-REQ-07 | CTL-08 | EVD-04 | S4 capacity for recovery |
| DRV-04 *(Example)* | SOV-REQ-08, SOV-REQ-10 | CTL-09, CTL-10 | EVD-04 | All |
| [Driver] | [Reqs] | [Controls] | [Evidence] | [Option] |

## 14. Glossary and references

<!-- Guidance: Define terms readers will meet and list the sources with the date each was checked. -->

### 14.1 Glossary

| Term | Meaning in this document |
|---|---|
| Digital sovereignty | The ability to control data, technology and operations in line with the laws, policies and risk decisions the organisation chooses |
| Data sovereignty | Control over where data and keys are and who can access them under which law |
| Operational sovereignty | Control over who operates the platform, from where, with what oversight, and continuity under disruption |
| Software (technology) sovereignty | Limited dependence on specific software, suppliers and proprietary interfaces |
| Classification | A reusable group of sovereignty requirements that workloads inherit |
| Sovereign partition | Cloud infrastructure and control plane separated from a provider's global cloud and run under a local entity |
| External key manager | Key management outside the provider, used by cloud services through an interface |
| Switching | Moving from one data processing service to another or to on-premises, in the sense of the Data Act |
| Minimum viable operations | The smallest set of services the organisation must keep running during a disruption |

### 14.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| Microsoft, Cloud Adoption Framework: Digital sovereignty adoption, learn.microsoft.com/en-us/azure/cloud-adoption-framework/sovereignty/executive-strategy | Page dated 2026-09-03, checked 2026-10-30 | Deployment models, decision approach |
| Microsoft, Cloud Adoption Framework: Planning and organizational readiness for sovereignty, learn.microsoft.com/en-us/azure/cloud-adoption-framework/sovereignty/planning-readiness | Page dated 2026-09-01, checked 2026-10-30 | Requirements, classifications, control baseline approach |
| AWS, Digital Sovereignty Lens, AWS Well-Architected Framework, docs.aws.amazon.com/wellarchitected/latest/digital-sovereignty-lens/digital-sovereignty-lens.html | Last updated 15 September 2026, checked 2026-10-30 | Five design concerns |
| Regulation (EU) 2023/2854 (Data Act), eur-lex.europa.eu | Applicable from 12 September 2025; check the consolidated text | Chapter VI switching, Article 32 |
| European Commission, Data Act explained, digital-strategy.ec.europa.eu/en/policies/data-act-explained | Checked 2026-10-30 | Switching charge dates |
| Bundesnetzagentur, Data Act fact sheet on switching, bundesnetzagentur.de | Checked 2026-10-30 | Notice and transitional periods (secondary confirmation) |
| European Commission, "Sovereign Cloud Framework explained", commission.europa.eu | Published 1 June 2026, checked 2026-10-30 | Categories and SEAL levels |
| NCSC, Cloud Security Principles, ncsc.gov.uk | Version 2.1, reviewed 7 June 2023, checked 2026-10-30 | UK example |
| 18 U.S.C. 2713, law.cornell.edu | Checked 2026-10-30 | US example |
| Related templates: `compliance/data-residency-sovereignty-assessment`, `architecture/landing-zone-design`, `architecture/hybrid-multicloud-architecture`, `architecture/resilience-tiering-ha-dr-design`, `architecture/tco-analysis`, `architecture/aws-well-architected-review`, `architecture/azure-well-architected-review`, `compliance/dora-ict-third-party-register` | Current versions | Legal transfer analysis, landing zone, resilience and cost detail |

## Standard and licence note

Based on public sources: the Microsoft Cloud Adoption Framework
sovereignty guidance (pages dated September 2026), the AWS Digital
Sovereignty Lens for the Well-Architected Framework (last updated 15
September 2026), Regulation (EU) 2023/2854 (Data Act) Chapter VI and
Article 32, the European Commission's Cloud Sovereignty Framework
explainer (1 June 2026), the NCSC Cloud Security Principles and 18
U.S.C. 2713. Provider concepts and legal provisions are summarised in
original words; no provider text or tables are reproduced, and the
requirement catalogue, classifications, controls and examples are
original. Provider and product names are trademarks of their owners and
are used only to identify offerings. Calvera Pensions Agency is
fictional. This is a documentation format, not legal advice; check the
current official texts, provider documentation and a qualified
professional before use. Template licence: MIT.