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.
Document control
| 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
| 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
1. Scope, drivers and requirements
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
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
Draw locations as boxes, not systems, so the cross-border paths are
obvious. Number every path with its XFR ID.
| 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
| 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)
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
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
| 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
| 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
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
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
| 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
| 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
| 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
| 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
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.