# Data Residency and Sovereignty Assessment: [Solution or data estate]

> Assessment of where a solution's data is stored, processed and
> accessed from, which laws reach it, which transfer mechanisms make
> each cross-border flow lawful, and which hosting and key management
> option meets the organisation's residency and sovereignty
> requirements. It covers the data inventory, the flow map, a
> jurisdiction matrix, transfer mechanisms under Chapter V of the GDPR
> (Regulation (EU) 2016/679, Articles 44 to 49), transfer impact
> assessments following EDPB Recommendations 01/2020 (version 2.0,
> 18 June 2021), the standard contractual clauses in Commission
> Implementing Decision (EU) 2021/914, the EU-US Data Privacy Framework
> adequacy decision (Implementing Decision (EU) 2023/1795 of 10 July
> 2023), safeguards for non-personal data under Article 32 of the Data
> Act (Regulation (EU) 2023/2854), localisation regimes outside the EU,
> key custody, sovereign cloud options, residual risk and the decision
> record. Replace every `[bracketed]` value and every row marked
> *Example*. Laws outside the EU are given as examples only; check
> current law in each jurisdiction and check the consolidated text of
> every EU act. This is a documentation format, not legal advice.

<!--
Guidance: How to use this template
- Use it for a new solution, a hosting change, a new vendor or support
  location, or a periodic review of an existing estate. One assessment
  can cover several systems when they share data and vendors.
- Keep three ideas apart. Residency is where data is stored and
  processed. Localisation is a legal rule that data must stay in a
  country. Sovereignty is the ability to keep data subject only to the
  laws and control you choose, which includes who can access it from
  abroad and who holds the keys.
- Build the inventory (section 2) and flow map (section 3) first.
  Remote access from another country, including support and
  administration, is a transfer in GDPR terms and must appear on the
  map.
- Do the legal analysis per transfer (sections 5 and 6), then choose
  technical options (sections 9 and 10). Technical choices cannot make
  an unlawful transfer lawful, but they can be the supplementary
  measures a TIA depends on.
- Related documents: Record of processing activities
  (`compliance/gdpr-ropa`), Data protection impact assessment
  (`compliance/dpia`), Supplier security assessment
  (`compliance/supplier-security-assessment`), Legal register
  (`compliance/legal-register`), Landing zone design
  (`architecture/landing-zone-design`), Hybrid and multi-cloud
  architecture (`architecture/hybrid-multicloud-architecture`), Data
  platform architecture (`architecture/data-platform-architecture`),
  Cloud security reference patterns
  (`security/cloud-security-reference-patterns`), HIPAA security
  solution design (`compliance/hipaa-security-solution-design`) for US
  health data.
-->

## Document control

<!-- Guidance: Identify the data estate, the controller or processor role of the organisation, and the data protection officer and counsel who must review it. A new country, vendor or hosting model is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [DRS-001] |
| Solution or data estate | [Name, systems in scope] |
| Organisation and role | [Legal name], [Controller / Processor / Joint controller] |
| Establishments | [Countries where the organisation is established] |
| Data protection officer | [@dpo] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@solution-architect] |
| Approvers/reviewers | [@dpo], [@legal], [@security-architect], [@procurement], [@business-owner] |
| Classification | [Confidential] |
| Last updated | YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD |
| Related documents | [ROPA entries], [DPIA], [Vendor DPAs], [Landing zone design] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Data protection officer | [@name] | [Opinion] | YYYY-MM-DD |
| Legal counsel | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Decision] | YYYY-MM-DD |
| Business owner (risk acceptance) | [@name] | [Accept / Do not accept] | YYYY-MM-DD |

### Revision history

<!-- Guidance: Transfer assessments must be re-evaluated when the law or practice in a destination country changes (EDPB step 6). Record what triggered each revision. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved; option B selected (section 13) |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Re-evaluated US transfers after a court ruling on the Data Privacy Framework |

## Contents

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

1. [Scope, drivers and requirements](#1-scope-drivers-and-requirements)
2. [Data inventory and classification](#2-data-inventory-and-classification)
3. [Data flow map](#3-data-flow-map)
4. [Jurisdiction matrix](#4-jurisdiction-matrix)
5. [Transfer mechanisms (GDPR Chapter V)](#5-transfer-mechanisms-gdpr-chapter-v)
6. [Transfer impact assessments](#6-transfer-impact-assessments)
7. [Localisation and transfer rules outside the EU](#7-localisation-and-transfer-rules-outside-the-eu)
8. [Non-personal data and foreign government access](#8-non-personal-data-and-foreign-government-access)
9. [Key management and access from abroad](#9-key-management-and-access-from-abroad)
10. [Sovereign cloud options](#10-sovereign-cloud-options)
11. [Residual risk](#11-residual-risk)
12. [Controls and monitoring](#12-controls-and-monitoring)
13. [Decision record](#13-decision-record)
14. [Traceability matrix](#14-traceability-matrix)
15. [Glossary and references](#15-glossary-and-references)

## 1. Scope, drivers and requirements

<!-- Guidance: Write down why residency matters for this estate. Drivers decide how strict the answer must be: a contractual promise to keep data in the EU is different from a statutory localisation rule. Pitfall: treating "EU region selected" as the whole answer while support staff and sub-processors access the data from elsewhere. -->

### 1.1 Scope

| In scope | Out of scope |
|---|---|
| *Example:* Customer policy platform, CRM SaaS, data warehouse, support desk, backups and logs | Internal finance ledger (assessed in DRS-002) |
| *Example:* China subsidiary sales data and India support centre access | Paper records |
| [Item] | [Item] |

### 1.2 Drivers

| ID | Driver | Source | Strength |
|---|---|---|---|
| DRV-001 *(Example)* | Lawful transfers of personal data out of the EEA | GDPR Chapter V | Legal obligation |
| DRV-002 *(Example)* | Customer contracts promise EU storage and EU-only support for enterprise clients | Master services agreement clause 14 | Contractual |
| DRV-003 *(Example)* | Personal information collected in China by the subsidiary | PIPL and CAC rules | Legal obligation |
| DRV-004 *(Example)* | Board risk appetite: limit exposure to foreign government access requests | Risk policy | Policy |
| DRV-005 *(Example)* | Regulator expectations on outsourcing and exit for financial services | Sector rules, see DORA register (`compliance/dora-ict-third-party-register`) | Legal obligation |
| [DRV-NNN] | [Driver] | [Source] | [Legal / Contractual / Policy] |

### 1.3 Requirements

| ID | Requirement | Driver | Acceptance criterion |
|---|---|---|---|
| RES-001 *(Example)* | Tier A data stays in the EEA at rest and in processing; Tier B data in the organisation's own platforms stays in EEA regions, and any other location is a registered transfer under RES-002 | DRV-001, DRV-002 | Policy-as-code denies resource creation outside the allowed regions; quarterly evidence report |
| RES-002 *(Example)* | Every transfer outside the EEA has a documented Chapter V mechanism and, where needed, a TIA | DRV-001 | Transfer register complete; TIA on file per XFR row |
| RES-003 *(Example)* | Encryption keys for Tier A data are held under the organisation's control in the EEA | DRV-004 | Keys in an external key manager in the EEA; provider cannot decrypt without a call the organisation can deny |
| RES-004 *(Example)* | Provider operational access to Tier A data only by EEA-resident staff, with approval | DRV-002 | Contract clause plus access approval logs |
| RES-005 *(Example)* | China personal information exported only under a valid CAC mechanism | DRV-003 | Mechanism recorded in JUR-004 with filing reference |
| [RES-NNN] | [Requirement] | [Driver] | [Criterion] |

## 2. Data inventory and classification

<!-- Guidance: Classify by residency sensitivity, not only by confidentiality. Include metadata, telemetry, logs and backups; they often carry personal data and leave the region by default. -->

### 2.1 Residency tiers

| Tier | Meaning | Example |
|---|---|---|
| Tier A | Must stay in the defined territory at rest and in processing; foreign access only under strict conditions | *Example:* Health and claims data, special category data |
| Tier B | Must stay in the territory at rest; controlled transfers allowed with mechanism and TIA | *Example:* Customer contact and policy data |
| Tier C | May be transferred with standard safeguards | *Example:* Pseudonymised analytics, product telemetry without identifiers |
| Tier D | No restriction | *Example:* Public product catalogue |

### 2.2 Inventory

| ID | Data category | Personal data? | Special or sensitive? | Systems | Tier | Volume | ROPA reference |
|---|---|---|---|---|---|---|---|
| DATA-001 *(Example)* | Customer identity and contact | Yes | No | Policy platform, CRM | B | 2.4 million people | ROPA-012 |
| DATA-002 *(Example)* | Claims and health information | Yes | Yes (Art. 9 GDPR) | Claims system | A | 310,000 people | ROPA-014 |
| DATA-003 *(Example)* | Support tickets and call recordings | Yes | Possibly | Support desk SaaS | B | 40,000 tickets per month | ROPA-020 |
| DATA-004 *(Example)* | Application logs and telemetry | Yes (IDs, IP) | No | Log platform | B | 1.2 TB per month | ROPA-031 |
| DATA-005 *(Example)* | Pricing models and actuarial data | No | Trade secret | Data warehouse | B | n/a | n/a |
| DATA-006 *(Example)* | China subsidiary customer data | Yes | Some sensitive (PIPL) | Local CRM | A (China rules) | 60,000 people | ROPA-CN-01 |
| [DATA-NNN] | [Category] | [Yes / No] | [Yes / No] | [Systems] | [Tier] | [Volume] | [Ref] |

## 3. Data flow map

<!-- Guidance: Show storage, processing and access locations, including vendors and sub-processors. Under EDPB Guidelines 05/2021, a transfer happens when an exporter subject to the GDPR makes personal data available to an importer in a third country, which includes remote access. -->

Draw locations as boxes, not systems, so the cross-border paths are
obvious. Number every path with its XFR ID.

```mermaid
flowchart LR
  subgraph EEA["EEA"]
    APP["Policy platform, EU region"]
    WH[("Data warehouse, EU region")]
    KMS["External key manager, EU"]
  end
  subgraph US["United States"]
    CRM["CRM SaaS, US processing"]
    SUP["Vendor follow-the-sun support"]
  end
  subgraph IN["India"]
    BPO["Support centre, processor"]
  end
  subgraph CN["China"]
    CNCRM["Subsidiary CRM"]
  end
  APP -->|"XFR-001 customer records"| CRM
  SUP -.->|"XFR-002 remote admin access"| APP
  BPO -.->|"XFR-003 remote ticket access"| APP
  CNCRM -->|"XFR-004 sales reports"| WH
  WH -->|"XFR-005 pseudonymised extract"| CRM
  APP --- KMS
```

| ID | Data | From (exporter, country) | To (importer, country) | Importer role | Purpose | Type | Frequency |
|---|---|---|---|---|---|---|---|
| XFR-001 *(Example)* | DATA-001 | [Company], Germany | CRM vendor, US | Processor | Sales and service | Storage and processing | Continuous |
| XFR-002 *(Example)* | DATA-001, DATA-004 | Cloud vendor EU entity (processor for [Company]), [EU country] | Cloud vendor support affiliate, US | Sub-processor | Incident support | Remote access | On request |
| XFR-003 *(Example)* | DATA-003 | [Company], Germany | Support BPO, India | Processor | First-line support | Remote access | Continuous, business hours |
| XFR-004 *(Example)* | DATA-006 extract, non-sensitive fields only | Subsidiary, China | [Company], Germany | Controller (group) | Group reporting | Export from China | Monthly |
| XFR-005 *(Example)* | DATA-001 pseudonymised | [Company], Germany | CRM vendor, US | Processor | Campaign analytics | Storage | Weekly |
| [XFR-NNN] | [Data] | [From] | [To] | [Role] | [Purpose] | [Type] | [Frequency] |

## 4. Jurisdiction matrix

<!-- Guidance: One row per country where data is stored, processed or accessed, and per country whose law can reach the provider (for example its home country). Record the laws that matter: data protection, localisation, sector rules and government access powers. -->

| ID | Country or territory | Presence | EU adequacy? | Localisation or export rules | Government access laws to assess | Notes |
|---|---|---|---|---|---|---|
| JUR-001 *(Example)* | EEA member states | Storage, processing | n/a (inside the EEA) | None for this data at EU level; check national sector rules | National security and criminal procedure law | Baseline |
| JUR-002 *(Example)* | United States | CRM processing, support access | Yes, for organisations certified under the EU-US Data Privacy Framework only | None federal for this data; state privacy laws | Surveillance law covered by the DPF assessment; CLOUD Act for provider-held data | Check the importer on the DPF List |
| JUR-003 *(Example)* | India | Support centre access | No | DPDP Act 2023 section 16 and DPDP Rules 2025 (notified 13 November 2025; Rule 15 on transfers applies from 13 May 2027) govern transfers out of India; sector localisation rules (for example payment data) | Check current law | Data is EU data accessed from India |
| JUR-004 *(Example)* | China (mainland) | Subsidiary CRM | No | PIPL Articles 38 to 40; CAC cross-border provisions of March 2024 | Data Security Law, PIPL Article 41 on foreign requests | Export mechanism needed for XFR-004 |
| JUR-005 *(Example)* | United Kingdom | Backup DR site (optional) | Yes (decision renewed December 2025) | UK GDPR transfer rules for onward transfers | Check current law | Alternative DR location |
| [JUR-NNN] | [Country] | [Presence] | [Yes / No] | [Rules] | [Laws] | [Notes] |

## 5. Transfer mechanisms (GDPR Chapter V)

<!-- Guidance: Article 44 sets the general rule that a transfer, and any onward transfer, needs a Chapter V basis. Work down the decision flow per XFR row and record the result. Pitfall: using the Article 49 derogations for regular, repeated transfers; they are for specific situations. -->

```mermaid
flowchart TD
  A["Transfer identified, XFR row"] --> B{"Is it a transfer under Chapter V?"}
  B -->|No| Z["Record reasoning, no Chapter V mechanism needed"]
  B -->|Yes| C{"Adequacy decision covers the destination and importer? Art. 45"}
  C -->|Yes| D["Rely on adequacy; monitor the decision"]
  C -->|No| E{"Appropriate safeguard available? Art. 46 or BCR Art. 47"}
  E -->|Yes| F["Sign SCCs or rely on BCRs; run TIA, section 6"]
  F --> G{"TIA shows essentially equivalent protection?"}
  G -->|Yes| H["Transfer may proceed with measures"]
  G -->|No| I["Suspend or redesign the transfer"]
  E -->|No| J{"Specific situation derogation fits? Art. 49"}
  J -->|Yes| K["Use narrowly; document and limit"]
  J -->|No| I
```

### 5.1 Mechanism options (paraphrased)

| Mechanism | Article | When it fits | What to check |
|---|---|---|---|
| Adequacy decision | 45 | Destination, territory, sector or organisation covered by a Commission decision | Current list on the Commission website; for the US, the importer must be certified under the Data Privacy Framework for the relevant data (HR or non-HR) |
| Standard contractual clauses | 46(2)(c) | Most processor and controller transfers to non-adequate countries | Use the 2021 clauses (Implementing Decision (EU) 2021/914) with the right module: controller to controller, controller to processor, processor to processor, processor to controller; do not modify the clauses; complete the annexes |
| Binding corporate rules | 46(2)(b), 47 | Intra-group transfers in a group with approved BCRs | BCR approval and scope cover the data and countries |
| Codes of conduct or certification with binding commitments | 46(2)(e), (f) | Where an approved code or certification exists for the importer | Approval status and enforceable commitments |
| Ad hoc clauses or administrative arrangements | 46(3) | Bespoke cases | Supervisory authority authorisation is needed |
| Derogations for specific situations | 49(1) | Occasional transfers such as explicit informed consent, contract performance with the data subject, important public interest, legal claims, vital interests, public registers; a narrow compelling legitimate interest fallback | Interpret strictly; not for systematic transfers |
| Foreign court or authority requests | 48 | A third-country judgment or decision alone does not authorise a transfer | Route requests through an international agreement such as a mutual legal assistance treaty |

Note the Commission's statement that it is developing additional
clauses for importers whose processing is already subject to the GDPR
under Article 3(2), and for EU institutions; check the Commission SCC
page for their status before choosing clauses for such importers.

### 5.2 Mechanism per transfer

| XFR | Chapter V transfer? | Mechanism | Instrument and reference | TIA needed? | Status |
|---|---|---|---|---|---|
| XFR-001 *(Example)* | Yes | Adequacy (DPF) as primary; SCCs module 2 kept in the DPA as fallback | Importer on DPF List, checked YYYY-MM-DD; DPA [ref] | No for DPF reliance; prepared for fallback | Valid |
| XFR-002 *(Example)* | Yes | DPF via cloud vendor certification; SCCs module 3 (processor to processor) between the vendor's EU entity and its US support affiliate | Vendor DPA [ref] | Fallback TIA on file | Valid |
| XFR-003 *(Example)* | Yes | SCCs module 2 | DPA with BPO [ref] | Yes, TIA-001 | Valid with measures |
| XFR-004 *(Example)* | Not under the GDPR (export from China); check PIPL | Volume exemption under LOC-002; standard contract or certification if thresholds are passed | Exemption record with yearly volume count [ref] | Under PIPL: personal information protection impact assessment | In progress |
| XFR-005 *(Example)* | Yes (pseudonymised data is still personal data) | As XFR-001 | As XFR-001 | No | Valid |
| [XFR-NNN] | [Yes / No] | [Mechanism] | [Ref] | [Yes / No] | [Status] |

### 5.3 Data Privacy Framework dependency

The Commission adopted the EU-US adequacy decision on 10 July 2023. On
3 September 2025 the General Court dismissed an action for annulment
(Case T-553/23, Latombe v Commission). Latombe lodged an appeal to the
Court of Justice (Case C-703/25 P), which is pending. Check the case status at
curia.europa.eu and the Commission's periodic review reports. Because a
future judgment could invalidate the decision, keep SCCs in every US
data processing agreement and keep a TIA ready, so the transfer
mechanism can switch without renegotiation.

## 6. Transfer impact assessments

<!-- Guidance: When relying on an Article 46 tool, assess whether the law and practice of the destination prevent the importer from meeting its commitments, then add supplementary measures where needed. EDPB Recommendations 01/2020 describe six steps; record each step per transfer. Pitfall: copying a vendor's generic TIA without checking your own data, importer and access path. -->

### 6.1 Steps (EDPB Recommendations 01/2020, summarised)

| Step | Question | Output |
|---|---|---|
| 1 | Do we know all our transfers, including onward transfers and remote access? | Sections 3 and 5.2 complete |
| 2 | Which transfer tool are we relying on? | Section 5.2 |
| 3 | Does the destination's law or practice impinge on the tool's effectiveness for this transfer? | Legal analysis below |
| 4 | Which supplementary measures (technical, contractual, organisational) close the gap? | Measures table |
| 5 | What formal steps do the measures need (for example authorisation where clauses are changed)? | Procedural record |
| 6 | When and how will we re-evaluate? | Review date and triggers |

### 6.2 TIA register

| ID | XFR | Destination law and practice findings | Data accessible in clear by importer? | Supplementary measures | Conclusion | Review |
|---|---|---|---|---|---|---|
| TIA-001 *(Example)* | XFR-003 | [Summary of surveillance and access laws, sources consulted, likelihood that this importer receives requests] | Yes, agents read tickets | Access through EU-hosted virtual desktop with no download; masking of identifiers that support work does not need; contractual duty to challenge requests and notify; transparency reporting | Proceed with measures | YYYY-MM-DD |
| TIA-002 *(Example)* | XFR-002 fallback | [Summary] | Only during approved support sessions | Customer approval before each support session (KEY-001 access rule), session recording; Tier A data stays under EEA-held keys (KEY-002) | Proceed with measures | YYYY-MM-DD |
| [TIA-NNN] | [XFR] | [Findings] | [Yes / No] | [Measures] | [Conclusion] | YYYY-MM-DD |

Technical measures that are most effective against access by the
destination's authorities are those that leave the importer without the
data in clear: strong encryption with keys held only by the exporter in
the EEA, or pseudonymisation where the re-identification data stays in
the EEA. Measures do not help where the importer needs clear data to do
its job, such as support agents reading tickets; in that case the
conclusion rests on the legal analysis and the organisational and
contractual measures.

## 7. Localisation and transfer rules outside the EU

<!-- Guidance: Record every non-EU regime that restricts storage or export of data in scope. The entries below are examples with article or section numbers; laws and thresholds change often, so check current law with local counsel before relying on them. -->

| ID | Regime | Rule (paraphrased) | Applies to this estate? | Mechanism or action |
|---|---|---|---|---|
| LOC-001 *(Example)* | China, Personal Information Protection Law, Articles 38 to 40 | Export of personal information needs a basis such as a CAC security assessment, certification or the CAC standard contract, plus separate consent and notice (Art. 39); critical information infrastructure operators and processors above volume thresholds must store personal information in China and pass a security assessment to export it (Art. 40) | Yes, DATA-006 | See LOC-002 |
| LOC-002 *(Example)* | China, CAC Provisions on Promoting and Regulating Cross-Border Data Flows (in force 22 March 2024) | Volumes counted from 1 January of the year decide the route: a security assessment for important data, for any export by a critical information infrastructure operator, and for exports of personal information of more than 1 million people or sensitive personal information of more than 10,000; a standard contract or certification for more than 100,000 but fewer than 1 million people, or sensitive personal information of fewer than 10,000; exemptions for contract performance with the individual, cross-border HR management under lawful rules, emergencies and, for processors that are not critical information infrastructure operators, non-sensitive exports of fewer than 100,000 people. Certification follows the CAC and SAMR Measures for Certification of Personal Information Outbound Transfer (in force 1 January 2026) | Yes: about 60,000 people, non-sensitive extract in XFR-004 | *Example:* The subsidiary is not a critical information infrastructure operator and the export is below 100,000 people and non-sensitive, so exempt; confirm and record the count yearly; check current law |
| LOC-003 *(Example)* | India, Digital Personal Data Protection Act 2023, section 16, and DPDP Rules 2025 | The government may restrict transfers to countries it notifies; stricter sector laws continue to apply. The Rules were notified on 13 November 2025 with phased commencement; Rule 15 (transfers) and most obligations apply from 13 May 2027; Rule 13 lets the government require significant data fiduciaries to keep specified data in India | Only if data of persons in India is processed; XFR-003 sends EU data to India, not Indian data out | Monitor notifications; check current law |
| LOC-004 *(Example)* | India, sector rules (for example payment system data storage directions) | Some financial data must be stored only in India | No | None |
| LOC-005 *(Example)* | Other localisation regimes (for example Russia, Vietnam, Saudi Arabia, Indonesia) | Localisation or export conditions for certain data or sectors | [Yes / No] | Check current law |
| LOC-006 *(Example)* | United States, sector rules (for example HIPAA for health data, federal government data rules) | No general localisation, but contract and sector rules may require US hosting | [Yes / No] | See HIPAA security solution design (`compliance/hipaa-security-solution-design`) |
| [LOC-NNN] | [Regime] | [Rule] | [Yes / No] | [Action] |

## 8. Non-personal data and foreign government access

<!-- Guidance: GDPR Chapter V covers personal data only. Trade secrets, industrial data and other non-personal data also face foreign access risk. Article 32 of the Data Act places duties on providers of data processing services, which you can check in vendor contracts. -->

| Item | Assessment |
|---|---|
| Non-personal data in scope | *Example:* DATA-005 pricing models, actuarial data |
| Data Act Article 32 (applicable from 12 September 2025; check the consolidated text) | Providers of data processing services must take adequate technical, legal and organisational measures to prevent international governmental access to, or transfer of, non-personal data held in the Union where it would conflict with Union or national law; third-country decisions are generally recognised only on the basis of an international agreement, with limited exceptions, and the customer is to be informed before the provider complies unless the request forbids it |
| Vendor commitments obtained | *Example:* Cloud vendor DPA and data processing addendum describe request handling, challenge and customer notice; transparency report reviewed |
| Foreign laws with reach over the provider | *Example:* US CLOUD Act (provider in US corporate group); assessed in JUR-002 |
| Residual exposure | *Example:* Low for DATA-005 with EEA-held keys (KEY-002) |

## 9. Key management and access from abroad

<!-- Guidance: Where data sits matters less than who can read it. Decide key custody and operational access per tier. Pitfall: assuming customer-managed keys in a provider key service prevent provider access; the provider still operates that service. -->

### 9.1 Key custody options

| Option | Where keys live | Provider can decrypt without the customer? | Operational cost | Typical use |
|---|---|---|---|---|
| Provider managed keys | Provider key service | Yes | Lowest | Tier C and D |
| Customer managed keys in provider key service | Provider key service, customer-controlled policy | Technically possible for the provider operating the service; controlled by contract and audit | Low | Tier B |
| External key manager (hold your own key) | Customer HSM or key service outside the provider, called at run time | Only while the customer's key service grants each call | Medium to high; key service becomes a critical dependency | Tier A |
| Client-side encryption | Customer application before upload | No, but provider services cannot process the data | High; limits search and analytics | Tier A archives, backups |

### 9.2 Key and access decisions

| ID | Tier or data | Key option | Key location | Operational access rule | Evidence |
|---|---|---|---|---|---|
| KEY-001 *(Example)* | Tier B (DATA-001, DATA-003, DATA-004) | Customer managed keys | Provider key service, EU region | Provider support from any location only with customer approval in the access approval workflow | Approval logs |
| KEY-002 *(Example)* | Tier A (DATA-002) and DATA-005 | External key manager | Customer HSM cluster in two EU data centres | Provider staff access only by EEA-resident personnel with approval; key calls logged and can be revoked | Key service logs, contract clause |
| KEY-003 *(Example)* | Backups of Tier A | Client-side encryption | Customer key vault, EU | No provider access | Backup job configuration |
| [KEY-NNN] | [Tier] | [Option] | [Location] | [Rule] | [Evidence] |

Plan for availability: with an external key manager, an outage of the
key service makes the data unavailable. Design the key service for the
same recovery targets as the most critical workload that depends on it
(see Resilience tiering (`architecture/resilience-tiering-ha-dr-design`)).

## 10. Sovereign cloud options

<!-- Guidance: Compare realistic hosting options against the requirements in 1.3 with weighted criteria agreed before scoring. Product names and offerings change often; check each provider's current documentation and contract terms on the day of the decision. -->

### 10.1 Option types

| Type | Description | Examples to check (names only, current status to be confirmed) |
|---|---|---|
| Standard public region with residency controls | Data stored in a chosen region; region restrictions by policy; global control plane and follow-the-sun operations | EU regions of the major providers |
| Provider data boundary commitment | Provider commits to store and process customer data and pseudonymised logs within a geography, with listed exceptions | Microsoft EU Data Boundary (EU and EFTA countries; check the current exceptions list) |
| Separate sovereign partition run by the provider | Independent infrastructure, control plane and EU-resident operations, separate from the global cloud | AWS European Sovereign Cloud (first region in Brandenburg, Germany; check service availability) |
| Partner-operated or locally controlled cloud | Provider technology operated by a local entity under local control | Google Cloud sovereign offerings with local partners; check current offering names |
| Private or on-premises cloud | Organisation-operated infrastructure | Customer data centres, colocation |

Certification schemes can support the choice. The EU Cybersecurity
Certification Scheme for Cloud Services (EUCS) under the Cybersecurity
Act has been in preparation for several years; check its adoption
status with ENISA and the Commission before relying on it. National
schemes such as SecNumCloud (France) and C5 (Germany) are used in
procurement; check their current versions.

### 10.2 Evaluation

Scores are 1 (poor) to 5 (strong). Weighted score is the sum of weight
times score, divided by 100.

| Criterion | Weight | Option A: EU region, customer managed keys, DPF and SCCs | Option B: data boundary with external key manager | Option C: sovereign partition |
|---|---|---|---|---|
| Legal fit (RES-001 to RES-005) | 30 | 3 | 4 | 5 |
| Service and feature availability | 20 | 5 | 4 | 3 |
| Control of operational access (RES-004) | 15 | 2 | 4 | 5 |
| Cost | 15 | 5 | 4 | 3 |
| Resilience and region choice | 10 | 5 | 4 | 3 |
| Exit and portability | 10 | 4 | 4 | 3 |
| Weighted score *(Example)* | 100 | 3.85 | 4.00 | 3.90 |

Working for the *Example*: Option A is (30 x 3, plus 20 x 5, plus
15 x 2, plus 15 x 5, plus 10 x 5, plus 10 x 4) / 100 = 385 / 100 = 3.85.
Option B is (120 plus 80 plus 60 plus 60 plus 40 plus 40) / 100 = 4.00.
Option C is (150 plus 60 plus 75 plus 45 plus 30 plus 30) / 100 = 3.90.
Scores close together mean the decision rests on the
must-have requirements: check that the chosen option meets every RES
row, not only the highest total.

## 11. Residual risk

<!-- Guidance: Record what remains after mechanisms and measures. Rate on the organisation's scale and name a risk owner. -->

| ID | Risk | Linked | Likelihood (1 to 5) | Impact (1 to 5) | Rating | Treatment | Owner |
|---|---|---|---|---|---|---|---|
| RR-001 *(Example)* | DPF invalidated by a future judgment; US transfers lose their primary basis | XFR-001, XFR-002, XFR-005 | 2 | 4 | 8 | SCCs already in DPAs; TIAs ready; plan to move analytics to EU instance | [@dpo] |
| RR-002 *(Example)* | Support centre staff in India exposed to a local access request | XFR-003 | 2 | 3 | 6 | EU-hosted virtual desktop, contractual notice and challenge duty | [@security-architect] |
| RR-003 *(Example)* | External key manager outage stops the claims system | KEY-002 | 2 | 5 | 10 | Active-active HSM cluster in two sites; tested quarterly | [@platform-lead] |
| RR-004 *(Example)* | China subsidiary volumes pass 100,000 people, triggering the standard contract or certification route | XFR-004 | 3 | 3 | 9 | Quarterly volume check; prepare the standard contract filing or certification in advance | [@cn-legal] |
| RR-005 *(Example)* | New sub-processor added outside the EEA without assessment | All vendors | 3 | 3 | 9 | Contractual notice of new sub-processors; CTRL-004 review | [@procurement] |
| [RR-NNN] | [Risk] | [Link] | [L] | [I] | [L x I] | [Treatment] | [@owner] |

Ratings are likelihood times impact: 1 to 4 low, 5 to 9 medium, 10 to
15 high, 16 to 25 very high.

## 12. Controls and monitoring

<!-- Guidance: Residency decays as teams add services and vendors add sub-processors. Make each control testable and assign evidence. -->

| ID | Control | Type | Frequency | Evidence | Owner |
|---|---|---|---|---|---|
| CTRL-001 *(Example)* | Policy-as-code denies resources outside allowed regions in the landing zone | Preventive | Continuous | Policy compliance report | [@platform-lead] |
| CTRL-002 *(Example)* | Data loss prevention rules flag Tier A data in tools outside the approved list | Detective | Continuous | DLP alerts | [@security-ops] |
| CTRL-003 *(Example)* | Transfer register (section 5.2) reconciled with ROPA and vendor list | Detective | Quarterly | Reconciliation record | [@dpo] |
| CTRL-004 *(Example)* | Review of vendor sub-processor change notices against the jurisdiction matrix | Detective | On notice | Ticket per notice | [@procurement] |
| CTRL-005 *(Example)* | Key access logs reviewed for provider-initiated calls | Detective | Monthly | Log review | [@security-ops] |
| CTRL-006 *(Example)* | Legal watch on adequacy decisions, court rulings and localisation laws | Detective | Monthly | Legal register (`compliance/legal-register`) entries | [@legal] |
| CTRL-007 *(Example)* | Government access request procedure: log, assess, challenge, notify | Corrective | On event | Request log | [@legal] |
| [CTRL-NNN] | [Control] | [Type] | [Frequency] | [Evidence] | [@owner] |

## 13. Decision record

<!-- Guidance: Record the decision in the same form as an architecture decision, so later reviewers see the options, the reasons and the conditions. Link it from the decision log. -->

| Field | Value |
|---|---|
| Decision ID | DEC-001 *(Example)* |
| Decision | *Example:* Adopt option B: provider EU data boundary with external key manager for Tier A, customer managed keys for Tier B; keep the CRM in the US under DPF with SCC fallback |
| Options considered | A, B, C (section 10.2) |
| Reasons | *Example:* Meets RES-001 to RES-005; better feature availability than option C; operational access controls stronger than option A |
| Conditions | *Example:* KEY-002 resilience test passed before go-live; TIA-001 approved by DPO; China volume check in place |
| Consequences | *Example:* Higher key service operating cost; some services unavailable where external keys are not supported |
| Review triggers | Court ruling on the DPF; new country, vendor or sub-processor; change of law in JUR rows; provider offering change |
| Decided by and date | [@business-owner], [@dpo], YYYY-MM-DD |
| Decision log reference | [Entry ID] in the Architecture decision log (`architecture/architecture-decision-log`) |

## 14. Traceability matrix

<!-- Guidance: Each requirement links to the transfers, mechanisms, controls and evidence that satisfy it. -->

| Requirement | Transfers or data | Mechanism or design element | Controls | Evidence | Status |
|---|---|---|---|---|---|
| RES-001 | DATA-001 to DATA-005 | Option B regions | CTRL-001 | Policy report | *Example:* Met |
| RES-002 | XFR-001 to XFR-005 | Section 5.2, TIA-001, TIA-002 | CTRL-003 | Transfer register | *Example:* Met |
| RES-003 | DATA-002, DATA-005 | KEY-002, KEY-003 | CTRL-005 | Key logs | *Example:* Met after go-live test |
| RES-004 | XFR-002 | Contract clause, access approval workflow | CTRL-005 | Approval logs | *Example:* Met |
| RES-005 | XFR-004 | LOC-002 exemption, volume check | CTRL-006 | Volume record | *Example:* Met |
| [RES-NNN] | [Data] | [Element] | [Control] | [Evidence] | [Status] |

## 15. Glossary and references

<!-- Guidance: Define terms for non-specialist readers and list every source with its version and the date you checked it. -->

### 15.1 Glossary

| Term | Meaning |
|---|---|
| Data residency | Where data is stored and processed, usually chosen by the organisation |
| Data localisation | A legal or contractual rule that data must stay in a country or region |
| Data sovereignty | Keeping data subject only to the laws and control the organisation chooses, including control of keys and access |
| Transfer | Making personal data available to an importer in a third country, including by remote access |
| Exporter and importer | The party sending, or making data available, and the party receiving or accessing it |
| Adequacy decision | A Commission decision that a third country, territory, sector or organisation ensures an adequate level of protection |
| SCCs | Standard contractual clauses adopted by the Commission |
| TIA | Transfer impact assessment: assessment of the destination's law and practice for a transfer under an Article 46 tool |
| Supplementary measures | Technical, contractual or organisational measures added to a transfer tool to ensure essentially equivalent protection |
| External key manager | Key service under customer control, outside the cloud provider, that the provider must call to decrypt data |

### 15.2 References

| Source | Version or date | Use in this template |
|---|---|---|
| Regulation (EU) 2016/679 (GDPR), Chapter V, Articles 44 to 50, eur-lex.europa.eu | Consolidated text, check on use | Section 5 |
| Commission Implementing Decision (EU) 2021/914 on standard contractual clauses for transfers | 4 June 2021 | Section 5 |
| Commission Implementing Decision (EU) 2023/1795, EU-US Data Privacy Framework | 10 July 2023 | Sections 4 and 5 |
| General Court, Case T-553/23, Latombe v Commission | Judgment 3 September 2025 | Section 5.3 |
| Court of Justice, Case C-703/25 P, Latombe v Commission (appeal) | Lodged October 2025; check status | Section 5.3 |
| EDPB Recommendations 01/2020 on measures that supplement transfer tools | Version 2.0, 18 June 2021 | Section 6 |
| EDPB Guidelines 05/2021 on the interplay between Article 3 and Chapter V | Final version | Section 3 |
| Regulation (EU) 2023/2854 (Data Act), Article 32 | Applicable from 12 September 2025 | Section 8 |
| Personal Information Protection Law of the People's Republic of China | In force 1 November 2021 | Section 7 |
| CAC Provisions on Promoting and Regulating Cross-Border Data Flows (CAC Order No. 16) | Published and in force 22 March 2024 | Section 7 |
| CAC and SAMR Measures for Certification of Personal Information Outbound Transfer | Issued October 2025, in force 1 January 2026 | Section 7 |
| Digital Personal Data Protection Act 2023 (India) and DPDP Rules 2025 | Check the Gazette of India | Section 7 |
| Commission adequacy decisions page, commission.europa.eu | Checked YYYY-MM-DD | Section 4 |
| Provider documentation for data boundary and sovereign offerings | Checked YYYY-MM-DD | Section 10 |

## Standard and licence note

Based on Regulation (EU) 2016/679 (GDPR) Chapter V, Commission
Implementing Decisions (EU) 2021/914 and (EU) 2023/1795, EDPB
Recommendations 01/2020 (version 2.0) and Guidelines 05/2021,
Regulation (EU) 2023/2854 (Data Act) Article 32, and, as examples, the
Personal Information Protection Law of China with the CAC cross-border
provisions of March 2024 and the CAC and SAMR certification measures of
2025, and India's Digital Personal Data Protection
Act 2023 with the DPDP Rules 2025. EU legislative texts and EDPB
documents are free to reuse; all provisions are summarised in original
wording and no legal text is reproduced. Laws outside the EU are
examples only and change often: check current law in each
jurisdiction, the consolidated text of each EU act, the current
Commission adequacy list and the status of any court case before use.
Provider and product names (Microsoft EU Data Boundary, AWS European
Sovereign Cloud, Google Cloud) are trademarks of their owners; this
template is not affiliated with or endorsed by them. This is a
documentation format, not legal advice. Template licence: MIT.