Every organisation using SaaS systems, cloud services, email marketing tools, CRM platforms, or HR software should ask itself one question: where are my customers’ and employees’ data actually processed? If a vendor’s servers or technical operations are located outside the European Economic Area — this constitutes a transfer of personal data outside the EEA, which requires an appropriate legal basis. The absence of such a basis is one of the most frequently identified violations by European supervisory authorities, including the Dutch AP (€290 million fine against Uber) and the Irish DPC (€1.2 billion fine against Meta).
What Is a Transfer of Data Outside the EEA
The European Economic Area (EEA) covers the 27 EU member states plus Norway, Iceland, and Liechtenstein. Transferring personal data to an entity outside the EEA — or granting access to such data to a person or system located outside the EEA — constitutes a transfer within the meaning of Chapter V of the GDPR.
The transfer does not have to involve physically sending a file. It is sufficient that a vendor located outside the EEA has access to data — for example, through a cloud platform where servers are located in the United States, or through a support team based in a third country.
When Is a Transfer Outside the EEA Lawful
The GDPR allows transfers to third countries only where one of the mechanisms specified in Chapter V applies:
1. Adequacy decision The European Commission has recognised certain countries as providing an adequate level of data protection — comparable to that in the EU. Such countries currently include the United Kingdom, Japan, South Korea, Canada (for commercial organisations), Switzerland, Israel, and — following the adequacy decision adopted in 2023 — the United States under the EU-US Data Privacy Framework (DPF).
If a US vendor is certified under the DPF — a transfer to that vendor is permissible on the basis of the adequacy decision, without the need for additional safeguards.
2. Standard Contractual Clauses (SCCs) The most commonly used mechanism. SCCs are standard contract templates adopted by the European Commission that impose data protection obligations on both the data exporter and the data importer. The current SCCs were adopted in 2021 and replaced the previous versions.
SCCs alone may not be sufficient — if the law of the destination country may interfere with the level of protection, the data exporter should conduct a Transfer Impact Assessment (TIA) to verify that SCCs effectively protect the data in practice.
3. Binding Corporate Rules (BCRs) An internal mechanism for multinational groups. BCRs are binding data protection policies approved by the lead supervisory authority, allowing data transfers within the group. The approval process is lengthy — BCRs are used primarily by large multinationals.
4. Derogations for specific situations Used where none of the above mechanisms apply. Include: explicit consent of the data subject, performance of a contract with the data subject, important public interest grounds, legal claims. Derogations should be used only in exceptional cases and cannot constitute a regular basis for systematic transfers.
Practical Examples — Which Tools Require Attention
Google Workspace / Google Analytics — Google LLC is a US company. For Google Workspace, Google offers SCCs as part of its data processing terms. For Google Analytics — data is processed in the US; SCCs apply, but the TIA should be verified in light of US surveillance law.
Mailchimp / HubSpot / Salesforce — US-based providers. All offer SCCs. DPF certification should be checked on the official DPF list.
Slack / Microsoft 365 — both offer SCCs and data residency options (EU data storage) as part of enterprise plans.
Stripe / PayPal — payment processors operating globally. Both offer SCCs.
Transfer Impact Assessment (TIA)
When using SCCs as the transfer mechanism — particularly for transfers to the United States — organisations should consider conducting a Transfer Impact Assessment. A TIA verifies whether the law of the destination country contains provisions that could undermine the protection guaranteed by the SCCs.
The assessment covers: the legal framework of the destination country (particularly regarding government access to data), the categories of data transferred, the likelihood that public authorities will access the data, and the technical and organisational safeguards applied by the importer.
Where a TIA reveals that SCCs are not sufficient — supplementary measures must be implemented: encryption (with keys held by the data exporter), pseudonymisation, technical access restrictions.
How to Document Transfers in Practice
Transfers outside the EEA must be documented in the record of processing activities — for each processing activity where data is transferred to a third country, the destination country and the transfer mechanism applied must be identified.
Additionally: keep copies of concluded SCCs, DPF certification confirmations, and — where conducted — TIA documentation. This is the evidence required during a supervisory inspection.
Most Common Mistakes
Failure to identify transfers. Many organisations do not realise that using Google Analytics, Mailchimp, or Slack constitutes a transfer of personal data outside the EEA. The first step is mapping all vendors and tools used, with identification of where their servers and technical teams are located.
SCCs not signed. Using a US vendor without concluded SCCs — where the DPF or another adequacy decision does not apply — is an unlawful transfer. Most major vendors offer SCCs as part of their standard data processing terms — they simply need to be accepted or signed.
Transfers not documented in the RoPA. The record of processing activities must reflect transfers outside the EEA. Absence of this information is a deficiency identified during supervisory inspections.
Relying on consent as the primary basis. Consent of data subjects as the basis for transfers to third countries is permissible only in exceptional situations and cannot constitute the regular basis for systematic processing.
Summary
A transfer of personal data outside the EEA requires a legal basis under Chapter V of the GDPR. The most common mechanisms are the adequacy decision (including the EU-US DPF for certified US vendors) and Standard Contractual Clauses. SCCs may require a supplementary Transfer Impact Assessment. Every transfer must be documented in the record of processing activities. The first step is identifying all vendors and tools that process data outside the EEA.
FAQ
Yes — Google Analytics processes data on servers located in the United States. Google offers SCCs as part of its data processing terms, and Google LLC is certified under the EU-US Data Privacy Framework. However, depending on the configuration and the data collected, a TIA may be advisable.
The DPF is an adequacy decision adopted by the European Commission in 2023, allowing transfers of personal data from the EU to US organisations that are certified under the Framework. The list of certified organisations is available at the official DPF website.
In exceptional situations — yes. But consent must be explicit, informed about the risks of the transfer, and freely given. It cannot constitute the regular basis for systematic data transfers.
In practice, most major US vendors include SCCs in their standard data processing terms (DPA). Accepting the DPA on the vendor’s platform generally constitutes conclusion of the SCCs.
A TIA is an assessment of whether the law of the destination country may undermine the protection provided by SCCs. It is particularly relevant for transfers to the United States in light of US surveillance legislation. A TIA is not explicitly required by the GDPR but is recommended by the European Data Protection Board.
Document data transfers and processing agreements in one place
iGDPR lets you record transfers outside the EEA directly in the record of processing activities and manage data processing agreements with all your vendors in a single register. See how it works in practice.
START FREE TRIAL
