Introduction
For technology companies in Israel, privacy protection stopped being a peripheral issue some time ago. Amendment 13 to the Privacy Protection Law, which came into force in August 2025, changed the rules of the game: it modernised the statutory terminology, sharply narrowed the old database registration duty, and in its place built an enforcement regime with real teeth at the Privacy Protection Authority.
The Privacy Protection Law, 5741-1981, remains the central legal framework in Israel for regulating the use of personal data, and the Privacy Protection Regulations (Data Security), 5777-2017, continue to set out the detailed requirements for securing databases. What changed is the centre of gravity: the question is no longer mainly whether a form was filed with a registrar, but whether the company can show that it knows what data it holds, why it holds it, who can reach it, and what happens when something goes wrong.
This article sets out what now applies to technology and SaaS companies operating in Israel — the updated terms, the duties that genuinely bind them, the exposure created by the new enforcement powers, and a practical order of operations for getting into shape.
The Legislative Framework and the Updated Terminology
The Privacy Protection Law was enacted in 1981, long before the internet as we know it today. Amendment 13 finally brought its definitions closer to the reality technology companies actually work in, and it is worth starting with the vocabulary, because the terms determine who bears which duty.
The law now works with a broad concept of personal data — data relating to an identified person, or to a person who can be identified from that data, whether directly or indirectly. That formulation captures most of what a technology company holds about its users, including identifiers that look technical rather than personal but that in practice point to a specific individual.
Alongside it, the former category of sensitive information was replaced by data of particular sensitivity, with a broader list than before. It covers, among other things, medical and genetic data, biometric identifiers, data on a person's opinions and beliefs, and data on intimate affairs. Holding such data does not necessarily mean heavier duties across the board, but it does raise the required security level and, where the volume is large enough, can trigger duties that would not otherwise apply.
Who Is a Controller and Who Is a Holder
Amendment 13 replaced the old figure of the database owner with the controller of the database — the party that determines the purposes for which the data is processed and the means of processing. Beside it stands the holder, the party that holds or processes the data for someone else, typically a service provider or a subcontractor.
For a SaaS company this distinction is rarely academic, because most such companies wear both hats at once. In relation to their own employees, leads and account administrators they are the controller; in relation to the end-user data their business customers load into the platform they are usually the holder. The duties, the contractual terms and the response expected in a security incident differ between the two roles, so it is worth deciding in writing which hat applies to each data set rather than leaving it to be argued about later.
Core Principles
The law is based on several guiding principles that every technology company must be familiar with:
The consent principle establishes that the collection and use of personal data are contingent upon the consent of the data subject. The Privacy Protection Authority published final guidance on consent in early 2026, and its direction is clear: the law still recognises implied consent, but the Authority prefers active, opt-in mechanisms, particularly for uses that are not needed to deliver the service itself, such as profiling or marketing, and stresses that an active, recorded mechanism makes it far easier to prove that consent was informed. In practice this pushes companies to rework onboarding flows, marketing sign-ups and cookie banners so that the user's choice is real and, just as importantly, recorded.
The purpose limitation principle mandates that data be collected for a defined and legitimate purpose, and that it not be used beyond that purpose without additional consent. A technology company that collects email addresses for sending product updates, for example, may not transfer them to a third party for marketing purposes without explicit consent.
The proportionality principle directs that only data necessary for the purpose for which it was collected should be gathered — no more. This principle is particularly relevant to technology companies that tend to collect large volumes of data "for a rainy day," an approach that may expose them to legal risks.
The Duty to Notify When Collecting Data
Amendment 13 expanded the duty owed to a person when data is requested from them. The notice must explain the purposes for which the data is being collected, whether there is a legal duty to provide it or whether it is voluntary, to whom the data will be transferred and for what purposes, and the person's rights to access their data and to have it corrected.
This is one of the changes that hits product teams rather than lawyers. The information has to reach the user at the point of collection, in language they can follow — which usually means a short, plainly written layer in the interface itself, with the full privacy policy behind it, rather than a single dense document nobody reads.
What Remains of the Database Registration Duty
For years, the duty to register databases was the first thing Israeli companies heard about privacy law, and the broad registration regime caught a very large number of ordinary commercial databases. Amendment 13 narrowed it dramatically. The duty was not abolished, but it was redirected: it now applies in substance to public bodies, and to data brokers — those whose main business purpose is collecting personal data in order to pass it on to others — provided they exceed a size threshold set in the law.
The practical consequence for most private companies, technology and SaaS businesses included, is that a consumer application, an internal CRM or a customer data platform no longer has to be registered merely because of its size or because it holds sensitive data. Alongside this, the law introduced a lighter notification duty to the Privacy Protection Authority, which applies to controllers of very large databases containing data of particular sensitivity. It is a far smaller undertaking than registration, but it is a duty in its own right and should be assessed rather than assumed away.
The relief here is narrower than it first appears. Registration was a formal gate; what replaced it is substantive supervision of how data is actually handled. A company that reads the amendment as permission to stop thinking about privacy has misread it.
Where registration or notification does apply, the controller must keep the entry current and reflect material changes — new processing purposes, new categories of data, or new transfers to third parties. And where neither applies, the internal documentation that registration used to force companies to produce is still worth maintaining: it is the fastest way to answer a regulator, a business customer's security questionnaire or a due diligence request.
The Data Security Regulations in Practice
The Privacy Protection Regulations (Data Security), 5777-2017, were not displaced by Amendment 13 — on the contrary, now that registration has receded they are the operative core of Israeli privacy compliance. The regulations classify databases into security levels — basic, medium and high — alongside a lighter track for a database managed by an individual. The classification turns on the sensitivity of the data held, the scale of the database and the breadth of access to it, and it determines how demanding the resulting duties are.
For technology companies, these are the key requirements to implement:
- Database definition document: The controller of the database must prepare a document setting out the database's purposes, the types of data it contains, its data sources, transfers to third parties, and the security mechanisms protecting it. It is the anchor for everything else, and it must reflect the system as it is rather than as it was designed.
- Data security procedure: The regulations require a written security procedure covering physical and environmental security, access management, communications and the handling of portable devices, kept current as the systems change.
- Risk surveys and penetration testing: At the higher security levels the regulations require periodic risk surveys and penetration tests, with the findings documented and the gaps actually closed — a report filed away without remediation is worse than none.
- Access management and logging: Access permissions must be defined precisely, so that each employee reaches only the data their role requires, and access to the data must be logged in a way that allows after-the-fact review.
- Incident documentation and reporting: Every data security incident must be documented, and a severe security incident must be reported to the Privacy Protection Authority. The time to decide who makes that call, and how fast, is before an incident, not during one.
- Outsourcing and vendor engagements: Where processing is handed to an external provider, the regulations require a written engagement setting out which data is handled, for what purposes, for how long, what security measures apply and what happens to the data when the engagement ends. For a company built on third-party infrastructure this is where much of the real exposure sits.
- Employee training: The regulations require regular training of employees on data security and privacy matters, in accordance with the required security level.
Transferring Data Outside Israel
Israeli technology companies, particularly startups operating in international markets, are frequently required to transfer personal data outside Israel's borders — whether to cloud servers, parent companies abroad, or business partners.
Transfers abroad are still governed by the dedicated transfer regulations made in 2001, which permit a transfer where the destination country's law affords a level of protection no lower than Israeli law, or where one of the alternative grounds they set out is satisfied. In most cases the regulations also require a written undertaking from the recipient abroad to observe the conditions applicable to the data's use in Israel — which means the safeguard has to live in the contract, not only in the architecture diagram.
In the other direction, Israel is recognised by the European Union as providing an adequate level of protection, and the European Commission reaffirmed that status in January 2024 — a significant commercial asset for Israeli companies serving European customers. Part of the price of keeping it is a set of Israeli regulations adopted in 2023 that impose additional duties on data received from the European Economic Area, with their scope gradually extending to further data over time.
Those duties sit on top of ordinary Israeli requirements. In broad terms they call for keeping data accurate and up to date, deleting data that is no longer needed for the purpose it was collected for, refraining from holding data beyond the period justified by that purpose, and notifying data subjects in defined circumstances. For a company whose systems were built on the assumption that data is retained indefinitely by default, the retention and deletion duties are usually the hardest part, and they are an engineering project as much as a legal one.
Transfers to other countries, the United States included, still require examination on their own terms. This matters most in the supplier chain, which is where transfers tend to happen without anyone deciding that they should: cloud and hosting providers, analytics and product-telemetry tools, support and ticketing platforms, mailing services, and increasingly external model and AI providers. Each of these can move personal data across a border, and the company remains answerable for it.
The mechanisms commonly relied on to support such transfers include:
- Obtaining informed consent from the data subject
- Entering into a data processing agreement (DPA) incorporating standard contractual clauses
- Demonstrating that the transfer is necessary for the performance of a contract for the benefit of the data subject
The Interface with the GDPR
Many Israeli technology companies operate in the European market and process personal data of European Union citizens. In this context, they are subject not only to Israeli law but also to the European Union's General Data Protection Regulation (GDPR).
Amendment 13 narrowed the distance between the two regimes considerably. Israeli law now works with a controller and holder distinction that maps reasonably well onto the European controller and processor, with a broad concept of personal data, with an expanded transparency duty at the point of collection, with a duty to appoint a privacy protection officer in defined cases, and with administrative monetary sanctions imposed by the regulator. Anyone who built a GDPR programme will recognise most of the furniture.
The regimes are still not identical. The GDPR remains broader on data subject rights — erasure, portability and objection to processing — and on the accountability apparatus around them, including impact assessments and the documentation the regulator expects to be produced on demand. The practical point is that alignment is now a matter of mapping and gap-closing rather than of running two unrelated compliance projects.
For most Israeli technology companies the sensible route is a single compliance programme built to the stricter standard, with local adjustments where Israeli law asks for something of its own — the security regulations, the transfer rules, the reporting channel to the Privacy Protection Authority. Maintaining two parallel sets of policies, records and vendor terms costs more and tends to leave gaps in the seams between them.
Enforcement, Sanctions and the Privacy Protection Officer
This is the heart of the change. Amendment 13 gave the Privacy Protection Authority substantially wider supervisory and investigative powers, and, crucially, the ability to impose administrative monetary sanctions without going through a criminal court. The sanctions are scaled by the size of the database and the sensitivity of the data in it, and at the upper end they can reach very significant sums. Alongside them, the courts may in defined circumstances award statutory damages without proof of harm, which lowers the bar for civil claims and makes class actions a more realistic prospect than they were.
The effect is that privacy has become a quantifiable exposure rather than a reputational worry. Boards, investors and acquirers can now put a number on it, and privacy posture is increasingly examined in diligence with the same seriousness as intellectual property chain of title. A company that cannot show how it handles personal data will find that gap priced into a transaction.
Who Must Appoint a Privacy Protection Officer
Amendment 13 introduced a duty to appoint a privacy protection officer. It applies to public bodies; to data brokers operating above the threshold set in the law; to entities whose core activity involves systematic large-scale monitoring of people; and to entities whose core activity is the large-scale processing of data of particular sensitivity.
The last two categories are the ones technology companies tend to underestimate. A platform built around behavioural tracking, location, device telemetry or continuous user profiling can fall within systematic monitoring even though nobody inside the company would describe the product that way, and a health, fintech or identity product can easily meet the sensitivity test. Where the duty applies, the officer must be able to act with a measure of independence, report to senior management, and have the standing and resources to raise problems before they become incidents. Where a company concludes that the duty does not apply, that conclusion is itself worth documenting, with the reasoning behind it.
What Else Is Worth Watching
The Privacy Protection Authority has also published guidance addressed to boards of directors on their role in overseeing privacy and data security. The general direction is that oversight of personal data is a governance matter rather than a purely technical one, and that management should be able to show the board what data the company holds and how it is protected.
Beyond that, the areas drawing the most regulatory attention are the ones moving fastest: tracking and advertising technologies, biometric processing, and the use of artificial intelligence over personal data. These are worth following not because the rules are settled but because they are not.
A short diagnostic is usually enough to tell a company where it stands:
- Can you produce, today, a current list of the personal data the company holds and where it lives?
- Do you know, for each data set, whether the company is acting as controller or as holder?
- Has the security level of each database been classified, and are the resulting duties actually implemented rather than merely written down?
- Is there a named person who decides whether a security incident is reportable, and a process that would get that decision made quickly?
- Do the agreements with your processing vendors contain the terms the regulations require, and has anyone read them since they were signed?
Most of these questions do not call for a long project — they call for a focused review and a set of documented decisions.
A Practical Compliance Roadmap
There is a sensible order to this work. Each step makes the next one cheaper, and taken together they are what a regulator, a business customer or an acquirer will ask to see.
- Map the data and fix your legal role. Identify what personal data the company collects, from whom, for what purposes, where it is stored, who can reach it and how long it is kept — and for each data set decide whether the company is the controller or the holder. Everything downstream depends on this.
- Classify the security level and implement it. Determine the level that applies to each database under the data security regulations and close the gap between the level required and the controls actually in place.
- Check registration or notification, if either applies. Most private companies no longer need to register. Confirm that this is true of yours, check whether the notification duty for very large databases of particularly sensitive data is triggered, and record the answer.
- Assess the privacy protection officer duty. Work through the statutory categories honestly, appoint an officer where the duty applies, and document the reasoning where it does not.
- Fix transparency and consent. Bring notices at the point of collection into line with the expanded duty, rework consent flows towards an explicit, active choice, and make sure consent is recorded in a way you could later evidence.
- Prepare for incidents. Put a written incident procedure in place, decide in advance who assesses severity and who reports to the Authority, and rehearse it at least once rather than discovering the gaps under pressure.
- Handle vendors and transfers. Inventory the providers that touch personal data, bring the engagements into line with the outsourcing requirements, and establish a basis for each transfer abroad — including the ones that happen through everyday tools.
- Build the culture and the paper trail. Train employees, bring privacy into product design from the start, and keep documentation of decisions. Under an administrative enforcement regime, an undocumented good decision is worth very little.
Conclusion
Privacy protection in Israel has moved from declaration to enforcement. For technology companies, that does not mean satisfying one or two formal requirements; it means managing personal data continuously as both an asset and a risk — with documentation, clear internal ownership, and processes that can be demonstrated rather than merely described.
Companies that build this infrastructure in advance gain more than reduced exposure to sanctions and claims. They also gain something commercially tangible: shorter procurement and due diligence cycles, credibility with enterprise customers and investors, and smoother access to international markets. The central recommendation is a simple one — carry out the legal and technical review now, at a pace that suits the business, rather than under the pressure of a security incident or a regulator's letter.
The information contained in this article is general in nature and does not constitute legal advice. For advice tailored to the specific circumstances of your company, we invite you to contact our firm.
