Can I transfer personal data to the US under GDPR?

Yes, but only through an approved transfer mechanism. Since the adoption of the EU-US Data Privacy Framework in July 2023, organisations may transfer personal data to US companies that have self-certified under the framework. For transfers to non-certified US entities, you must rely on Standard Contractual Clauses with a Transfer Impact Assessment, Binding Corporate Rules for intra-group transfers, or one of the limited derogations under Article 49. The earlier Privacy Shield mechanism was invalidated by the Court of Justice of the European Union in the Schrems II ruling of July 2020.

What are Standard Contractual Clauses?

Standard Contractual Clauses (SCCs) are pre-approved contractual terms adopted by the European Commission that provide appropriate safeguards for the transfer of personal data to countries outside the EEA. The current SCCs, adopted in June 2021, follow a modular structure with four modules covering controller-to-controller, controller-to-processor, processor-to-processor, and processor-to-controller transfers. Organisations using SCCs must also conduct a Transfer Impact Assessment to evaluate whether the legal framework of the recipient country provides effective protection equivalent to that available in the EEA.

Is the EU-US Data Privacy Framework sufficient?

The EU-US Data Privacy Framework (DPF), adopted by the European Commission in July 2023, is a valid adequacy decision that permits transfers to self-certified US organisations without additional safeguards. However, its long-term stability is not guaranteed. Privacy advocacy groups have signalled their intention to challenge the framework before the Court of Justice of the European Union, as occurred with Safe Harbour and Privacy Shield. Organisations should monitor developments closely and maintain contingency plans — such as having SCCs in place — in the event the DPF is invalidated.

What is a Transfer Impact Assessment?

A Transfer Impact Assessment (TIA) is an evaluation that organisations must conduct before relying on Standard Contractual Clauses or Binding Corporate Rules for cross-border data transfers. The TIA examines whether the laws and practices of the recipient country provide an essentially equivalent level of data protection to that guaranteed within the EEA. It considers the specific circumstances of the transfer, including the type of data, the purposes of processing, the legal framework of the third country, and any supplementary measures — such as encryption or pseudonymisation — that can bridge any protection gaps identified.

Do I need SCCs if my cloud provider is in the EU?

Not necessarily for the primary hosting relationship, but you must look beyond the immediate provider. If your EU-based cloud provider uses sub-processors located outside the EEA, or if support staff in third countries can access the data, a cross-border transfer occurs and appropriate safeguards are required. Review your provider's sub-processor list and data processing agreement carefully. Many major cloud providers route support requests or perform maintenance from non-EEA locations, which constitutes a transfer under GDPR. Data residency controls that restrict processing to EEA regions can reduce but not always eliminate the need for SCCs.

What happens if an adequacy decision is revoked?

If the European Commission revokes an adequacy decision, transfers to the affected country can no longer rely on that decision and must immediately be supported by an alternative mechanism such as Standard Contractual Clauses or Binding Corporate Rules. The revocation does not typically take effect overnight — the Commission provides a transition period and advance notice. However, organisations should not wait for revocation to occur. Maintaining parallel transfer mechanisms, particularly SCCs with completed Transfer Impact Assessments, ensures continuity of data flows regardless of changes to adequacy decisions.

GDPR Cross-Border Data Transfers: A Compliance Guide

The General Data Protection Regulation restricts the transfer of personal data to countries outside the European Economic Area (EEA) unless the recipient jurisdiction offers an adequate level of data protection or the exporting organisation puts appropriate safeguards in place. Chapter V of the GDPR — Articles 44 through 50 — establishes this framework. The principle is straightforward: the protections afforded to individuals under European law must not be undermined simply because their data crosses a border.

For organisations operating internationally, these rules have profound practical consequences. Every SaaS subscription, cloud deployment, outsourced support function, and intra-group data flow that involves a non-EEA destination must be evaluated against the transfer provisions. Getting this wrong exposes organisations to enforcement action, with supervisory authorities across Europe increasingly treating unlawful transfers as a priority.

The Transfer Restriction Principle

Article 44 of the GDPR states that any transfer of personal data to a third country or international organisation may only take place if the conditions laid down in Chapter V are complied with. This applies to onward transfers as well — data initially transferred from the EEA to one third country cannot be forwarded to another without equivalent safeguards.

The definition of “transfer” is broad. It covers not only the physical movement of data but also remote access. If an engineer in India accesses a database hosted in Frankfurt to provide technical support, that constitutes a transfer. If a US-based SaaS platform processes personal data uploaded by an EEA-based customer, that is a transfer. The European Data Protection Board (EDPB) has confirmed that three cumulative conditions determine whether a transfer occurs: a controller or processor is subject to the GDPR for the processing in question, the controller or processor discloses or makes the data available to another entity, and the recipient is in a third country or is an international organisation.

Organisations must map their data flows to identify all transfers and then apply one of the lawful transfer mechanisms described below.

Adequacy Decisions (Article 45)

The simplest mechanism for cross-border transfers is an adequacy decision. Under Article 45, the European Commission may determine that a third country, a territory within a third country, or an international organisation ensures an adequate level of data protection. When an adequacy decision is in place, personal data can flow to the recognised jurisdiction without any additional authorisation or safeguard.

The Commission’s assessment considers several factors: the rule of law, respect for human rights, relevant legislation (including on public security, defence, and national security), the existence and effective functioning of independent supervisory authorities, and international commitments the country has entered into.

As of early 2026, adequacy decisions are in force for the following jurisdictions (among others):

United Kingdom — granted in June 2021, subject to a sunset clause requiring review by June 2025 (extended)
Japan — mutual adequacy arrangement since January 2019
South Korea — adequacy decision adopted in December 2021
Canada — for organisations subject to the Personal Information Protection and Electronic Documents Act (PIPEDA), covering commercial activities
New Zealand — adequacy decision in effect since December 2012
Israel — adequacy decision in effect since January 2011
Switzerland — recognised as adequate under the original Data Protection Directive, continued under GDPR
Argentina, Uruguay, and Guernsey, Jersey, Isle of Man, Faroe Islands, Andorra — various adequacy decisions carried over from the Directive era
United States — limited to organisations self-certified under the EU-US Data Privacy Framework (see below)

Adequacy decisions are not permanent. The Commission reviews them periodically and may amend or revoke them if the third country no longer provides adequate protection. The UK adequacy decision, for example, has been the subject of considerable scrutiny given post-Brexit legislative developments.

Standard Contractual Clauses (Article 46(2)(c))

Where no adequacy decision applies, Standard Contractual Clauses (SCCs) are the most widely used transfer mechanism. SCCs are sets of contractual terms approved by the European Commission that the data exporter and data importer incorporate into their data transfer agreements. They impose binding obligations on both parties and grant enforceable rights to the data subjects whose data is transferred.

The 2021 SCCs

The European Commission adopted new SCCs in June 2021 (Commission Implementing Decision (EU) 2021/914), replacing the earlier sets from 2001, 2004, and 2010. The 2021 SCCs must be used for all new contracts. Contracts concluded under the older SCCs that have not been updated are no longer valid as a transfer mechanism.

The 2021 SCCs adopt a modular approach with four distinct modules:

Module 1 — Controller to Controller (C2C): For transfers between two independent controllers. Applies when both parties determine the purposes and means of processing.
Module 2 — Controller to Processor (C2P): The most common module for SaaS and cloud relationships. Applies when the EEA-based controller engages a non-EEA processor.
Module 3 — Processor to Processor (P2P): Covers sub-processing chains where an EEA-based processor engages a sub-processor outside the EEA on behalf of an EEA controller.
Module 4 — Processor to Controller (P2C): A less common scenario where a non-EEA entity acts as controller and the EEA entity processes data on its behalf. Relevant for EEA-based service providers serving non-EEA clients when the data relates to EEA individuals.

Organisations must select the correct module for each transfer relationship and complete the annexes specifying the details of the transfer — the parties, the categories of data, the purposes, and the technical and organisational measures in place.

Transfer Impact Assessments

Since the Schrems II judgment, SCCs alone are not sufficient. Organisations must also conduct a Transfer Impact Assessment (TIA) to determine whether the laws and practices of the third country impinge on the effectiveness of the safeguards provided by the SCCs. The TIA must be documented and should cover:

The specific circumstances of the transfer (nature of the data, sector of activity, length of the processing chain, number of actors involved)
The laws and practices of the third country that may affect the data importer’s ability to comply with the SCCs, with particular attention to government access provisions and surveillance laws
Any supplementary measures that can be applied to fill identified gaps

The EDPB’s Recommendations 01/2020 on supplementary measures provide a six-step methodology for this assessment. If the TIA concludes that the third country’s laws undermine the protection afforded by the SCCs and no supplementary measures can cure the deficiency, the transfer must not proceed.

Supplementary Measures

Supplementary measures fall into three categories:

Technical measures: Encryption where the exporter retains sole control of keys, pseudonymisation where the mapping table remains in the EEA, split processing so that no single entity in the third country holds meaningful data
Contractual measures: Additional commitments by the importer to challenge government access requests, to notify the exporter of any legally binding requests for disclosure, to provide transparency reports
Organisational measures: Internal policies restricting access to transferred data, audit rights, staff vetting and confidentiality obligations, establishment of a dedicated data protection team at the importer

In practice, technical measures — particularly strong encryption with EEA-held keys — offer the most robust protection, because they render the data unintelligible to third-country authorities regardless of local law.

Binding Corporate Rules (Article 47)

Binding Corporate Rules (BCRs) are internal codes of conduct adopted by multinational corporate groups to permit the transfer of personal data between group entities located in different countries. BCRs must be approved by a competent supervisory authority through a co-operation procedure involving other concerned authorities.

When BCRs Are Appropriate

BCRs are designed for intra-group transfers. They are most suitable for large multinational organisations with significant volumes of personal data flowing between subsidiaries and affiliates across jurisdictions. BCRs are not available for transfers to external third parties — those must rely on SCCs or another mechanism.

The Approval Process

Obtaining BCR approval is a substantial undertaking. The process typically takes 12 to 24 months and involves:

Drafting the BCRs in accordance with Article 47 requirements and EDPB guidance (WP256 rev.01 and WP257 rev.01)
Selecting a lead supervisory authority based on the location of the group’s European headquarters or its EU representative
Submitting the application with supporting documentation, including a description of the group structure, data flows, and the BCR text
A co-operation procedure with other concerned supervisory authorities
Formal approval by the lead authority

BCRs must include legally binding obligations on all members of the group, explicit rights for data subjects as third-party beneficiaries, details of the co-operation mechanism with supervisory authorities, the mechanism for reporting and recording changes, and the training programme for staff involved in data transfers.

Despite the effort involved, BCRs offer significant advantages for qualifying organisations: they provide a single, unified framework for all intra-group transfers globally, they demonstrate a high level of accountability, and they are well regarded by supervisory authorities.

Derogations (Article 49)

Article 49 provides a set of derogations that permit transfers in specific situations where neither an adequacy decision nor appropriate safeguards such as SCCs or BCRs are in place. These derogations are to be interpreted restrictively and are not intended as a basis for systematic or large-scale transfers. They include:

Explicit consent: The data subject has explicitly consented to the transfer after being informed of the risks arising from the absence of an adequacy decision and appropriate safeguards. Consent must be genuinely informed, specific, and freely given — a broad consent buried in terms of service will not suffice.
Contractual necessity: The transfer is necessary for the performance of a contract between the data subject and the controller, or for pre-contractual measures taken at the data subject’s request. This covers scenarios such as booking international travel or purchasing goods from a non-EEA vendor.
Important reasons of public interest: The transfer is necessary for important reasons of public interest recognised in Union or Member State law.
Legal claims: The transfer is necessary for the establishment, exercise, or defence of legal claims.
Vital interests: The transfer is necessary to protect the vital interests of the data subject or another person, where the data subject is physically or legally incapable of giving consent.

The EDPB has repeatedly emphasised that derogations under Article 49 are exceptions and must not be used to circumvent the requirement for appropriate safeguards. For routine, ongoing business transfers, SCCs or BCRs remain the expected mechanism.

The Post-Schrems II Landscape

The Court of Justice of the European Union’s judgment in Data Protection Commissioner v. Facebook Ireland Ltd and Maximillian Schrems (Case C-311/18) — commonly known as Schrems II — reshaped the international data transfer regime in July 2020.

What Schrems II Changed

The Court invalidated the EU-US Privacy Shield adequacy decision on the grounds that US surveillance programmes (particularly those under Section 702 of the Foreign Intelligence Surveillance Act and Executive Order 12333) did not meet the standards of necessity and proportionality required by EU law, and that US law did not provide EU data subjects with actionable judicial redress.

Critically, the Court also held that SCCs remain valid in principle but that data exporters cannot rely on them mechanically. Before transferring data, the exporter must verify, on a case-by-case basis, whether the law of the third country ensures adequate protection. If it does not, the exporter must identify and implement supplementary measures to bring the level of protection up to the EU standard. If no supplementary measures can achieve this, the transfer must be suspended or terminated.

Practical Consequences

Schrems II imposed a due diligence obligation on every organisation relying on SCCs. In practice, this means:

Every transfer relationship requires a documented TIA
Organisations must actively monitor the legal landscape of recipient countries for changes
Supervisory authorities can — and do — order the suspension of specific transfers where safeguards are found to be insufficient
Reliance on the contractual commitments of a data importer alone is not enough if the importer is subject to laws that compel disclosure to government authorities without adequate oversight

Several supervisory authorities have taken enforcement action based on Schrems II, including the Austrian, French, and Italian authorities’ coordinated decisions on the use of Google Analytics, which found that the tool transferred personal data to the US without adequate supplementary measures.

The EU-US Data Privacy Framework

In response to Schrems II, the European Commission and the US government negotiated a new framework — the EU-US Data Privacy Framework (DPF) — which the Commission recognised as adequate in July 2023 (Commission Implementing Decision (EU) 2023/1795).

How It Works

The DPF is underpinned by Executive Order 14086, signed by the US President in October 2022, which introduced new safeguards for US signals intelligence activities. Key elements include:

Proportionality and necessity requirements imposed on US intelligence agencies when collecting signals intelligence involving personal data of non-US persons
A two-tier redress mechanism consisting of the Civil Liberties Protection Officer within the Office of the Director of National Intelligence (first tier) and the Data Protection Review Court (second tier), which can issue binding decisions including ordering the deletion of data collected in violation of the safeguards
Self-certification by US organisations through the International Trade Administration within the US Department of Commerce. Only organisations that have self-certified — and remain on the DPF list — benefit from the adequacy decision.

Self-Certification

US organisations must commit to a set of principles (notice, choice, accountability for onward transfer, security, data integrity and purpose limitation, access, and recourse, enforcement, and liability) and submit to enforcement by the Federal Trade Commission or the Department of Transportation. Self-certification must be renewed annually.

Stability Concerns

The DPF faces the same structural challenge as its predecessors. Privacy advocacy organisation noyb (None of Your Business) has announced its intention to challenge the DPF before the CJEU, arguing that Executive Order 14086 does not substantively change the US surveillance practices that led to the invalidation of Privacy Shield. The first review of the DPF by the Commission was conducted in late 2024. Organisations transferring data under the DPF should maintain fallback mechanisms.

Cloud Providers and International Transfers

The relationship between EEA-based organisations and cloud infrastructure providers is one of the most common contexts for international data transfers. Even when a cloud provider offers EEA-based hosting, transfers may still occur through several vectors.

Sub-Processor Chains

Major cloud providers maintain extensive sub-processor networks. A provider hosting data in Frankfurt may engage sub-processors for monitoring, security operations, or customer support that are based in the US, India, or the Philippines. Each sub-processor with access to personal data triggers a transfer obligation.

Organisations should:

Review the provider’s complete sub-processor list (most major providers publish these)
Ensure the data processing agreement covers onward transfers and requires the provider to impose equivalent obligations on sub-processors
Assess whether the SCCs executed with the provider extend to sub-processor relationships (Module 3)
Monitor changes to the sub-processor list — most processing agreements grant the provider the right to add sub-processors with prior notice

Practical Due Diligence

When evaluating a cloud provider’s cross-border transfer posture, consider:

Data residency options: Does the provider offer the ability to restrict data storage and processing to EEA regions?
Access controls: Can remote access from non-EEA locations be disabled or restricted?
Encryption architecture: Does the provider support customer-managed encryption keys (CMEK) or bring-your-own-key (BYOK) models?
Government access transparency: Does the provider publish transparency reports detailing government access requests?
Contractual protections: Does the provider commit to challenging overbroad government requests and notifying the customer where legally permitted?

SaaS-Specific Considerations

SaaS applications introduce additional complexity because data processing often spans multiple jurisdictions by design, and customers may have limited visibility into the underlying infrastructure.

Multi-Region Hosting

Many SaaS providers operate a global infrastructure with data replicated across regions for performance and resilience. Organisations must verify:

Whether they can select an EEA-only hosting region
Whether backups, disaster recovery replicas, or content delivery network caches are stored outside the EEA
Whether the provider’s architecture routes any processing through non-EEA nodes (even transiently)

Data Residency Controls

Increasingly, SaaS providers offer data residency features that restrict processing to specified regions. These controls can significantly simplify the transfer compliance picture but must be evaluated carefully:

Do the residency controls cover all data categories, including metadata, logs, and analytics?
Are support interactions routed through EEA-based teams, or can support agents in third countries access customer data?
Does the provider contractually warrant the residency restrictions, or are they offered on a best-effort basis?

Vendor Assessment for Transfer Compliance

A structured vendor assessment should address:

Where personal data will be stored and processed
Which sub-processors will have access and their locations
What transfer mechanisms are in place (SCCs, DPF self-certification, or both)
Whether a TIA has been conducted and is available for review
What supplementary measures are implemented
What happens if a transfer mechanism is invalidated — does the provider offer contractual commitments to maintain data within the EEA?

Comparison of Transfer Mechanisms

Mechanism	Legal Basis	Scope	Approval Required	Typical Use Case	Ongoing Obligations
Adequacy Decision	Article 45	All transfers to recognised country	None (Commission decision)	Transfers to UK, Japan, South Korea, Canada (commercial)	Monitor for revocation or amendment
EU-US Data Privacy Framework	Article 45 (adequacy)	Transfers to self-certified US organisations	US entity must self-certify	US SaaS and cloud providers	Verify recipient’s DPF certification annually; maintain fallback SCCs
Standard Contractual Clauses	Article 46(2)(c)	Any transfer to any third country	No prior authorisation	Most common mechanism for vendor and cloud relationships	Conduct and maintain TIA; implement supplementary measures; monitor third-country law
Binding Corporate Rules	Article 47	Intra-group transfers	Supervisory authority approval (12-24 months)	Multinational corporate groups	Annual reporting; update for group changes; co-operate with supervisory authorities
Article 49 Derogations	Article 49	Limited, specific situations	None	Occasional, non-systematic transfers (e.g., booking travel, legal claims)	Document the specific justification for each transfer; cannot be used for routine flows

Building a Sustainable Transfer Compliance Programme

Cross-border data transfer compliance is not a one-time exercise. Organisations should embed transfer compliance into their broader data governance framework through the following practices:

Maintain a transfer register: Document all cross-border data flows, the mechanism relied upon, the date of the most recent TIA, and the supplementary measures in place. This register should be reviewed quarterly.
Monitor regulatory developments: Track adequacy decision reviews, CJEU challenges to the DPF, new EDPB guidance, and legislative changes in key recipient countries.
Conduct periodic TIA reviews: TIAs are not static documents. Revisit them whenever the legal landscape of a recipient country changes, when the nature or volume of data transferred changes, or at least annually.
Maintain fallback mechanisms: Where transfers rely on an adequacy decision or the DPF, have SCCs in place as a contingency. The cost of pre-positioning SCCs is negligible compared to the disruption of suspending transfers at short notice.
Engage procurement and legal teams: Transfer compliance begins at the vendor selection stage. Procurement teams should include transfer mechanism requirements in RFPs and evaluate vendors’ ability to support EEA data residency.
Train staff: Ensure that teams involved in data handling, vendor management, and IT operations understand the basics of transfer compliance and know when to escalate.

The regulatory environment for cross-border data transfers continues to evolve. Organisations that invest in robust, adaptable transfer compliance frameworks — rather than treating each transfer as an isolated legal question — will be best positioned to maintain uninterrupted data flows while meeting their obligations under the GDPR.