TL;DR
- Cross-border data transfer happens when personal data collected on your website is sent to servers in another country. GDPR Article 30 (ROPAs) and 28 (processor obligations), along with CCPA disclosure requirements, require website owners to document where data is sent.
- Start by inventorying who collects data (all third-party data collectors on your site). Map each data collector to a lawful basis.
- Monitor where data is actually sent. Look at external domains, hosting regions, and subprocessors. You can get a quick snapshot through manual inspection on browser developer tools. Or use an automated tool like cside Privacy Watch for ongoing monitoring.
- This information feeds into your privacy compliance documentation via ROPAs, DPAs, privacy disclosures, and incident audits. Additionally, sudden changes in data destinations (such as to Russia or China) are early signs of a website data breach.
4 Steps To Track Cross-Border & International Data Transfer on Your Website
1. Inventory who transfers data on your site
To track cross border data transfers, understand where data collection actually starts. This includes both first-party elements you directly control and third-party services embedded across your site.
First-party data collection (your own team):
First-party components like contact forms, CRM integrations, and internally built analytics tools can trigger outbound data flows. It’s easy to miss collection points on your site or be uncertain as to who owns them (marketing, support, or developers).
Third-party data collection (vendors and tools):
Third-party scripts deserve special attention. Most teams do not know how third party scripts work behind the scenes and there are dozens of them on a typical website according to research from Web Almanac. Tools such as analytics platforms, ad pixels, chat widgets, A/B testing scripts, or developer libraries load from external domains and may send personal data across borders without authorization.
Those third party scripts load in 4th party scripts, which can load in 5th party scripts, and on and on. You may have approved the 3rd party script but are blind to all the sub-processors down the supply chain.
EXPERT QUOTE: “Vendor inventories” that live in general compliance tools are a good start. But they do not monitor code execution in the browser. “It’s also possible for terminated vendors to still have live code on your website that wasn’t properly removed.”
Creating a manual inventory of all third party data collection on your website involves:
- Inspecting your site’s source code for third party snippets of code
- Inspecting tag managers (like Google Tag Manager) for hidden data trackers
- Repeating this process continuously as new scripts are added, removed, or updated.
Web security tools like cside automate this process with ongoing monitoring. You can get started with a free website scan of third party scripts.
2. Understand what data is transferred on your site
Once you know the first party and third party collection points on your site, your next goal is to understand what data they actually collect and send off-site.
- There are obvious inputs like names, email addresses, and phone numbers.
- Third party scripts quietly capture identifiers such as IP addresses, cookies, session IDs, device details, or location metadata.
- Sensitive data is entered through KYC flows (drivers licenses, passports) and support chatbots receive images of account data from customers.
Some individual data points are privacy-friendly, but when you combine them the data points collected can qualify as personal data under GDPR and may count as sharing under CCPA (even if the intent was simple site measurement).
That’s why each data flow needs to be tied back to its lawful basis category for each framework you are complying with.
Mapping data types to legal justification is how organizations show accountability during audits for CCPA “sharing” disclosures and respond to regulatory questions about data subject rights.
Your inventory should have columns with something like this-
With sensitive data you need to exercise extra caution. Health information, precise location data, biometric identifiers, or political opinions often require explicit consent and stronger safeguards. Even accidental collection can create compliance obligations, especially in regulated industries like healthcare.
3. Monitor where data is sent
Now you need visibility into where data goes once it leaves the user’s browser. First-party and third-party code will send data to external domains for storage or processing. Those external servers may be hosted in different states or countries.
- Your checkout form captures a customer's email in California, but your email service provider's servers are in Frankfurt
- A visitor in London loads your homepage. An analytics script sends data to servers in the US or APAC. You've just triggered an international data flow.
These destinations determine whether a data flow becomes a cross-border transfer with regulatory implications.
The Department of Justice restricts large transfers of sensitive personal data to countries of concern which include China, Russia, Iran, North Korea, Cuba, and Venezuela.
This isn’t a one-time review exercise. Third-party vendors and SDKs change their code frequently or add new subprocessors. A single update can shift data flows to a new country without notice. GDPR Article 44 and CCPA §1798.100 obligations around sharing and disclosure assume ongoing responsibility for tracking data movement.
Manual checks using browser DevTools or network monitoring tools like Chrome’s “Network” tab can instantly see where requests were sent. However, this becomes unmanageable because of scripts and domain changes. Plus, these manual reviews only show a quick snapshot making it inadequate for compliance documentation.
4. Document cross border transfers for regulatory requirements (GDPR & CCPA)
When regulators ask how personal data leaves your website, they expect an answer that is documented, not reconstructed after the fact.
Under GDPR, cross-border transfers are covered explicitly in Articles 44 to 50. These articles mandate organizations to record where data is sent, which safeguards apply to that data, and the legal mechanism supporting each transfer.
GDPR Article 30 (ROPAs) require documentation on data movement to third countries or international organizations.
GDPR Article 28 (Processor obligations) requires DPAs to show:
- Which subprocessors are used
- Where data is processed
- How onward transfers are handled
DPAs reflect what a vendor claims to be true. Without third party script monitoring it’s impossible to verify that third party scripts actually behave that way on your site. If a third party vendor is compromised in a supply chain attack, DPAs will be ignored and overcollection of data will take place without your team noticing.
CCPA focuses on transparency, businesses must show:
- Which third parties receive personal data
- Whether that data is considered a sale or a share
- How consumer rights apply across those disclosures
How cside helps with cross border data transfer tracking
cside Privacy Watch monitors every third party script on your website for security risks and hidden privacy violations. cside’s web security engineers specialize in monitoring code execution in the browser and they build Privacy Watch after realizing that traditional compliance software did not catch data exfiltration events.
As a layer in the enterprise GRC stack, cside’s website monitoring platform helps you:
- Track all data collection points on your website (from first-party code and third-party vendors)
- Alert when data destinations are changed or new data is collected from vendors
- Catch malicious code injected on your site that steals user data (web skimming)
- Identify misconfigured third party code on your website that violates privacy compliance
- Compare live website code to vendor inventories in your GRC tools to ensure that terminated vendors don’t have code still present on your website
Other best practices for cross border data transfer
Review your vendor policies
Start with the vendor’s privacy policy and DPA. Look for:
- Where data is processed
- Which subprocessors are involved
- Safeguards that processors have in place
Make sure to verify the stated policies with technical monitoring shows. Third party scripts may behave differently than stated DPAs if there are misconfigurations or malicious code injections. You can see examples of DPA tracking on our blog how to make your website GDPR compliant
Encrypt data in transit and storage
Encryption is an important safeguard when personal data moves across borders and between tools like CRMs, data warehouses, and APIs. It reduces exposure if data is intercepted or accessed by unauthorized parties.
Point to note here- encryption usually kicks in after a user’s submitted data (such as a form) enters the perimeter of your network/API security. Data can be stolen before it enters this perimeter through web skimming.
Which Laws Mandate Cross-Border Data Transfer Documentation:
| Privacy Framework | Requirement / Article | What it requires |
|---|---|---|
| GDPR | Articles 44 to 50 (Transfers to Third Countries) | Transfers outside the EU/EEA require approved safeguards |
| GDPR | Article 30 (ROPAs) | Controllers must document recipients in third countries and safeguards used |
| GDPR | Article 28 (DPAs) | DPAs must define processing locations and onward transfers to subprocessors |
| CCPA / CPRA | §1798.100 (Transparency) | Businesses must disclose categories of personal information collected and shared |
| USA Department of Justice | Data Security Program | Restrictions on cross-border data transfer to China, Russia, Iran, North Korea, Cuba, and Venezuela |
