Chapter V of GDPR creates the regulatory framework for transfers of personal data to countries outside the European Economic Area. The fundamental principle is that EEA-level protection must travel with the data: when personal data leaves the EEA, the data subject’s rights and the controller’s obligations must be maintained in the destination country to an equivalent standard. Where no mechanism achieves this equivalence, the transfer is prohibited.
Cross-border transfers are one of the most technically and legally complex areas of GDPR compliance — and one of the most frequently investigated by DPAs following the Schrems II judgment in 2020 and the subsequent invalidation of the EU-US Privacy Shield. Organisations that transfer data to the United States, to major cloud providers with infrastructure outside the EEA, or to any non-adequate country must have a compliant transfer mechanism in place before data leaves the EEA.
What Constitutes a Transfer Under Chapter V
A transfer occurs whenever personal data is made accessible to, or leaves to reach, a recipient in a third country outside the EEA. This includes: sending data to a server in a non-EEA country; granting remote access to EEA-held data from a non-EEA location; using a cloud service that stores data in non-EEA data centres; sharing data with a non-EEA entity in the same corporate group; and receiving support or maintenance access from non-EEA employees of a vendor.
COMMON TRANSFER SCENARIOS
| Scenario | Transfer? | Mechanism Required |
|---|---|---|
| Data sent to a US cloud provider with servers in the US | Yes | EU-US Data Privacy Framework (adequacy); SCCs; BCRs; or other Chapter V mechanism |
| EEA data stored in EEA data centres, accessed remotely by US-based support engineers | Yes | Access from a third country constitutes a transfer; SCCs or other mechanism required |
| Data stored on EEA servers by a US-headquartered SaaS provider | Depends on whether non-EEA entities have access | If US parent or affiliates can access, transfer mechanism required; EEA-only data centre clause insufficient alone |
| Intra-group data sharing from EU subsidiary to US parent company | Yes | BCRs (if group implements them); SCCs; or adequacy if applicable |
| Non-EU supplier receives anonymised data only | No transfer of personal data | No Chapter V mechanism required; but anonymisation must be genuine and irreversible |
| Data processed entirely within the EEA by an EEA-established processor | No | No Chapter V mechanism required; Article 28 DPA required instead |
Transfer Mechanism Overview
Chapter V provides a hierarchy of mechanisms that can lawfully enable a transfer. Adequacy decisions are the first and simplest mechanism: where the European Commission has determined that a third country provides an equivalent level of protection, transfers can proceed without additional safeguards. Where no adequacy decision exists, appropriate safeguards under Article 46 are required. Where neither is available, only specific derogations under Article 49 apply.
CHAPTER V TRANSFER MECHANISM HIERARCHY
| Mechanism | Article | When Available | Key Limitation |
|---|---|---|---|
| Adequacy decision | 45 | When European Commission has formally decided the destination country provides equivalent protection | Commission decision can be invalidated (Schrems I, Schrems II); must monitor for revocation |
| Standard Contractual Clauses (SCCs) | 46(2)(c)/(d) | When controller and recipient sign the Commission’s approved SCCs; supplemented by TIA where required | SCCs alone may not be sufficient where destination country surveillance laws override contractual protections |
| Binding Corporate Rules (BCRs) | 47 | For intra-group transfers where the group has obtained DPA approval of its BCRs | Approval process lengthy (12–18 months); only covers intra-group transfers; not available for third-party transfers |
| Codes of conduct + binding commitments | 46(2)(e) | Where a DPA-approved code of conduct exists for the sector and processor commits to binding enforcement | Limited availability; sector-specific; enforcement mechanisms must be legally binding |
| Certification mechanisms | 46(2)(f) | Where an approved certification mechanism exists covering international transfers | Currently limited availability; EU-US DPF is adequacy, not certification |
| Derogations (Article 49) | 49 | Explicit consent; contract performance; public interest; legal claims; vital interests; public register data; compelling legitimate interests (one-off) | Strictly interpreted; not for systematic or large-scale transfers; compelling LI derogation requires notification to DPA |
Adequacy Decisions: Current Status
As of 2025, the European Commission has adopted adequacy decisions covering the following countries and territories. Controllers transferring to these destinations can do so without additional Chapter V safeguards, though they must continue to monitor the adequacy decision status as decisions can be challenged or revoked.
CURRENT ADEQUACY DECISIONS (AS OF 2025)
| Country / Territory | Adequacy Status | Key Notes |
|---|---|---|
| Andorra, Argentina, Faroe Islands, Guernsey, Isle of Man, Israel, Jersey, New Zealand, Switzerland, Uruguay | Full adequacy | General transfers permitted without additional safeguards; monitor for any Commission review |
| Japan | Partial adequacy | Transfers to Japanese entities that have opted into APPI supplementary rules; verify recipient’s participation |
| UK | Adequacy (post-Brexit) | UK GDPR considered adequate by EU Commission; time-limited adequacy decision subject to review; monitor status |
| South Korea | Adequacy (2021) | Commercial transfers; excludes certain public sector and sensitive data categories; additional conditions may apply |
| United States | EU-US Data Privacy Framework (2023) | Transfers to US entities certified under the DPF; verify recipient’s DPF certification; subject to legal challenge |
| Canada | Partial adequacy (PIPEDA) | Commercial sector transfers only; federal public sector not covered; Quebec Law 25 modernisation ongoing |
The EU-US Data Privacy Framework replaced the invalidated Privacy Shield in 2023. Transfers to US-based processors and controllers are only covered by the DPF adequacy decision if the US recipient has self-certified under the framework. Controllers must verify DPF certification before relying on it, and must monitor for any legal challenge to the framework — previous US-EU transfer frameworks (Safe Harbour and Privacy Shield) were both invalidated by CJEU rulings.
Standard Contractual Clauses: The Primary Mechanism
Standard Contractual Clauses are the most widely used transfer mechanism for organisations that cannot rely on adequacy decisions. The European Commission adopted updated SCCs in June 2021, covering four transfer scenarios. These updated SCCs replaced the previous sets and must be used for new contracts — contracts concluded before September 2021 had until December 2022 to migrate to the new SCCs.
2021 SCCs — FOUR MODULE STRUCTURE
| Module | Covers | Typical Use Case |
|---|---|---|
| Module 1: Controller to controller | Transfer from an EEA controller to a non-EEA controller, where the recipient processes data for its own purposes | Sharing customer data with a non-EEA partner that uses it for its own marketing; data broker arrangements |
| Module 2: Controller to processor | Transfer from an EEA controller to a non-EEA processor, where the processor processes only on the controller’s instructions | Using a US-based SaaS provider; outsourcing processing to non-EEA data centre; non-EEA payroll provider |
| Module 3: Processor to processor | Transfer from an EEA processor acting on a controller’s instructions to a non-EEA sub-processor | EEA-based cloud provider passing data to non-EEA sub-processor; SaaS provider using non-EEA hosting |
| Module 4: Processor to controller | Transfer from an EEA processor back to a non-EEA controller that originally sent the data | Non-EEA controller using EEA-based processor; data returning to original non-EEA controller after EEA processing |
SCCs are not individually negotiable — the clauses approved by the Commission cannot be modified. However, the SCC package includes optional clauses and annexes that the parties complete with the specifics of their arrangement: the data categories transferred, the sub-processors engaged, the technical and organisational security measures applied, and any supplementary measures beyond the SCCs themselves.
Transfer Impact Assessments
Following the Schrems II judgment, the European Data Protection Board issued Guidelines 05/2021 on SCCs, requiring controllers to conduct a Transfer Impact Assessment before relying on SCCs for transfers to non-adequate countries. The TIA assesses whether the legal framework of the destination country — particularly its surveillance laws — would prevent the data importer from honouring its SCC obligations in practice.
TIA METHODOLOGY — FOUR STEPS
| Step | Activity | What to Document |
|---|---|---|
| 1. Identify the transfer | Map all personal data transfers to non-EEA countries; identify the parties, data categories, and transfer mechanism for each | Transfer map; data categories per transfer; mechanism relied on; country of destination |
| 2. Assess destination country law | Research the destination country’s data protection laws, surveillance legislation, and government access powers; identify any conflicts with SCC obligations | Summary of relevant laws; government access powers; any known conflicts with SCC obligations; EDPB/DPA guidance on specific countries |
| 3. Identify supplementary measures | Where destination country law creates risk, identify supplementary technical, contractual, or organisational measures that can mitigate the risk | Technical measures (encryption, pseudonymisation, access controls); contractual measures (enhanced SCC provisions); organisational measures (data minimisation, access limitations) |
| 4. Conclude and document | Based on the assessment, conclude whether the transfer can proceed; if not, identify whether alternative measures are possible or transfer must cease | TIA conclusion; reasoning; measures implemented; review date; signatory |
| KEY IDEA | A TIA does not need to conclude that the destination country provides perfect protection. It needs to assess whether, in practice, the transfer can take place with confidence that the data importer will be able to comply with the SCCs. Where strong encryption is applied before transfer and the importer holds no keys, government access powers in the destination country become largely moot — the data is inaccessible in plaintext regardless of legal orders. Technical measures of this kind are the most effective supplementary measure identified by the EDPB. |
Binding Corporate Rules
Binding Corporate Rules are an intra-group transfer mechanism that allows multinational organisations to transfer personal data between group companies in non-adequate countries, on the basis of an approved privacy framework that applies across the entire group. BCRs require approval from the lead DPA (typically the DPA in the country where the group’s EU headquarters is established) and are the most comprehensive — and most demanding — transfer mechanism to implement.
BCRS — KEY CHARACTERISTICS
| Dimension | Detail |
|---|---|
| Who can use BCRs | Corporate groups with entities in non-EEA countries; both controller BCRs and processor BCRs are available |
| Approval process | Application to lead DPA; cooperation procedure with other EU DPAs; typical timeline 12–18 months; significant legal and operational preparation required |
| Coverage | Only covers intra-group transfers; third-party transfers still require SCCs or other mechanism; BCRs must identify all group entities covered |
| Obligations | Group-wide binding privacy rules; staff training; internal audit; DPA cooperation; data subject rights across the group; breach notification process |
| Data subject rights | BCRs give data subjects enforceable rights against any group member; lead EU entity or nominated group entity must be liable for group member breaches |
| Who should consider BCRs | Large multinationals with significant non-EEA operations and frequent intra-group transfers; organisations where SCCs are operationally impractical due to volume |
Article 49 Derogations: Last Resort, Not Default
Article 49 derogations are intended as exceptions for specific situations, not as a systematic alternative to Chapter V mechanisms. The EDPB has consistently emphasised that Article 49 derogations cannot be used for systematic or repetitive transfers that require a proper transfer mechanism. Controllers that rely on derogations as their primary transfer mechanism — particularly the consent derogation or the contract performance derogation — without genuine analysis of whether a proper mechanism is available are building a non-compliant transfer programme.
ARTICLE 49 DEROGATIONS — CONDITIONS AND LIMITATIONS
| Derogation | Condition | Limitation |
|---|---|---|
| Explicit consent (49(1)(a)) | Data subject explicitly consented after being informed of the risks of the transfer to a non-adequate country | Cannot be used for employment data (employer-employee imbalance); cannot be used for systematic transfers affecting multiple individuals |
| Contract performance (49(1)(b)) | Transfer necessary for performance of contract between data subject and controller | Only covers data strictly necessary for the contract; not pre-contractual data or data processed alongside the contract for other purposes |
| Controller’s contract with third party (49(1)(c)) | Transfer necessary for conclusion or performance of a contract concluded in the interest of the data subject | Narrow; must genuinely be in the data subject’s interest, not the controller’s commercial interest |
| Important public interest (49(1)(d)) | Transfer necessary for important reasons of public interest recognised by EU or member state law | Must be a recognised public interest; commercial interests do not qualify |
| Legal claims (49(1)(e)) | Transfer necessary for the establishment, exercise, or defence of legal claims | Only for the specific data needed for the legal claim; ongoing commercial operations not covered |
| Compelling legitimate interests (49(1)(f)) | Transfer necessary for compelling legitimate interests of the controller, not repetitive, and involves limited data subjects | Requires prior DPA notification; not available if overridden by data subject interests; one-off transfers only |
| BITLION INSIGHT | The most common Chapter V compliance gap identified in practice is not the absence of SCCs — it is the use of outdated SCCs (pre-2021), SCCs executed with the wrong module for the relationship, or SCCs unaccompanied by a TIA for high-risk transfer destinations. Building a transfer mechanism register that maps each transfer to the correct mechanism, the correct SCC module, the executed agreement, and the TIA outcome creates the accountability record that Chapter V compliance requires. |