When may personal data be transferred outside the EU?

In brief

Personal data may be transferred outside the European Union (EU) only when the General Data Protection Regulation (GDPR) transfer rules are met. The usual route is an adequacy decision under the GDPR's Article 45. If there is no adequacy decision, the controller or processor needs appropriate safeguards under the GDPR's Article 46, such as standard contractual clauses. If neither route is available, the GDPR's Article 49 allows only narrow derogations for special situations.

A transfer is not just a contract line, but part of personal data processing

An international transfer is a GDPR issue because the data remains personal data after it leaves the EU. A customer name in a support ticket, an employee email address in an outsourcing system or a patient identifier in a cloud log can all be personal data if a person can be identified from it.

The GDPR's Article 44 sets the starting point. A transfer to a third country or an international organisation may happen only if the controller and the processor meet the conditions in the GDPR transfer chapter. The rule also covers onward transfers from that third country or international organisation to another third country or another international organisation.

This means the transfer basis is only one part of the decision. You still need the rest of the GDPR to be in order. The GDPR's Article 5 requires lawful, fair and transparent processing, purpose limitation, data minimisation, storage limitation, security, and accountability. In everyday terms, a supplier contract cannot make an unnecessary export of employee data lawful if the organisation does not need that data for the purpose.

The role of the supplier also matters. If a supplier processes personal data for the controller, the GDPR's Article 28 requires a processor arrangement. The processor must process personal data only on documented instructions from the controller, including instructions on transfers to a third country or international organisation. The controller and processor question is explained further in Controller or processor: when a data processing agreement is needed and what Article 28 requires.

An adequacy decision is the easiest route, but it must be identified correctly

An adequacy decision means that the European Commission has decided that a third country, a territory, one or more specified sectors, or an international organisation ensures an adequate level of data protection. Under the GDPR's Article 45, personal data may be transferred on that basis without a specific authorisation.

The practical point is scope. The decision may concern a whole country, a territory, a sector or an international organisation. You therefore need to know which recipient receives the data and whether the decision actually covers that transfer. A general note that a supplier is outside the EU is not enough.

The GDPR's Article 45 also shows why adequacy is not a one-time assumption. The Commission's decision must provide for a periodic review at least every four years. The Commission also monitors developments in third countries and international organisations that may affect the functioning of existing decisions. If the level of protection is no longer adequate, the Commission may repeal, amend or suspend the decision without retroactive effect.

For work purposes, an adequacy route should answer these questions:

Question	Why it matters
Who receives the personal data?	The recipient may be in a third country or may be an international organisation.
What is the exact country, territory, sector or organisation?	The adequacy decision may not cover every transfer in the same way.
Is the transfer direct or onward?	The GDPR's Article 44 also covers onward transfers.
What personal data and data subjects are involved?	The transfer is still subject to the GDPR principles in Article 5.

Standard contractual clauses and other safeguards apply when there is no adequacy decision

If there is no adequacy decision, the GDPR's Article 46 allows a transfer only when appropriate safeguards have been put in place and data subjects have enforceable rights and effective legal remedies. A safeguard is a practical and legal protection. In everyday terms, it is not only a promise in a purchase order. It must support the person's ability to enforce their rights if the transfer causes a problem.

The best-known safeguard is the standard contractual clauses. Under the GDPR's Article 46, these can be data protection standard clauses adopted by the Commission, or clauses adopted by a supervisory authority and approved by the Commission. The same Article also recognises other safeguards.

Appropriate safeguards that do not require specific supervisory authority authorisation include:

• a legally binding and enforceable instrument between public authorities or bodies;
• binding corporate rules under the GDPR's Article 47;
• Commission standard contractual clauses;
• supervisory authority standard contractual clauses approved by the Commission;
• an approved code of conduct together with binding and enforceable commitments by the third-country recipient;
• an approved certification mechanism together with binding and enforceable commitments by the third-country recipient.

Some safeguards do require authorisation from the competent supervisory authority. The GDPR's Article 46 names contractual clauses between the exporting and receiving parties, and provisions in administrative arrangements between public authorities or bodies that include enforceable and effective rights for data subjects.

A common procurement error is to treat standard contractual clauses as a replacement for all other GDPR documentation. They are not. If the recipient is a processor, Article 28 still matters. If the processing is high risk, the data protection impact assessment rules may also matter. The DPIA route is explained in Data protection impact assessment: when a DPIA is mandatory and what goes into it.

Derogations are the last route, not the normal procurement model

The GDPR's Article 49 deals with derogations for specific situations. These are available when there is no adequacy decision and no appropriate safeguards, including binding corporate rules. That structure matters. Article 49 is not the first place to look when a regular service provider is being selected.

The Article 49 derogations include explicit consent after risk information, necessity for a contract with the data subject, necessity for a contract in the data subject's interest, important public interest, legal claims, vital interests where the data subject cannot give consent, and certain transfers from public registers.

Consent is a narrow example. The data subject must give explicit consent to the proposed transfer after being informed of possible risks caused by the absence of an adequacy decision and appropriate safeguards. This is different from a general privacy notice sentence that says data may be processed globally.

Article 49 also contains a final fallback for a transfer that cannot rely on Articles 45 or 46 and where none of the listed derogations applies. That fallback is tightly limited. The transfer must not be repetitive. It must concern only a limited number of data subjects. It must be necessary for compelling legitimate interests of the controller, and those interests must not be overridden by the interests or fundamental rights and freedoms of the data subject. The controller must assess all the circumstances of the transfer, put in place appropriate safeguards, inform the supervisory authority, and give the data subject information about the transfer and the compelling legitimate interests.

There is an important public-sector limit. The GDPR's Article 49 says that the explicit consent route, the contract routes, and the final compelling-interest fallback do not apply to activities carried out by public authorities in the exercise of their public powers. For a municipality or other public body, this makes Article 49 a route that needs especially careful role and purpose analysis.

The data subject must be told about the transfer in understandable language

A data subject is the person the personal data is about. A customer, an employee, a pupil and a service user can all be data subjects. The transfer route should appear in information given to that person when the GDPR requires it.

The GDPR's Article 12 requires information to be concise, transparent, intelligible, easily accessible and in clear and plain language. In workplace terms, a privacy notice should not hide an international transfer behind vague wording such as global processing partners. It should say what the transfer is about in terms a person can understand.

When personal data is collected from the data subject, the GDPR's Article 13 requires information about the controller, the purposes and legal basis, recipients, and planned transfers to a third country or international organisation. If a transfer is planned, the information must cover the existence or absence of an adequacy decision. If the transfer uses Article 46 or Article 47 safeguards, or the Article 49 route named in the provision, the controller must also tell the data subject about the safeguards and how to get a copy of them or where they are available.

When personal data is not obtained from the data subject, the GDPR's Article 14 contains the corresponding information duty. It also sets timing rules. The information must be given within a reasonable period and at the latest within one month after obtaining the personal data, or at first contact if the data is used for communication, or at the first disclosure if the data is to be disclosed to another recipient.

The right of access can also surface transfers. Under the GDPR's Article 15, the data subject has the right to receive information about recipients or categories of recipients, especially recipients in third countries or international organisations. If personal data is transferred to a third country or international organisation, the data subject has the right to be informed of the appropriate safeguards under Article 46. Related request handling is covered in Data subject rights: when a customer asks for their data, you have a month.

What should be documented about transfers

The GDPR is built on accountability. The GDPR's Article 5 says the controller is responsible for compliance and must be able to demonstrate it. The GDPR's Article 24 requires the controller to implement measures that ensure and demonstrate that processing complies with the Regulation, taking into account the nature, scope, context, purposes and risks of processing.

The record of processing activities is one practical place where transfers appear. Under the GDPR's Article 30, the controller's record must include categories of recipients, including recipients in third countries or international organisations. Where relevant, it must also include information about transfers to a third country or international organisation, including the third country or international organisation, and the documentation of appropriate safeguards for the Article 49 fallback route.

Processors also have their own record duty under Article 30. A processor's record must include the categories of processing carried out on behalf of each controller and, where relevant, information about transfers to a third country or international organisation, including the country or organisation and the safeguard documentation for the Article 49 fallback.

There is a limited Article 30 exception for an enterprise or organisation with fewer than 250 employees. That exception does not apply if the processing is likely to result in a risk to the rights and freedoms of data subjects, is not occasional, or includes special categories of personal data or personal data relating to criminal convictions and offences. More on the record itself is covered in What must a record of processing activities contain?.

Good transfer documentation usually connects four things: the processing purpose, the recipient and location, the transfer route, and the safeguards or exception relied on. This makes later supplier changes easier to check. It also helps when a data subject asks for access, when a customer asks for proof, or when a supervisory authority asks how the transfer basis was chosen.

Limits: what a transfer basis does not solve

A transfer basis does not create a lawful purpose for processing. The organisation still needs a legal basis for processing personal data and must meet the GDPR principles. If the basic processing is not lawful, an adequacy decision or standard contractual clauses do not fix it. The separate legal basis question is explained in What legal basis permits processing personal data?.

A transfer basis also does not remove data subject rights. Access, rectification, erasure, restriction, portability, objection and rules on automated decisions can still matter. Nor does it remove breach duties. If a personal data breach happens, the GDPR's Article 33 requires notification to the competent supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of it, unless the breach is unlikely to result in a risk to rights and freedoms. Breach timing is discussed in Personal data breach: the 72 hours start when an employee notices.

A transfer basis is also separate from impact assessment duties. Under the GDPR's Article 35, a data protection impact assessment is required before processing that is likely to result in a high risk to the rights and freedoms of natural persons. If artificial intelligence is involved, the AI Act's Article 27 may require a fundamental rights impact assessment for specified deployers of high-risk artificial intelligence systems. Where duties have already been met through a data protection impact assessment, the AI Act says the fundamental rights impact assessment supplements that assessment.

Finally, the transfer rules do not decide whether a data protection officer must be appointed or what the data protection officer must know. The GDPR's Articles 37–39 set appointment, position and task rules for the data protection officer. International transfers are still a subject that a data protection officer may need to understand, because they affect transparency, supplier control, records, risk assessment and the ability to demonstrate compliance.