Your app sends personal data outside the EU. Each destination needs its own transfer mechanism.

Your production database is in Frankfurt. You chose that region deliberately, it is on the security page, and when a customer asks where their data lives, Frankfurt is the honest answer.

Then look at what else the product did last week. Your error monitoring shipped a stack trace to a vendor in Virginia, carrying the email address of whoever was signed in when the request failed. Two support engineers at that vendor, in Denver, hold standing read access to your customers' tickets. A new feature posts the user's message to a model API in Oregon. Your analytics tag fires from the visitor's browser straight to a US endpoint.

All four are transfers of personal data out of the EU, and Chapter V of the GDPR wants a named mechanism for each one. The database stayed in Frankfurt the whole time.

If your product touches EU users, every vendor you send their data to needs one of those mechanisms written against it, or the transfers sentence in your privacy policy is a claim you cannot back. Something will ask you to back it: a customer's security team working through procurement, or a regulator, and European regulators are running a coordinated check on this exact duty during 2026. Plenty of products could not back it today. When we scanned 458 Product Hunt launches from inside the EU, 233 both published a privacy policy and loaded a third-party service in the visitor's browser, and 59.7% of those said nothing about international transfers at all.

What counts as a transfer of personal data?

Making personal data available to a separate organisation outside the EEA. Anywhere beyond it is a "third country", which is the phrase the articles themselves use.

The GDPR never defines the word transfer, so the European Data Protection Board, the body that issues the GDPR's official guidance, filled the gap with three criteria that all have to hold at once: the exporter is subject to the GDPR for that processing, the exporter discloses or otherwise makes the data available to another controller or processor, and that importer sits in a third country. Whether the importer is itself caught by the GDPR makes no difference to whether a transfer happened 2.

Four cases follow from that, and products get them wrong in both directions.

Nothing has to move. The EDPB's worked example is a processor in a third country remotely accessing data that stays stored in the EU for support purposes, and the remote access is itself the transfer 2. Its transfer recommendations say the same in one line: remote access from a third country to data located in the EEA is a transfer 6. The engineers in Denver count.

A foreign parent company does not by itself create one. Where an EU controller uses an EU processor owned by a US parent, and the data is processed exclusively in the EU with nobody outside it holding access, there is no transfer and Chapter V does not apply. Article 28(1) still applies: you may use only processors offering sufficient guarantees, and a processor exposed to foreign disclosure law is a reason to look harder before signing 2.

Your own staff are not a separate party. An employee reading the company database from a laptop in São Paulo is an integral part of the controller, so nothing has been exported. Another company in your group is separate, though, and disclosures between group entities can be transfers 2.

A tag in the visitor's browser is still your transfer. The EDPB treats data disclosed via cookies as a transmission by the operator of the website the person is visiting, not a disclosure by the person themselves 2.

This is the second column of a vendor list you may already have. Sorting vendors into processor, separate controller or joint controller tells you which contracts you owe; sorting the same list by destination tells you which mechanism you owe. A vendor can be settled on the first question and untouched on the second.

Which countries can you send data to without extra paperwork?

The ones the European Commission has found adequate, where a transfer needs no further authorisation under Article 45(1) 1. The Commission's register of adequacy decisions currently covers Switzerland, the United Kingdom, Japan, Canada, Brazil, Argentina, the Republic of Korea, Israel, New Zealand, Uruguay, Andorra and four small European territories, plus the European Patent Organisation and the United States on a framework basis.

Read the scope of each decision rather than the country name, because several of them are narrower than a map suggests.

Brazil is the newest entry, and the one most likely to be missing from a list assembled a year ago. Commission Implementing Decision (EU) 2026/179 of 26 January 2026 covers data transferred to controllers and processors there "subject to the General Data Protection Law (LGPD)" 4. A Brazilian vendor outside the LGPD's scope still needs a safeguard.

The United States entry is narrower still: it reaches only organisations that have certified to the EU-US Data Privacy Framework, so the question about a US vendor is whether that specific company is certified, not whether it is American. The framework survived its first court challenge on 3 September 2025, when the General Court, the first-instance court of the Court of Justice of the European Union, dismissed an action brought by the French MP Philippe Latombe to annul it 7.

That is not the last word, and the difference reaches your vendor list. He appealed on 31 October 2025, asking the Court of Justice to set the judgment aside and annul the adequacy decision, and that case is pending 8. The framework is valid today. If the appeal succeeds, every vendor where the framework is your only mechanism needs a different one, so it is worth knowing now which rows those are.

So an adequacy decision is a finding about a country at a particular moment, and it can be withdrawn. Article 45(3) requires each one to provide for review at least every four years, and Article 45(5) lets the Commission repeal, amend or suspend a decision when a country stops measuring up 1.

What do you use when there is no adequacy decision?

An appropriate safeguard under Article 46. The routes open to a company without special authorisation include binding corporate rules, standard contractual clauses adopted by the Commission, clauses adopted by a supervisory authority, approved codes of conduct and approved certification mechanisms 1. For a company of ten people, the realistic option is the Commission's standard contractual clauses (SCCs), usually accepted inside the vendor's own terms at signup.

Signing them does not finish the job. After Schrems II, the Court of Justice judgment that struck down the previous EU-US arrangement, the EDPB set out a six-step method. Step three is assessing whether the Article 46 tool you picked is effective in that particular destination, and adding supplementary measures such as encryption where it is not 6. Step one is the plainest instruction in the area: know your transfers, build the map from your Article 30 records, and include onward transfers to your vendors' own sub-processors 6.

One row type is worth flagging to counsel rather than solving yourself. The SCCs are written for an importer "whose processing of the data is not subject to" the GDPR 3, so a vendor that targets EU users with its own product may sit outside what they cover. Purpose-built clauses for that case have been listed as in development on the Commission's standard contractual clauses page for five years. Most companies sign the standard set anyway.

Can you rely on consent, or on "necessary for the contract"?

Not for a vendor the product uses every day. Article 49 lists exceptions for specific situations, including consent, necessity for a contract with the data subject, and legal claims 1. The EDPB reads them restrictively so the exception does not become the rule, a reading it draws from the article's own title 5.

The sentence that settles it for most SaaS integrations: a transfer is generally treated as non-occasional or repetitive "when the data importer is granted direct access to a database (e.g. via an interface to an IT-application) on a general basis" 5. That describes an API key.

Consent under Article 49(1)(a) is narrower than a signup checkbox too: it has to be explicit consent to the proposed transfer, given after the person has been told the risks of there being no adequacy decision and no safeguards 1.

What has to end up in your privacy policy?

Three specific things, and Article 13(1)(f) names them: that you intend to transfer personal data to a third country, whether an adequacy decision exists for it, and for transfers resting on Article 46 or 47 safeguards, a reference to the safeguard plus how to obtain a copy 1. Article 14(1)(f) repeats the duty word for word for data you did not collect from the person, and Article 30(1)(e) asks your internal record to identify the third country itself 1.

That published sentence is under unusual scrutiny in 2026. In March the EDPB launched its coordinated enforcement action on transparency, in which 25 data protection authorities contact controllers across sectors about compliance with Articles 12 to 14. They pool and discuss their findings in the second half of the year, ahead of a consolidated report. Both of the transfer duties above sit inside that scope.

What to do with your vendor list this week

Open the list and add one column: destination. For every vendor, write where the receiving company is and which of the three routes covers it. Adequacy, naming the decision and checking this vendor sits inside its scope. A safeguard, naming which one and who assessed it for that country. Or nothing at all. Include the vendors whose data stays in the EU but whose staff read it from elsewhere. Then compare the result against the transfers sentence your privacy policy already publishes, because that sentence is a claim about this list.

If I were doing this from scratch I would start with the rows that came back "nothing", since a missing mechanism is an obligation you have not met, while a thin policy sentence is a disclosure you can sharpen.

The awkward part is that the list stops being true almost immediately. A new region on a cloud console, a support vendor opening an office in another country, a model API swapped for a cheaper one: each changes a destination without anyone treating it as a legal event, and the transfers sentence in your policy goes stale silently.

Lawcel is a compliance platform that watches the pull requests and tickets where product change happens. My co-founder and I built it for that half of the problem. You record each third party once, including where it is based and what it receives. The pull requests are how it catches the change: when one adds a vendor or moves data somewhere new, Lawcel opens a case naming the documents that no longer match and proposing the edit for your team to review and publish. If you would rather not rebuild the destination column by hand every quarter, that is the part we can take off you.

Either way, do the column. It is one pass down a list you have already built, and it turns the vaguest sentence in your privacy policy into something you can stand behind when a regulator, or a customer's security team, asks you to.