Cross-border data transfers: PPL and GDPR, side by side

Two separate rulebooks can apply to the same transfer. If you’re an Israeli company sending personal data outside Israel, the Protection of Privacy Law’s transfer rules apply. If any of that data belongs to people in the EU/EEA, GDPR’s transfer rules apply too — regardless of where your company is incorporated. Most cross-border AI vendors trigger both at once, and the two regimes don’t ask exactly the same questions.

When each regime applies

The PPL’s transfer rules apply whenever an Israeli-controlled database sends personal data outside Israel — the trigger is where the database is controlled from, not the nationality of the individuals in it. GDPR’s transfer rules apply whenever the data belongs to people located in the EU/EEA, whether or not your company has any EU presence — the trigger is whose data it is, not where you’re based. A company with an all-Israeli customer base but a US-hosted AI vendor is squarely in PPL territory. A company with EU customers is in both regimes simultaneously, even if it has never opened an EU office.

What each one actually requires

The default rule under the PPL’s transfer regulations is that data may not leave Israel unless the destination country’s law ensures a level of protection no lower than Israel’s own. Short of that, transfer is permitted only under one of eight specific alternative bases set out in the regulations: the data subject’s consent; transfer necessary to protect their health or physical safety; transfer to an entity under the same controller’s control that has committed to protecting the data; transfer to a recipient who has contractually committed to the same data-handling conditions that would apply in Israel; data already lawfully published to the public; transfer necessary to protect public safety; transfer required by Israeli law; or transfer to a country that is party to the European Convention on data protection, receives the data under EU-equivalent conditions, or has been recognized by the Registrar as offering adequate protection. GDPR runs on a comparable structure but different mechanics: it defaults to prohibiting transfers to third countries unless an adequacy decision covers the destination, or the transfer is backed by an appropriate safeguard — most commonly Standard Contractual Clauses.

Where they diverge

Israel holds an EU adequacy finding — originally granted in 2011 under the 1995 Directive, and reported as reaffirmed in 2024 under GDPR, citing strengthened PPA independence, the 2022 Amendment 14, the 2017 Data Security Regulations, and EEA-transfer-specific regulations adopted in 2023. That’s what makes Israel–EU data flows comparatively straightforward in that one direction. It does not make an Israeli company’s outbound transfers to a third country (a US-hosted AI vendor, for instance) automatically compliant under the PPL — that’s a separate question, resolved against the eight bases above, not against Israel’s own adequacy status. The two regimes also differ on documentation expectations and on what counts as an acceptable transfer mechanism in edge cases, which is where a transfer that looks fine under one regime can still be exposed under the other.

The compounding case: AI vendors

This is exactly the scenario the Business Plan calls the “segment marker” — a company with a cross-border customer base, using AI vendors that may process data outside Israel and outside the EU. That combination creates compound exposure: a PPL question about the transfer out of Israel, and a separate GDPR question about the transfer of any EU customer’s data, both resting on the same underlying vendor account.

What to check

For each vendor that touches personal data outside Israel: where the data is actually processed (not just where the vendor is headquartered), what transfer mechanism covers that specific flow, and whether that mechanism is documented anywhere you could produce it on request. “The vendor says they’re GDPR-compliant” is not, on its own, an answer to any of those three questions.