Cross-Border DSARs: Handling Access Requests Across Jurisdictions

When DSARs Cross Borders

If your business operates internationally — or even if it just has customers, employees, or vendors in more than one country — you will eventually receive a DSAR that does not fit neatly into a single jurisdiction's rules. A customer in Germany submits a request to your US headquarters. An employee in your London office requests data held by your Canadian parent company. A Brazilian consumer contacts your EU subsidiary about data processed by a third-party vendor in India.

These scenarios are increasingly common, and getting them wrong has consequences in multiple jurisdictions simultaneously. This guide covers how to determine which law applies, how to coordinate across legal frameworks, and how to build a workflow that handles cross-border DSARs without creating a compliance crisis.

For an overview of data protection laws by country, see our data protection laws by country guide.

Which Law Applies?

This is the first question, and the answer is often "more than one." Data protection laws are typically triggered by one or both of two factors: where the data subject is located, and where the controller or processor is established.

The GDPR Approach (EU)

The GDPR applies based on two criteria (Articles 2 and 3):

1. Establishment — if you have an establishment in the EU (an office, subsidiary, or branch), the GDPR applies to processing carried out in the context of that establishment's activities, regardless of where the processing actually takes place.
2. Targeting — even without an EU establishment, the GDPR applies if you offer goods or services to people in the EU, or monitor their behavior within the EU.

This means a US company with no EU office can still be subject to GDPR DSARs if it sells products to EU customers or tracks EU visitors on its website.

The UK GDPR Approach

The UK GDPR applies on the same basis as the EU GDPR but in relation to people in the UK. Since Brexit, the UK GDPR and the EU GDPR are separate legal instruments, so a company dealing with both EU and UK data subjects may be subject to both regulations simultaneously.

For more on how the UK framework has evolved, see our guide on the UK GDPR.

The CCPA Approach (California)

The CCPA applies to businesses that:

• Do business in California, AND
• Meet one of three thresholds (annual gross revenue over $25 million, buy/sell/share personal information of 100,000+ California residents, or derive 50% or more of annual revenue from selling/sharing personal information)

The CCPA is triggered by the business's connection to California and the consumer's California residency. A UK company selling to California residents may be subject to the CCPA.

The PIPEDA Approach (Canada)

PIPEDA applies to private-sector organizations that collect, use, or disclose personal information in the course of commercial activities. It also applies to personal information about employees of federally regulated businesses. Provinces like Quebec, British Columbia, and Alberta have their own substantially similar legislation.

For more on Canadian privacy law, see our PIPEDA jurisdiction guide.

The LGPD Approach (Brazil)

Brazil's Lei Geral de Protecao de Dados (LGPD) applies to any processing of personal data carried out in Brazil, where the data was collected in Brazil, or where the processing is aimed at offering goods or services to individuals in Brazil.

The Practical Result

For a business operating across borders, a single DSAR might trigger obligations under two, three, or more privacy laws simultaneously. A French customer of a US-based company with a UK subsidiary could potentially invoke rights under the EU GDPR, the CCPA (if the company meets the thresholds), and the UK GDPR (if the UK subsidiary processes the data).

You do not get to choose which law to apply. You must comply with every applicable law.

Common Cross-Border Scenarios

Scenario 1: EU Customer, US Controller

A customer in France submits a DSAR to your US headquarters. The EU GDPR applies because you offer goods or services to people in the EU (Article 3(2)). You must respond within one calendar month, provide all the information required by Article 15, and follow GDPR procedures for identity verification and exemptions.

If you also meet the CCPA thresholds and the customer happens to have California connections, CCPA obligations may also apply. In practice, responding to the GDPR's more comprehensive requirements will typically satisfy the CCPA as well, but verify this rather than assuming.

Scenario 2: UK Employee, Global Employer

An employee in your London office submits a SAR requesting all personal data held about them globally. Your London office holds HR records, but your US headquarters holds payroll data, your Indian shared services center holds benefits information, and your German subsidiary holds project records the employee contributed to.

The UK GDPR applies because the London office is an establishment processing the employee's data. The question is whether data held by other group entities is also in scope. If those entities process the data on behalf of or in the context of the UK establishment's activities, it is. If they are independent controllers processing the data for their own purposes, each entity's local law applies.

In practice, most multinational employers treat employee data as a shared responsibility. The safest approach is to coordinate a single response covering all data held across the group, applying the most protective standard (typically the GDPR or UK GDPR).

Scenario 3: Dual-Jurisdiction Consumer

A California resident who is also a UK citizen submits a DSAR to your business. They are entitled to exercise rights under both the CCPA and the UK GDPR (assuming you are subject to both). The timelines differ (45 calendar days for CCPA, one calendar month for UK GDPR), the scope of access rights differs, and the identity verification requirements differ.

The practical approach: respond to the stricter timeline and the broader scope, noting in your response which rights you are addressing under which law.

Scenario 4: Data Processed by a Third-Party Vendor Abroad

A data subject submits a DSAR to your EU-based company, but much of their personal data is held by a processor in a country outside the EU — for example, a cloud service provider in the US or a BPO center in the Philippines. The controller (your company) remains responsible for responding to the DSAR, regardless of where the data is physically processed.

You may need to:

• Request the data from your processor under the terms of your data processing agreement
• Ensure the processor provides the data within a timeframe that allows you to meet your response deadline
• Confirm that transferring the data back to you for disclosure does not create additional international transfer compliance issues

Coordinating Across Jurisdictions

Establish a Lead Entity

For multinational organizations, designate one entity as the lead for coordinating DSAR responses. This is typically the entity that has the most direct relationship with the data subject (the subsidiary in the country where the data subject is located, or the entity that collected the data).

The lead entity is responsible for:

• Receiving and acknowledging the request
• Coordinating data collection from other group entities
• Determining which laws apply and ensuring the response meets all applicable requirements
• Delivering the final response to the data subject

Create a Cross-Border DSAR Protocol

Document a protocol that all group entities follow when a DSAR requires cross-border coordination:

1. Routing — how requests are routed to the correct lead entity
2. Internal deadlines — internal turnaround times for each entity to provide data to the lead entity (these must allow enough time for review, redaction, and compilation before the external deadline)
3. Data transfer mechanisms — how personal data is transferred between entities securely and in compliance with international transfer rules
4. Conflict resolution — how to handle situations where different jurisdictions' requirements conflict (for example, if one jurisdiction's exemption would require withholding data that another jurisdiction requires be disclosed)
5. Communication — who communicates with the data subject, and how follow-up queries are handled

Handle Conflicting Requirements

Occasionally, the requirements of different jurisdictions genuinely conflict. Common conflicts include:

• Retention requirements — one jurisdiction may require you to retain data that another jurisdiction requires you to delete upon request
• Scope of access — one jurisdiction may require disclosure of data that another jurisdiction's law protects from disclosure (for example, trade secrets or national security information)
• Identity verification — CCPA requires a signed declaration under penalty of perjury for specific-pieces requests; GDPR does not require this specific mechanism

When conflicts arise, document the conflict and the basis for your decision. Generally, comply with the more protective requirement unless doing so would violate the other jurisdiction's law (not merely its preferences). When in genuine doubt, seek legal advice in both jurisdictions.

Building a Cross-Border Workflow

Map Your Data Flows

Before you receive a cross-border DSAR, understand where personal data flows within your organization. Document:

• Which entities hold personal data about which categories of individuals
• Where data is physically stored (which countries, which cloud regions)
• Which entities process data on behalf of other entities (processor vs. controller relationships)
• What data transfer mechanisms are in place (Standard Contractual Clauses, adequacy decisions, Binding Corporate Rules)

This mapping is required under GDPR Article 30 (records of processing activities) and is essential for efficient cross-border DSAR response.

Standardize Your Response to the Highest Standard

Rather than maintaining separate DSAR processes for each jurisdiction, build a single process that meets the most stringent requirements you are subject to. For most multinational businesses, this means a process that:

• Responds within one calendar month (the GDPR/UK GDPR standard, shorter than the CCPA's 45 days)
• Provides all information required by GDPR Article 15 (broader than most other laws)
• Follows GDPR-compliant identity verification (adaptable to CCPA's specific requirements when needed)
• Documents exemptions and withholdings with reference to the specific law being applied

This "highest common denominator" approach is simpler to manage and reduces the risk of under-compliance in any single jurisdiction.

Train Your Global Teams

Everyone in your organization who might receive a DSAR — not just the privacy team — needs to know the protocol. This includes:

• Recognizing a DSAR regardless of the language or format it arrives in
• Routing it to the correct lead entity immediately
• Understanding internal deadlines for providing data to the lead entity
• Knowing not to disclose data directly to the requester without going through the proper process

For guidance on DSAR training, see our DSAR training guide.

Practical Tips

Do not delay. Cross-border coordination takes time. Start the moment the request arrives, not two weeks later when you realize it involves multiple jurisdictions. The clock is already ticking.

Communicate proactively. If you need more time because of cross-border complexity, consider whether the applicable law allows a deadline extension and, if so, notify the data subject within the initial response period.

Keep a single file. Maintain one central record for each cross-border DSAR, including all internal correspondence, data collected from each entity, redaction decisions, and the final response. Fragmented records across multiple entities make it difficult to demonstrate compliance.

Account for language differences. If the data subject submitted their request in French but the data is held in English, you may need to consider whether translation is required. Under the GDPR, the response should be in a language the data subject can understand, which typically means the language of the request or the language of your relationship with the individual.

For the detailed side-by-side comparison of CCPA and GDPR response requirements, see our guide on DSAR response: CCPA vs GDPR.

References

• GDPR: Articles 2, 3, 12, 15, and 30. GDPR full text | Article 3 (Territorial scope)
• UK GDPR: ICO guidance on international transfers and individual rights. ICO UK GDPR guidance
• CCPA: Cal. Civ. Code §§ 1798.100–1798.199.100. Full text
• PIPEDA: Office of the Privacy Commissioner of Canada. OPC website
• LGPD (Brazil): Lei No. 13.709/2018. English summary

Related Guides

• Data Protection Laws by Country — global overview
• DSAR Response: CCPA vs GDPR — side-by-side comparison
• Building a DSAR Workflow — end-to-end process design

Navigate Multi-Jurisdiction Compliance

Our DSAR Compliance Guide includes jurisdiction-specific checklists and cross-border coordination templates designed for businesses operating across multiple data protection regimes.

Read the DSAR Compliance Guide