Data residency is a flow, not a region label
A vendor statement that data is “hosted in Europe” answers only one question. A SaaS service may also use support teams, subprocessors, telemetry, backups, disaster recovery, content delivery, security tooling and administrative access across several locations. The buyer needs a data-flow map, not a country name on a sales page.
Start with the data categories and people affected, then trace collection, processing, storage, replication, support access, export, retention and deletion. Record the legal entity responsible at each step and the mechanism that permits any relevant international transfer. Keep production data, metadata, logs and support content visible as separate flows.
This guide is an operational due-diligence framework, not legal advice. Requirements vary by data, role, sector, contract and jurisdiction. Use qualified privacy and legal review for the actual arrangement, especially where sensitive data, regulated services or government access risks are involved.
| Question | Evidence | Why it matters |
|---|---|---|
| Who controls and processes it? | Entity and role map | Assigns obligations and decisions |
| Where can it be stored? | Primary, replica and backup locations | Tests residency and recovery requirements |
| Who can access it remotely? | Support and administration model | Reveals transfers beyond storage |
| Which subprocessors receive it? | Current list, purpose and location | Shows the real service chain |
| How does it leave? | Export, retention and deletion process | Tests portability and exit |
Name the parties and purposes first
Identify the customer entity, vendor contracting entity, hosting provider and every material subprocessor. Record whether each party acts as controller, processor or subprocessor for the relevant purpose. A company can play different roles for account administration, service delivery, product analytics and its own security or commercial purposes.
Ask for the purpose and data categories associated with each service component. “Operational support” is too broad if it hides access to message content, identifiers or files. The answer should allow the buyer to decide whether the component is necessary, configurable and compatible with its notice, policy and legal basis.
The EDPB coordinated enforcement report on cloud-based services highlights issues including role allocation, subprocessors, international transfers and access by third-country authorities. Its focus is EEA public bodies, but the questions expose weaknesses any serious cloud review should make explicit.
Map storage, access and support separately
Request locations for primary data, replicas, backups, disaster-recovery copies, logs and customer-controlled encryption keys. Confirm whether the selected region is a default, a contractual commitment or an optional configuration. Ask what happens during failover and whether temporary movement is possible during an incident.
Remote access can create a transfer question even when storage stays in one region. Document where support and engineering teams can connect from, how access is approved, whether content is visible, what is logged and which emergency process can override normal controls. “Global support” should be translated into roles, locations and privileges.
Separate customer choices from vendor defaults. A tenant may control its region but not the location of telemetry, abuse monitoring or support attachments. Record which features change the flow and which controls are available in the proposed package, rather than assuming that a capability shown in documentation is enabled for every contract.
- Primary database, object storage and search indexes.
- Replicas, backups and disaster-recovery regions.
- Logs, telemetry, diagnostics and support attachments.
- Identity, encryption-key and administrative-control locations.
- Remote support, engineering and emergency access.
Inspect the subprocessor chain
A list of company names is not enough. For each subprocessor, request the service purpose, data categories, processing locations, access pattern and the notice process for changes. Distinguish infrastructure providers from optional integrations and support tools. Confirm whether the customer can object and what practical choices follow an objection.
Look for nested dependencies. The SaaS vendor may use a communications platform that uses its own hosting and monitoring suppliers. The buyer may not need a map of every low-risk commodity dependency, but it does need enough visibility to understand material transfers, concentration and the chain that must honour deletion or incident obligations.
Treat a static subprocessor page as a snapshot. Capture the review date and require change notification through a channel someone owns. A technically compliant notice has little value if it goes to an abandoned mailbox or arrives after the new processor begins handling data.
Verify the transfer mechanism and supplementary controls
For EEA personal data, identify whether the transfer relies on an adequacy decision, an appropriate safeguard such as standard contractual clauses, or another lawful route. Check the maintained European Commission list of adequacy decisions rather than relying on an old questionnaire or a vendor’s undated statement.
Where a transfer tool is required, assess whether the destination and practical access conditions affect the promised level of protection. The EDPB Recommendations 01/2020 set out a process for identifying transfers, verifying the tool, assessing destination law and adopting supplementary measures where necessary.
Ask which technical, contractual and organisational measures apply to the exact flow. Encryption at rest does not answer who can decrypt during support. A contractual promise does not replace an access-control design. Record keys, privileges, logging, challenge procedures and transparency evidence at the level needed for the risk.
Test retention, deletion and exit
Map retention by data category and state. Active records, deleted records, backups, logs and support tickets may follow different schedules. Ask when deletion becomes irreversible, which exceptions apply and what evidence the vendor can provide. “Deleted on request” should resolve into a process, duration and responsible system.
Run an export before commitment. Confirm formats, relationships, attachments, audit logs, metadata, API limits and the effort needed to make the export usable elsewhere. Portability is not proven by a download button if the organisation cannot reconstruct the records and controls it needs to continue operating.
Define termination access, transition support, deletion timing and any residual legal retention in the contract. Include configuration and derived data where they matter. The exit test should link to the organisation’s enterprise application architecture, because portability depends on surrounding systems as well as the vendor.
Turn answers into contract and operating controls
Place each material answer in the right control: contract commitment, configuration baseline, access procedure, review calendar, incident playbook or architecture record. A due-diligence response that remains in procurement email will be forgotten when the service changes. Give every ongoing control an owner and evidence source.
Use the software vendor evaluation scorecard to distinguish a hard data-location gate from a scored portability feature and a residual transfer risk. This prevents a strong user experience or low price from quietly compensating for a condition the organisation cannot accept.
Review after material product, subprocessor, region, legal or architecture changes. Also review before renewal. The most important data-residency answer is not a map that was correct at purchase; it is a maintained operating record that still reflects where data and access can move today.
The residency decision gate
Do not approve the service until the team can name the parties, purposes, data categories, storage and backup locations, remote-access locations, subprocessors, transfer mechanisms, supplementary controls, retention, deletion and exit path. Mark every missing item as a blocker, bounded risk or contractual action.
Involve security, privacy, architecture, procurement and the service owner, but keep one accountable decision maker. Each function sees a different failure mode. The final record should explain what was accepted, why the controls are proportionate and which change would trigger reassessment.
A clear answer may still be “this arrangement does not fit”. That is a useful outcome. Data residency review is successful when it makes the actual flow and responsibility visible before dependency grows, not when it finds wording that allows every proposed vendor to pass.
