GDPR Israel Adequacy: Outsourcing Without Compliance Risk

Israel has held a European Commission adequacy decision under GDPR since 2011, reconfirmed after a formal review in January 2024. In practice, GDPR Israel adequacy means personal data can move from the EU to an Israeli company without standard contractual clauses or any other extra transfer safeguard. It does not mean compliance stops there: you still need an Article 28 data processing agreement, verifiable security controls, and a clear view of how your vendor's obligations changed under Amendment 13 to Israel's Privacy Protection Law, in force since 14 August 2025.

This guide is for EU and UK companies, DPOs and legal teams evaluating or already working with an Israeli development partner. It covers what the adequacy decision does and does not cover, what changed in Israeli law itself, and a checklist and requirement table you can use directly in vendor due diligence. This is general information, not legal advice; confirm specifics with your own counsel before you rely on them.

What Does It Mean That Israel Has EU Adequacy Under GDPR?

An adequacy decision is the European Commission's formal finding, made under GDPR Article 45, that a non-EU country protects personal data to a standard essentially equivalent to the EU's own. Once a country has one, personal data can flow to it much like data flowing between two EU member states: no standard contractual clauses, no binding corporate rules, no case-by-case transfer assessment.

Israel earned that status in Commission Decision 2011/61/EU of 31 January 2011, adopted under the pre-GDPR Data Protection Directive. When GDPR replaced the Directive in 2018, it did not wipe the slate clean: Article 45(9) of the Regulation states that adequacy decisions made under the old Directive stay in force until the Commission amends, replaces or repeals them. Israel's 2011 decision is still that same decision, now operating under GDPR.

The Commission does not treat adequacy as a one-time judgment. On 15 January 2024 it published its first periodic review of the eleven adequacy decisions adopted under the old Directive, Israel among them, and confirmed that all eleven, including Israel, continue to provide adequate protection. The report also recommended that Israel move some protections that currently exist only in sub-legislative guidance and case law into primary legislation, a nudge that likely shaped parts of the Amendment 13 reform covered below.

The UK reached its own, separate conclusion. After Brexit, it carried forward the adequacy findings the EU had already made and now maintains those findings under its own UK GDPR framework. The ICO lists Israel among the countries and territories with full UK adequacy, so the same logic applies to transfers that start in the UK.

Israel's data protection regulator, the Privacy Protection Authority (PPA, formerly known as ILITA), is the counterpart your legal team would eventually deal with if a complaint or an audit reached that level.

Does the Decision Cover All of Israel?

One detail is worth confirming rather than assuming. The 2011 decision's scope is limited to Israel within its pre-1967 borders and does not extend to the West Bank. In practice, the large majority of Israeli software houses, including Tel Aviv-based teams, operate entirely within that scope, but it belongs on a due-diligence checklist: ask where your vendor's engineers and infrastructure are actually located, not only where the company is registered.

What Does Adequacy Remove, and What Still Sits on You?

Adequacy answers exactly one question: which legal mechanism lets data cross the border. It does not touch the rest of your GDPR obligations, which apply to an Israeli processor exactly as they would to a processor in Warsaw or Lisbon.

Four things stay squarely on your side of the table:

• An Article 28 contract. GDPR Article 28 requires a written data processing agreement with any processor, wherever it is based. It must cover documented instructions, confidentiality commitments, Article 32 security measures, rules for engaging sub-processors, cooperation on data subject requests and breach notification, and deletion or return of data at the end of the engagement. Adequacy has no bearing on whether you need this contract; you need it regardless.
• Security measures under Article 32. Adequacy says Israel's legal system is trustworthy. It says nothing about whether a specific vendor patches its servers, encrypts backups or reviews access logs. That remains your due diligence to perform.
• A lawful basis and data minimization. You still need a lawful basis under Article 6, and Article 9 if special category data is involved, for the processing itself, plus the general GDPR expectation to send only the data actually needed. In outsourced development, that usually means synthetic or pseudonymized data in development and staging environments rather than a live customer database.
• Sub-processor visibility. If your Israeli vendor uses a US-based analytics tool, an error-tracking service or a nearshore subcontractor, that hop may fall outside adequate territory and need its own safeguard, typically standard contractual clauses. Adequacy covers the direct relationship you set up; it does not automatically cover every tool downstream of it.

Put simply: adequacy removes a transfer-mechanism burden under Article 46. It does not replace the rest of your vendor compliance program.

What Changed in Israel's Own Privacy Law? Amendment 13, Explained

Israel's core privacy statute, the Privacy Protection Law, 5741-1981, went largely unchanged for decades while the EU moved from the Data Protection Directive to GDPR. Amendment 13 closes much of that gap. The Knesset approved it in August 2024, and most of its provisions took effect on 14 August 2025, making it the most significant change to Israeli privacy law since the original statute.

Four changes matter most to a company sending data to an Israeli vendor:

Registration got narrower, not broader. The previous rule required most databases above a low threshold to register with the regulator, widely seen as unenforceable given how many databases existed. Amendment 13 narrows mandatory registration to databases holding data on more than 10,000 people where the primary purpose is supplying that data to others for business or payment, such as data brokers and direct-mail services, plus databases controlled by a public body. A separate new rule requires notifying the PPA, even without registering, if a database holds especially sensitive data on more than 100,000 people.

A Data Protection Officer duty exists in Israeli law for the first time. Public bodies, data brokers, organizations whose main activity is processing especially sensitive data at scale, and organizations that systematically monitor people must now appoint a DPO with direct access to senior management. The PPA granted a grace period on enforcing this specific duty until 31 October 2025, which signals how new the requirement is, not that it can be ignored afterward.

The Privacy Protection Authority can now enforce with teeth. Before Amendment 13, enforcement leaned heavily on criminal referral, a blunt and rarely used tool. The PPA can now issue administrative orders, monetary sanctions and cease-and-desist directives, and can order a business to stop processing altogether. Fines can reach into the millions of shekels, scaling with the size of the database and the sensitivity of the data involved.

Sensitive data got a broader definition, alongside new transparency duties and specific rules for data brokers. If your Israeli vendor processes anything your organization classifies as sensitive, especially health, biometric or financial data, ask directly how Amendment 13 changed their handling of it.

None of this changes the EU adequacy analysis on its own. If anything, a stricter, better-enforced Israeli privacy law supports the case that the country's data protection framework has kept pace since 2011, and it is likely to feature in the Commission's next periodic review.

What Do Israel's Data Security Regulations Require of Your Vendor?

Separately from the Privacy Protection Law, Israel's Privacy Protection (Data Security) Regulations, 5777-2017, in force since May 2018, set out concrete technical requirements for anyone holding a database in Israel, including a software vendor holding your data for development or support. They sort every database into one of three security levels.

| Security level | Typically set by | Extra duties on top of the basics | | --- | --- | --- | | Basic | Any database not classified higher | Written security policy, access management, basic network controls | | Medium | Larger record counts, more authorized users, or public-body data | Basic duties plus stricter access reviews and monitoring | | High | Especially sensitive data such as health, biometric or financial records, or authorization to profile people at scale | Medium duties plus a documented risk assessment and a penetration test at least once every 18 months |

Level is set by data sensitivity, record volume and how many people have access, not by company size. A small Israeli team holding health data for a client's app can land in the high tier despite a modest headcount. If your project touches anything in that category, ask directly which level applies and for evidence of the most recent risk assessment and penetration test, since both are legal requirements rather than optional hardening.

What Should You Ask an Israeli Development Partner Before You Sign?

Run this checklist with any vendor before data starts moving, not after the contract is signed:

1. Confirm the contracting entity and where engineers and infrastructure actually sit, since the adequacy decision's geographic scope stops at Israel's pre-1967 borders.
2. Request a signed Article 28 data processing agreement before any data moves.
3. Ask which Data Security Regulations level applies to your data, and for evidence of the required risk assessment and, for high-level data, the latest penetration test.
4. Get a current sub-processor list, including analytics, monitoring, email and cloud tools, and confirm each one has its own lawful transfer basis.
5. Confirm development and staging environments use synthetic or pseudonymized data rather than a live copy of production.
6. Set a vendor-to-you breach notification window tight enough that you can still meet your own 72-hour duty to your supervisory authority under GDPR Article 33.
7. Ask whether Amendment 13's Data Protection Officer duty applies to the vendor, and if not, who owns privacy internally.
8. Confirm audit rights and how often you can exercise them.
9. Set data retention and deletion terms for the end of the engagement, including backups.
10. Put currency, incident-response contacts and an escalation path in the contract, not just in a sales call.

The table below maps the same ground by requirement, useful as a quick reference during vendor calls.

| Requirement | What it actually covers | What to ask your Israeli vendor | | --- | --- | --- | | EU adequacy (GDPR Article 45) | The legal basis for the cross-border transfer itself | Confirm their entity and data sit within Israel's pre-1967 borders | | Article 28 DPA | Contractual duties of any processor, anywhere | Request the signed DPA before data moves, not after kickoff | | Data Security Regulations level | Israeli-law technical controls tied to data sensitivity | Which level applies, and evidence of the required risk assessment | | Sub-processors | Every tool or subcontractor that touches your data | A current list, and the transfer mechanism each one relies on | | Breach notification | Your own 72-hour duty under GDPR Article 33 | A vendor notification window well inside that 72 hours | | Amendment 13 DPO duty | Whether the vendor must appoint a privacy officer | Ask directly, and who owns privacy if the duty does not apply | | Data minimization | Reducing what a vendor ever needs to see | Synthetic or pseudonymized data in development and staging |

What Does GDPR-Ready Vendor Onboarding Look Like in Practice?

Illustrative scenario: a Berlin-based B2B SaaS company with 35,000 EU users is hiring an Israeli software house for a six-month platform rebuild that will need access to production data for debugging. Assumptions: the platform stores payment metadata, and the client's DPO runs vendor onboarding before any repository or environment access is granted.

Four steps happen before code access is granted. First, legal confirms the vendor's contracting entity and where the assigned engineers are based, then signs an Article 28 DPA covering the rebuild. Second, the vendor discloses its sub-processor list: an EU-region cloud provider, which needs no extra safeguard, and a US-based error-tracking tool, which is flagged for its own transfer mechanism. Third, because the platform holds payment metadata, the security lead classifies the project at the high Data Security Regulations level and requests the vendor's latest risk assessment and penetration test report. Fourth, instead of granting access to the live database, the two teams agree on a synthetic dataset that mirrors production's shape for day-to-day development, with narrowly scoped, logged access to real data reserved for specific debugging sessions.

The DPA sets a 24-hour vendor-to-controller breach notification window, leaving the Berlin team a working margin inside its own 72-hour regulatory deadline. None of this required standard contractual clauses or a transfer impact assessment, because adequacy already cleared that hurdle. What it required was ordinary GDPR vendor management, applied with the same discipline the company would use for any processor.

What Mistakes Do EU Companies Make When Outsourcing to Israel?

A handful of avoidable errors show up repeatedly in vendor reviews:

• Treating adequacy as the whole answer. Adequacy clears the transfer mechanism, not the rest of GDPR. Skipping the DPA because "Israel is adequate anyway" is a common and easily corrected mistake.
• Never asking about sub-processors. A vendor can be fully compliant while a tool it uses is not, if that tool sits outside the EU or an adequate country without its own safeguard.
• Handing over production data for a routine build. Most development work never needs real customer data. Ask for synthetic data by default and treat production access as a logged exception.
• Assuming Amendment 13 does not affect a foreign client. Amendment 13 is Israeli domestic law, but it reshapes how a vendor handles data, including yours, so it is worth a direct conversation even though your own GDPR obligations do not change because of it.
• Skipping the geography question. Confirming that a vendor's team and infrastructure fall within the adequacy decision's actual scope takes one question and closes an unnecessary gap.

For the parallel questions that come up when an Israeli vendor also serves clients regulated under NIS2 or DORA, see our guide to NIS2 and DORA compliance for tech vendors. If you are earlier in the process of evaluating Israel as an outsourcing destination at all, our guide to outsourcing software development to Israel and Israeli software house buyer's guide cover the broader decision.

How Agentixly Approaches Data Protection for International Clients

At Agentixly, data protection sits inside the engagement from discovery onward rather than as a document signed once and filed away. A typical engagement with an EU or UK client runs through five concrete steps.

1. Data-flow mapping. Before any access is granted, we document what data the project touches, where it will live, and which of our systems and any third-party tools it passes through.
2. Contract first. We sign an Article 28 data processing agreement covering instructions, confidentiality, security measures, sub-processor rules and breach notification before data moves, not after the project starts.
3. Environment separation. Development and staging environments default to synthetic or masked data; access to real production data is scoped, logged and time-boxed.
4. Security controls mapped to the actual requirement. Our cybersecurity team classifies each engagement against the relevant Data Security Regulations level and GDPR Article 32, and documents the controls in place rather than asserting them.
5. Named ownership. Every client gets a named point of contact for privacy and security questions, and a defined breach notification window written into the contract rather than left to a support inbox.

This is the same discipline our team brings from backgrounds in Israel's elite technology units: assume scrutiny is coming, and keep the evidence ready before it arrives. Companies preparing for a broader security review alongside GDPR due diligence often run this in parallel with our ISO 27001 vs SOC 2 comparison or before scoping a penetration test.

The Bottom Line

GDPR Israel adequacy is real, has held since 2011, and was reconfirmed in 2024, so the cross-border transfer mechanism is not the hard part of working with an Israeli development partner. The hard part, as with any processor, is the ordinary GDPR work: a signed Article 28 DPA, verified security controls, visibility into sub-processors, and data minimization in day-to-day development. Amendment 13 raises the bar on the Israeli side too, with real enforcement power behind it for the first time.

Use the checklist and requirement table above with any Israeli vendor you are evaluating, and treat a vendor who cannot answer them cleanly as a signal, not a technicality. If you want a partner whose cybersecurity practice already builds this into delivery, talk to Agentixly about your next engagement.