DAT-022 Data Residency and Location Transparency
Description
A location record states, for each category of customer and personal data, the countries and cloud regions in which it is stored, processed and backed up. It also names the locations each sub-processor uses. Storage and processing are restricted to the locations the record gives for that tenant and the restriction is enforced by configuration rather than by convention. The record is available to customers, is updated when a location changes and customers are notified before the change takes effect. The record also states, per service, the countries the service is operated, supported and engineered from, the country each sub-processor operates from together with the country of its parent undertaking, and the jurisdiction whose law the infrastructure running the service is subject to, recorded separately from the country that infrastructure sits in. A change to any of those is notified on the terms a change of data location is notified on. The record is published where a prospective customer can read it without an account and the customer agreement names where it is published.
Rationale
Buyers and supervisory authorities ask where the data actually is. The answer has to be a record that matches the running configuration rather than a marketing claim. Enforcing the permitted set in configuration is what stops a new service or a support tool from quietly landing data in a region nobody disclosed. DAT-015 holds the legal mechanism for a cross-border transfer, DAT-006 the processing inventory the location record hangs off and INF-013 the availability reason for a second region. Issued in S4 from the NC-H proposal in docs/review-coverage-security.md section 2.1. Where a service is run from and where its data rests are different questions, and the second is the one a support engineer in an undisclosed country answers wrongly while every byte stays put. Jurisdiction is a third question again: an organisation incorporated outside the Union and running in an EU region is reachable by its own country's law wherever the servers are, so the record states the law as well as the place. VND-011 publishes the responsibility matrix and the measures that resist a foreign order. DAT-022 answers where the service and its data are and under whose law.
Applicability (9 profiles)
Location transparency is a commitment of a hosted service to its tenants.
Condition: deployment_model in on-prem, hybrid, edge, on-device, embedded, air-gapped
Where the deployer runs the AI system on infrastructure it controls, the location record for that system is its own and is enforced by its own configuration. Under cloud-saas or cloud-single-tenant the row is satisfied by the provider: the deployer obtains the provider's location record under VND-004 and reflects it in DAT-006 and DAT-015.
Condition: deployment_model in cloud-saas, cloud-single-tenant
Location transparency is a commitment of a hosted service to its tenants. Conditional since 1.1: the profile lists every deployment model and this row is a commitment of a hosted service, so a provider that publishes weights or runs on infrastructure the customer controls has no hosted service to carry it (ADR-046 amendment, 2026-09-16).
Location transparency is a commitment of a hosted service to its tenants.
Condition: deployment_model in on-prem, hybrid, edge, on-device, embedded, air-gapped
Where the deployer runs the AI system on infrastructure it controls, the location record for that system is its own and is enforced by its own configuration. Under cloud-saas or cloud-single-tenant the row is satisfied by the provider: the deployer obtains the provider's location record under VND-004 and reflects it in DAT-006 and DAT-015.
EX-101 written in S8 wave B (migration 057). The location record now states, per service, the jurisdiction whose law the infrastructure running it is subject to, recorded separately from the country that infrastructure sits in, and it is published where a prospective customer can read it without an account with the customer agreement naming where. Art. 28(1)(a) holds full and Art. 28(2) is stated for this record. Art. 28(1) stays partial on both halves of the duty: the point (b) content, the description of the measures preventing international governmental access, sits on VND-011.
EX-94 written in S8 wave B (migration 057). The location record now carries, per service, the countries the service is operated, supported and engineered from and the country of each sub-processor's parent undertaking, with a change notified on the terms a data location change is notified on, so Art. 30(2)(b) holds full. Support, operations or engineering access from an unaccepted country is a change of location under the control as well as under the article, even when no data moves.
Location transparency is a commitment of a hosted service to its tenants.
Location transparency is a commitment of a hosted service to its tenants.
Framework Mappings (11)
| DSP-19 | Data Location | full |
| DSP-19 | Data Location | full |
| DORA-Art.30.2.b | Locations of service provision and data processing | full |
| DORA-ITS-2024/2956-Art.3 | Register of information templates and data quality | informative |
| DORA-RTS-2025/532-Art.4.1 | Contract conditions for subcontracting critical or important functions | informative |
| EU-DA-Art.28.1 | Website Publication of International Access Information | partial |
| EU-DA-Art.28.1.a | Jurisdiction of the ICT Infrastructure | full |
| EU-DA-Art.28.2 | Website Reference in Service Contracts | informative |
| CM-12 | Information Location | partial |
| CM-12(1) | Information Location | Automated Tools to Support Information Location | partial |
| SA-9(5) | External System Services | Processing, Storage, and Service Location | full |
Evidence (3)
Data location record listing each data category against the countries and cloud regions used for storage, processing and backup, with the sub-processor locations and the date each entry was last confirmed. It also records, per service, the operating, support and engineering countries, the country of each sub-processor and of its parent undertaking, and the jurisdiction whose law the infrastructure is subject to.
Example: Data location register v4, dated 2026-08-01, listing customer content, telemetry and support attachments against their storage, processing and backup regions, with the sub-processor list and each entry's last confirmation date
Test: Read the location record. Verify: (1) every data category in the processing inventory appears, (2) each entry gives storage, processing and backup locations rather than storage alone, (3) each sub-processor is listed with the locations it uses, (4) every entry was confirmed within the defined interval, (5) a sample of entries matches the region of the live resource holding that data. (6) every service in the catalogue carries the countries it is operated, supported and engineered from, (7) each sub-processor entry names the country of its parent undertaking, (8) each service carries the jurisdiction whose law its infrastructure is subject to, recorded separately from the country that infrastructure sits in, (9) the record is reachable without an account and the customer agreement names where it is published.
Platform configuration that restricts where resources holding customer data may be created, read from the cloud control plane or from the infrastructure code that sets it.
Example: Organisation policy export restricting resource creation to the permitted region list, with the storage bucket and database region settings for three tenants, dated 2026-08-12
Test: Export the location restriction configuration. Verify: (1) a restriction on permitted regions is applied at the account or organisation level and not only in a document, (2) the permitted set matches the location record, (3) no resource holding customer data sits outside the permitted set, (4) any exemption from the restriction carries a recorded justification and an expiry date.
Notification record for the most recent change of a storage, processing or sub-processor location, showing what changed, who was told and when relative to the change taking effect.
Example: Sub-processor and region change notice of 2026-04-09 announcing the addition of a backup region, with the customer distribution list and the date the change took effect
Test: Take the most recent location change from the record. Verify: (1) customers were notified before the change took effect, (2) the notice named the data category, the old location and the new one, (3) the notice period matches what the location record and the customer agreement state, (4) the location record was updated on the same change. (5) a change in the period to an operating, support or engineering country, to a sub-processor's country or to the jurisdiction a service's infrastructure is subject to was notified on the terms a data location change is notified on.
Questions (3)
Is there a current record of the countries and cloud regions in which customer data is stored, processed and backed up?
The record has to cover processing and backup as well as primary storage, since those are the locations that surprise buyers. A sub-processor list without locations does not answer this question.
Which of the following does the location record cover?
Support tooling and analytics are the usual source of a location the record misses, because data is read from a region it is not stored in. The operating, support and engineering countries are a second set again: they answer where the people and the pipelines are, not where the bytes are. Jurisdiction is a legal answer and can differ from every geographic answer above it. Published means readable without an account, not supplied on request.
How is the permitted set of regions enforced?
Options run from strongest to weakest. Preventive enforcement at the account or organisation level is the difference between a location record that describes the estate and one that constrains it.