Short answer
Data residency is the physical location where data rests. Data sovereignty is the question of whose law governs access to it, and data localization is a legal duty to keep it in one country. The GDPR sets conditions for transfers of personal data outside the EEA and contains no general rule that data must stay in the EU. In an integration, check the region of both systems, the service between them, and its logs, queues, backups and monitoring tools.
On this page
Data residency vs data sovereignty, and where localization fits
The Treasury Board of Canada Secretariat defines data residency as the physical or geographical location of an organization's digital information. Docusign defines the term the same way.
The same paper defines data sovereignty, for Canada, as the country's right to control access to and disclosure of its digital information, subject only to Canadian laws. It records the gap between the two: data residency "does not mitigate against the application of foreign laws". A provider that answers to another country's courts can receive an order for data that sits in your region.
Data localization is a legal duty to keep data in one place. Regulation (EU) 2018/1807 defines a data localization requirement for non-personal data. It is a Member State requirement that "imposes the processing of data in the territory of a specific Member State" or hinders processing in another Member State. The regulation prohibits such requirements unless public security justifies them.
| Term | The question it answers | Who settles it |
|---|---|---|
| Data residency | Which region holds the data at rest. | You and your vendors, through each system's region setting. |
| Data sovereignty | Whose law governs access to the data. | The countries with authority over the data or over the company that holds it. |
| Data localization | Whether a law obliges you to keep the data in one country. | A legislature or a regulator. |
You find the first answer in each system's settings, and your counsel answers the other two.
GDPR and data residency: what the regulation says
The GDPR sets conditions for moving personal data out of the EEA. It contains no general rule that the data must stay in the EU. Article 1(3) states that the free movement of personal data within the Union "shall be neither restricted nor prohibited" on data protection grounds. The European Commission notes that the rules apply across the EEA, Iceland, Liechtenstein and Norway included.
Chapter V, Articles 44 to 50, governs a transfer to a country outside that area. Article 44 allows a transfer only if the controller and the processor meet the chapter's conditions, onward transfers included. The chapter names the transfer tools:
- An adequacy decision (Article 45). The Commission decides that a country protects personal data to an adequate level. Data then flows there "without any further safeguard being necessary".
- Appropriate safeguards (Article 46). The article lists binding corporate rules and standard data protection clauses adopted by the Commission. The Commission issued its modernized standard contractual clauses on 4 June 2021.
- Derogations (Article 49). These cover specific situations, such as the explicit consent of the data subject.
The European Data Protection Board defines a transfer by three criteria. The exporter falls under the GDPR for that processing, it makes the personal data available to another controller or processor, and that importer sits in a third country. If all three hold, the Board counts remote access from a third country as a transfer, "even if it takes place only by means of displaying personal data on a screen". The Board treats storage in a provider's cloud outside the EEA the same way.
US companies that participate in the EU-US Data Privacy Framework fall under an adequacy decision, and a court challenge to that decision is on appeal. The Commission adopted the decision on 10 July 2023. The General Court dismissed an action to annul the decision on 3 September 2025. On 27 September 2026 the appeal, case C-703/25 P, is pending before the Court of Justice.
Contracts and other laws add data residency requirements. A customer can write EU data residency into its terms. Article 49(5) lets Union or Member State law limit transfers of specific categories of personal data to a country without an adequacy decision. Article 9(4) lets Member States add conditions for genetic, biometric and health data.
Where data rests in an integration
Take a CRM account in Germany and a Docusign account in Europe. The service between them runs in whichever cloud region its developer chose, and each tool it writes to has a region of its own.
| Place | What rests there | What sets the region |
|---|---|---|
| The two systems of record | Records and documents. | The account's region, chosen at provisioning. |
| The integration service | Payloads in memory, plus any state or cache the code writes. | The cloud region in the deployment configuration. |
| Logs | Request and response bodies, if the code logs them. | The log store's region and retention period. |
| Queues and retries | Message bodies that wait for the next attempt. | The region of each queue and dead-letter queue. |
| Backups | Snapshots of the service's database and storage. | The backup plan and its copy rules. |
| Error tracking | Stack variables and request context. | The vendor region you pick at account creation. |
| Monitoring | Traces and forwarded logs. | The vendor site your agents send to. |
| Support access | Whatever the engineer's role can read. | The country the engineer works from. |
On AWS, you choose the Region that stores your content. AWS commits to keep it there unless a service you started, the law or a binding government order requires a move. You decide three settings:
- CloudWatch Logs keeps log data with no expiry date until you set a retention period.
- Amazon SQS keeps a queue and its messages within a single Region. It holds a message for 4 days by default and for 14 days at most.
- AWS Backup copies backups to other Regions on demand or on a schedule, so a copy rule for disaster recovery moves data out of the region.
Outside your cloud account, Sentry stores error events in the US or the EU, in the location you select as you create the organization. Datadog runs independent sites, one of them in the EU, and you cannot share data across sites.
Fluidlabs hosts the integrations it builds in the US (us-east-1), the EU (eu-west-1) or both, and the customer chooses where its data lives, databases and storage included (Partner Hosting).
What goes wrong in production
In each of these four failures, code or configuration moves personal data out of its region.
Payloads in logs
An error handler that logs the request body copies the payload to the log store: the signer's name, email address and field values. In the JSON SIM format, Docusign Connect sends data about the triggering event by default. It adds an envelope summary only if you request one in the configuration.
"includeData": [
"tabs",
"custom_fields",
"recipients",
"attachments"
]With each entry your listener receives more data, and a log line that prints the body copies it.
Fix. Subscribe to the event, read the envelopeId, and fetch the rest from the API inside your region. Log identifiers and leave the payload out. The OWASP logging guidance names access tokens and sensitive personal data among the items to remove, mask, sanitize, hash or encrypt before they reach a log. Our guides to Docusign Connect and webhook vs API cover the listener and the fetch.
A retry queue in another region
Your service puts a failed write to the CRM on a queue, and the queue keeps the message body until an attempt succeeds or the retention period ends. If a template creates that queue with the wrong region value, EU payloads sit in the wrong region for up to 14 days on SQS.
Fix. Create the queue and its dead-letter queue in the service's region, and make the deployment fail if the region value differs. Put record identifiers in the message in place of the record. Keep retention as short as your retry policy allows. Docusign Connect retries a delivery that fails at your listener, on a schedule that ends with one attempt per day over a 15-day span.
A monitoring tool that ships stack traces abroad
Sentry's documentation lists stack locals, breadcrumbs, user context and HTTP context among the places that carry sensitive data. If your organization sits in Sentry's US region, each event the SDK captures in your EU service carries that context to the US.
Fix. Choose the region before the first event. Sentry cannot change the location later: you create a new organization to switch. Scrub events in the SDK's beforeSend hook. Article 28(2) requires a processor to hold the controller's prior written authorization before it engages another processor, so ask your counsel whether the tool belongs on your list of sub-processors.
A support engineer who reads data from another country
The Board's guidelines treat remote access by a processor in a third country as a transfer under Chapter V. Example 11 describes access "for support purposes" to data that stays in the EU.
Fix. Ask each vendor which countries its support and operations staff work from and what their roles can read, and record the answer in the contract. Docusign states that support personnel can access basic transaction data and cannot access agreement data. HubSpot states that its staff may access customer data from other regions for support and development.
On the platforms you connect
Docusign, Salesforce and HubSpot each state that an integration, or the customer's own action, can move data out of the region.
Docusign. Docusign stores agreement data in one of five data center regions: the US, Canada, Europe, Australia and Japan. Its table lists eSign and IAM in all five, and CLM in the US, Europe and Australia. Docusign provisions an account in the region closest to the sign-up location, such as the company billing address, unless you work with a Docusign representative and choose the region. Docusign cannot move agreement data to another region after provisioning. It may copy transaction data across regions: the names and email addresses used for login, and audit-trail metadata. On integrations, Docusign states that data may leave your region and that the third-party provider determines where it goes.
An integration reads each account's base_uri from the userinfo endpoint. The Docusign example shows one user with two accounts, at https://eu.docusign.net and https://na3.docusign.net, so match the account ID before the service writes a document. Our Docusign API integration guide covers authentication and the base URI.
Salesforce. As a general rule, Salesforce stores customer data in the country of the org, provided the services in use run on Hyperforce in that country. Hyperforce on AWS covers 18 countries, Germany and France among them. Data can leave the country for processing, and some customer data may sit outside it for support and operations. Salesforce "does not prevent the customer themselves from moving customer data". To find the region of an org you run today, look up its instance name on the Salesforce Trust site.
HubSpot. HubSpot hosts accounts on AWS in Germany, Virginia, Oregon, Montreal and Sydney. If you buy a subscription on the website, HubSpot assigns a data center from your IP address at sign-up, and on a paid subscription you can change it. You find the location in settings under Privacy & Consent, on the Data Hosting tab. Among the cases that process data outside that location, HubSpot lists a marketplace app first: it "may process data and transfer data outside of the data center location".
NetSuite. NetSuite's data sheet lists data centers in North America, South America, Europe and Asia-Pacific, with Amsterdam, Frankfurt, London and Newport in Europe. London and Newport are in the United Kingdom, outside the EEA. NetSuite replicates data between data centers within each region, and its optional Premium Disaster Recovery keeps a synced backup in a remote region, so ask which data centers hold the account and the backup. The data sheet does not describe how a customer selects a data center. An account-specific domain does not depend on the data center and stays the same if the account moves, so the URL does not show the location.
Questions to ask before you build
Put these questions to each vendor in the chain and to whoever builds and hosts the integration.
- Which region hosts each system of record, and can the account move later?
- Which cloud region runs the integration service, and does the deployment fail if that value changes?
- Does the service store payloads, or does it pass them through and keep identifiers?
- Do the logs contain request bodies? Which region holds them, and for how many days?
- Which region holds each queue and dead-letter queue, and how long does a message live?
- Do backups stay in the region, or does a disaster recovery option name a second one?
- Which error tracking and monitoring vendors receive data, in which region, after which scrubbing?
- Which countries do support and operations staff work from, and what can their roles read?
- Which sub-processors sit in the chain, and which transfer tool covers each transfer outside the EEA?
This guide is not legal advice. Your counsel decides which residency requirements bind your company, which of these flows count as transfers, and which transfer tool covers each one.