Art.44.Onward GDPR

GDPR Art.44.Onward: Onward Transfers to Third Countries

What This Control Requires

Any transfer of personal data which are undergoing processing or are intended for processing after transfer to a third country or to an international organisation shall take place only if, subject to the other provisions of this Regulation, the conditions laid down in this Chapter are complied with by the controller and processor, including for onward transfers of personal data from the third country or an international organisation to another third country or to another international organisation.

In Plain Language

Data does not always stop at the first destination. When personal data leaves the EEA and then gets forwarded from that third country to yet another third country or international organisation, each hop in the chain must independently comply with Chapter V. The GDPR is explicit about this: protection must follow the data all the way through, from the original EEA exporter to the final recipient. The practical difficulty is visibility. Once you send data to a processor in Country A, that processor might engage a sub-processor in Country B, or a controller in Country A might share data with a partner in Country C. Each of those downstream movements is an onward transfer requiring its own legal basis. Many organisations simply do not know these onward transfers are happening. The 2021 Standard Contractual Clauses tackle this head-on. Under Module 2 (controller-to-processor) and Module 3 (processor-to-processor), the data importer may only transfer data onward with your documented instructions or consent, and must ensure the downstream recipient is bound by SCCs, sits in an adequate country, or provides equivalent safeguards. The importer also has to give you information about onward transfers on request.

How to Implement

Map every onward transfer in your data flow chains. For each international transfer from the EEA, trace whether the initial recipient sends the data further - through sub-processor chains, affiliated company sharing, cloud provider cross-region replication, or any other downstream flow. Most organisations find transfers they did not know about during this exercise, which is precisely why it matters. Make sure each onward transfer has its own valid Chapter V mechanism. An adequacy decision covering the first destination does not extend to countries further down the chain. SCCs between you and the initial importer do not automatically protect the next leg. Assess and cover each link independently. Build onward transfer controls into your contracts. Require data importers to notify you before any onward transfer happens, obtain your prior written consent, ensure downstream recipients are bound by equivalent obligations (via SCCs, BCRs, or similar), and run their own Transfer Impact Assessments for each onward transfer. Extend your Transfer Impact Assessments to cover the full chain. If data flows EEA to Country A to Country B, assess the legal frameworks of both countries. A weak link anywhere in the chain undermines the whole arrangement - regulators will look at the end-to-end picture, not just the first hop. Monitor onward transfer compliance continuously. Require importers to report annually on onward transfers that took place, the legal mechanisms applied, and any government access requests received. Use your audit rights to verify these provisions are actually being followed. If you find non-compliance, enforce your contractual rights promptly or suspend the initial transfer if needed.

Evidence Your Auditor Will Request

Complete data transfer chain mapping including all onward transfers
Legal mechanism documentation for each onward transfer in the chain
Contractual provisions requiring prior consent and notification for onward transfers
Transfer Impact Assessments covering the full data transfer chain
Audit records of onward transfer compliance monitoring

Common Mistakes

No visibility into onward transfers - initial data importer transfers data further without knowledge or consent
Onward transfers lack their own independent legal mechanism under Chapter V
Transfer Impact Assessments only cover the initial transfer and not the full chain
DPAs and SCCs do not include provisions restricting or governing onward transfers
Sub-processor chains not mapped, leading to uncontrolled onward transfers through multiple countries

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	A.5.20	Related
ISO 27001	A.5.34	Related

Frequently Asked Questions

If we use SCCs with our processor, are onward transfers automatically covered?

No, they are not. Your SCCs cover the initial transfer to your processor, but they do not automatically extend to wherever the processor sends data next. The Module 2 and Module 3 SCCs do include onward transfer restrictions and conditions, but you need to verify those conditions are actually being met for each downstream transfer. Do not assume coverage - check it.

How do we control onward transfers by our processors?

Put clear contractual restrictions in your DPAs and SCCs. Require prior written consent before any onward transfer. Keep an approved sub-processor list with locations. Make the processor flow down equivalent data protection obligations to every downstream recipient. Audit their onward transfer practices periodically, and use your right to object when a new sub-processor sits in a jurisdiction that concerns you.

Do onward transfers within a cloud provider's infrastructure count?

Yes, they do. If a cloud provider replicates data between data centres in different third countries, or lets support staff in third countries access it, each of those movements is an onward transfer under Chapter V. This is exactly why many organisations insist on EEA-only data residency from their cloud providers, or at minimum require full documentation of where data can travel.

Track GDPR compliance in one place

AuditFront helps you manage every GDPR control, collect evidence, and stay audit-ready.

Start Free Assessment