What is data residency?
Data residency describes the country or region in which data is physically stored and processed. The GDPR does not use the term; it regulates transfers of personal data to third countries. Under Article 44 of Regulation (EU) 2016/679 (GDPR), any such transfer is permitted only under the conditions of its Chapter V. The GDPR guide sets out that framework.
Which data and access count towards the location question?
Data residency covers every place where a service's data sits or is worked on, not only the region of the production data:
- backups and disaster recovery sites;
- log, telemetry and metadata;
- the content of support tickets and their attachments;
- analytics, test and training environments;
- subcontractors for peripheral functions such as content delivery networks, email delivery, telephony or ticketing.
Access location is a second question. Remote maintenance, support from other time zones and fault analysis are processing even when the data physically stays put: Article 4(2) GDPR expressly lists consultation as processing. A region setting in the admin console says nothing about either.
Data residency, localisation, sovereignty: three terms, three questions
| Term | Answers the question | Who decides |
|---|---|---|
| Data residency | Where is the data geographically? | The customer, within the regions the provider offers |
| Data localisation | Must the data stay within a defined territory? | The legislator or the contract; it is a requirement, not an option |
| Data sovereignty | Which law governs the data, and who can access it? | The jurisdictions the provider and its affiliates are subject to |
A commitment on the storage location leaves the other two rows open.
Why is a data centre in Germany not proof of GDPR compliance?
A data centre in Germany does not make processing lawful. The legal basis, data processing agreements under Article 28 GDPR, information duties, erasure and data subject rights all have to be assessed regardless of location. The same applies to the technical and organisational measures under Article 32 GDPR. A provider's certificate or attestation report describes the provider's audited scope, not your configuration and not your purposes.
Where personal data is transferred to a third country, Chapter V applies. Without a Commission adequacy decision under Article 45 GDPR, a transfer needs appropriate safeguards under Article 46 or, in specific situations, a derogation under Article 49. Under Article 46(2)(c), appropriate safeguards include the standard data protection clauses adopted by the Commission. Which instrument holds in a given case needs a legal assessment.
What Article 28 GDPR already sets for location commitments
Part of the location question is already built into the data processing agreement:
| Contract point | Basis in Article 28 GDPR | Also set out in the contract |
|---|---|---|
| Transfers to third countries | Para. 3(a): processing only on documented instructions, including for third-country transfers | An exhaustive list of storage and access locations |
| New sub-processors | Para. 2: authorisation; with general authorisation, information on changes and the opportunity to object | The location of every sub-processor, including for peripheral functions |
| End of contract | Para. 3(g): deletion or return at the controller's choice | Coverage of backups, deadline and proof |
| Audits | Para. 3(h): information to demonstrate compliance, audits including inspections | Information on the locations actually used |
| Key management | No express rule | Where keys are managed and who has access |
| Requests from authorities | No express rule | Notification, where legally permitted |
Twelve questions for the provider before signing
The location question cannot be answered from a product page. These twelve questions work as an annex to a tender:
- In which countries is the production data stored, as an exhaustive list?
- In which countries are the backups, and where is the failover site?
- Where are log, telemetry and metadata stored?
- Where is the content of support tickets and their attachments stored?
- From which countries do support, operations and fault analysis access the data?
- Which subcontractors are involved, including for peripheral functions, and where are they based?
- Which company operates the service, which law is it subject to, and who owns it?
- Where is key management located, and who can make the data readable?
- Is content used for analytics, fault reproduction or model training, and where?
- How will you learn of new locations and subcontractors, and how do you object?
- How does the provider inform you of requests from authorities, where permitted?
- What happens to data and backups at the end of the contract, within what period and with what proof?
For services with analytics or model components, the place of execution can differ from the storage location. The answer to question 9 therefore belongs in the contract.
Location and personal data per service in the asset register
Rizzqo carries the location on the individual asset. Every supporting asset, such as a SaaS application, a cloud service or a supplier, holds its country and a responsible owner.
Each supporting asset inherits the personal-data flag from the primary assets it supports, and Rizzqo shows which ones. Which services process personal data, and in which country they sit, then becomes a query against the asset register. For the platform itself: Rizzqo hosts your instance in your own country.