Israel's Protection of Privacy Law has two layers that security teams need to understand together: Amendment 13, in force since 14 August 2025, which modernised definitions and gave the Privacy Protection Authority real enforcement powers, and the Protection of Privacy (Data Security) Regulations 2017, which already set some of the most prescriptive technical security rules of any privacy regime. This guide explains how the two fit, which security level a database falls into, the concrete controls each level requires, and what that means for the service accounts, keys and AI agents that reach personal data. It is written for security, privacy and engineering leads with operations or customers in Israel.
Source note: the Data Security Regulations are summarised from the official English translation published by the Israeli government on gov.il. The Hebrew text of Amendment 13 and the Privacy Protection Authority's Hebrew guidance could not be reviewed for this guide, so the Amendment 13 sections are based on named secondary sources: Pearl Cohen, Baker McKenzie's Global Data and Cyber Handbook and an Ius Laboris briefing published on Mondaq. Each obligation below names its source. Figures are included only where two independent sources agree. Confirm against the official text before relying on it.
Key takeaways
- Amendment 13 is in force: Pearl Cohen, Baker McKenzie and Ius Laboris all give 14 August 2025 as the commencement date.
- The security rules are older and more detailed: the Data Security Regulations, published on 8 May 2017 and effective a year later, set controls by database security level (basic, medium, high, or individually managed).
- Several controls carry fixed numbers: logs kept for at least 24 months, independent audits at least every 24 months for medium and high databases, and risk assessments and penetration tests at least every 18 months for high level databases.
- Severe incidents go to the regulator immediately: Regulation 11 requires immediate notice of a severe security incident to the Registrar of Databases, who may order notice to data subjects.
- Machine access counts: the access, authentication and logging rules apply to every authorised access path, which in practice includes service accounts, API keys and AI agents.
Scope: two instruments, one regulator
The Protection of Privacy Law 5741-1981 is the primary statute. Amendment 13 changed it substantially; Pearl Cohen calls it "the most significant Amendment to the law in decades". The Data Security Regulations 5777-2017 sit under the same law and apply to databases containing personal data. The regulator is the Privacy Protection Authority (PPA) within the Ministry of Justice, (Baker McKenzie). The Data Security Regulations address notices to the Registrar of Databases. The Israel National Cyber Directorate is a separate body focused on national cyber defence and best practice.
Israel holds an EU adequacy decision, which our Global Privacy Regulatory Map lists alongside other adequate countries. That status is a reason the PPA's enforcement posture matters to EU businesses as well as Israeli ones.
What Amendment 13 changed
| Change | What the sources say | Source |
|---|---|---|
| Definitions | "Personal information" and "data processing" were broadened and aligned more closely with GDPR-style concepts | Pearl Cohen |
| Database registration | Registration narrowed to specific cases; a new duty to notify the PPA when highly sensitive data is processed on a significant scale | Pearl Cohen; Ius Laboris |
| Data Protection Officer | Required in certain cases, including where core activity involves large-scale processing or systematic monitoring; PPA draft guidance covers databases used for "extended and systematic monitoring" | Ius Laboris; Pearl Cohen |
| Administrative enforcement | The PPA gained significant administrative fining powers and said it intends to use them fully | Pearl Cohen; Baker McKenzie |
| Court orders | The PPA can seek a court order to stop unlawful processing | Baker McKenzie; Ius Laboris |
| Statutory damages | Up to NIS 10,000 for certain violations without proof of harm | Baker McKenzie; Ius Laboris |
| Advance rulings | Organisations can ask the PPA for a binding opinion on a fact pattern; Pearl Cohen reports a 60-day response period in most cases | Pearl Cohen |
The sources agree that administrative fines rose sharply, but they describe the calculation differently, so this guide does not quote a fine figure. Read the PPA's current publications or take local advice before estimating exposure.
Working out the security level
Every obligation in the Data Security Regulations depends on the database's security level. The official translation sets four.
| Level | Typical trigger (summarised from Regulation 1 and the Schedules) |
|---|---|
| Individually managed | Managed by one individual (or their company) with no more than two other authorised users, excluding databases held for transfer to others, those with 10,000 or more people, and those under professional confidentiality |
| Basic | Any database that is not individually managed, medium or high |
| Medium | First Schedule categories, such as public body databases, databases collected for transfer to third parties, and databases holding sensitive data such as medical, biometric, criminal or financial information. Some, such as limited employee or supplier databases or those with no more than ten authorised users, drop to basic |
| High | Medium-type databases holding data on 100,000 or more people, or public body databases with more than 100 authorised users |
The authorised user counts matter. Our recommendation is to count every identity that can read the database, including service accounts, integration users and AI agents, not just people. A database that looks basic on a staff headcount can cross a threshold once machine access is included, and the regulator will look at the reality of access, not an HR list.
Controls the regulations require
These are the core duties from the official translation. Medium and high levels add most of the technical controls.
| Regulation | Requirement | Levels |
|---|---|---|
| 2 | Database definitions document: purposes, data types, transfers abroad, processors, main risks; reviewed annually | All except individually managed (limited) |
| 3 and 4 | Data security officer where required; written security procedure, reviewed annually and on material change | Basic and above |
| 5 | Up-to-date systems map and inventory; risk assessment and penetration tests at least every 18 months | Inventory all; testing high |
| 7 | Screening and training before access; refresher training at least every two years | Refresher medium and high |
| 8 | Role-based access, granted only as needed, with a current list of roles and authorised users | Basic and above |
| 9 | Identity verification; for medium and high, preference for physical credentials, password rules with change at least every six months, automatic logout, immediate revocation when a role ends | Medium and high for the detail |
| 10 | Automatic logging of access attempts, detection of log tampering, routine review, retention for at least 24 months | Medium and high |
| 11 | Document every incident; review incidents annually (medium) or quarterly (high); notify the Registrar immediately of a severe incident | All, with level-specific detail |
| 14 | Safeguards before internet connection, encryption over public networks, verified remote access, physical credential for medium and high remote access | All, with level-specific detail |
| 15 | Pre-contract risk assessment, written agreement and annual reporting from service providers | Basic and above |
| 16 | Independent audit at least every 24 months by someone other than the security officer | Medium and high |
Regulation 20 lets the Registrar accept compliance with recognised security standards. Mapping your controls to ISO/IEC 27001 or NIST CSF 2.0 does not replace the regulations, but it makes the audit evidence easier to assemble.
What it means for non-human identities and AI agents
The regulations were written around human users, but their wording covers anything that authenticates to a database. In our view the practical gaps are almost always on the machine side:
- Regulation 8 user lists: include service accounts, API clients and agents in the list of authorised users, each with a named owner and a stated role. An NHI inventory reconciliation is the quickest way to produce it.
- Regulation 9 authentication: a six-month change rule is easy to evidence for people and easy to miss for static keys. Replace long-lived secrets with short-lived federated credentials where you can, and rotate the rest on a schedule you can prove; see Credential Rotation at Scale.
- Revocation on role end: the immediate revocation duty applies when an integration or project ends, not only when an employee leaves. Tie machine credential lifecycle to the system owner; see NHI lifecycle automation.
- Regulation 10 logging: logs must show which identity accessed what. Shared service accounts used by several applications make that impossible, so split them.
- Regulation 15 outsourcing: a SaaS or AI provider holding an API key or OAuth grant to your database is a service provider under the regulation; record the credential in the written agreement and the annual report.
- AI agents: an agent that queries personal data needs its own identity, a role in the Regulation 8 list, and logs that tie its actions to a human principal. Our Human vs Non-Human Identity guide explains the distinction.
Severe incidents and notification
Regulation 11 requires organisations to document every security incident. For a severe security incident, as defined in the regulations, the controller must notify the Registrar immediately and report the measures taken. The Registrar may then order the controller to notify affected data subjects. There is no fixed hour count in the regulation text summarised here; "immediately" should be read as faster than the 72 hours many teams plan for under GDPR.
Build Israel into the same breach decision process you use for other countries. Our Breach Notification Laws by Country Guide covers the wider picture and the Customer Breach Notification Letter Template helps when the Registrar orders individual notice. A leaked database credential with confirmed access to a high level database is, in our view, a likely severe incident: treat it as reportable until legal counsel says otherwise.
Enforcement and penalties
Baker McKenzie lists the PPA's tools as administrative fines, cease orders, warnings, suspension or cancellation of database registration, publication of findings, and referral for criminal penalties. It reports that Amendment 13 added offences, including obstructing a PPA investigation and processing without authority, and that the PPA's enforcement priorities include cross-sector inspections and investigations prompted by media reports. Breaches of the database provisions are also a tort, and class actions are available. Statutory damages of up to NIS 10,000 for certain violations are confirmed by both Baker McKenzie and Ius Laboris.
Compliance steps
- List every database holding personal data and assign a security level, counting machine identities as authorised users.
- Write or refresh the Regulation 2 database definitions document and the Regulation 4 security procedure.
- Decide whether Amendment 13 requires a DPO and whether any database triggers the notice duty for highly sensitive data; record the reasoning.
- Bring access lists, authentication and revocation into line with Regulations 8 and 9 for people and machines.
- Turn on access logging with tamper detection and 24-month retention for medium and high databases.
- Schedule the 18-month risk assessment and penetration test for high level databases and the 24-month independent audit for medium and high.
- Add Regulation 11 severe incident criteria and the Registrar notice step to the incident response plan.
- Review service provider agreements against Regulation 15 and collect annual reports.
Common failure patterns
- Counting only staff as authorised users, so the database is assigned too low a security level.
- Service accounts shared across applications, which breaks Regulation 10 attribution.
- Integration credentials left active after the project ends.
- Logs retained for 90 days by default in a cloud or SaaS service when 24 months is required.
- Incident response plans that only reference GDPR timelines and miss the immediate Registrar notice.
Practitioner checklist
- Every personal data database has a recorded security level and owner.
- Authorised user lists include service accounts, API clients and AI agents.
- Machine credentials are short-lived or rotated on a provable schedule and revoked when a role ends.
- Access logs are attributable, tamper-evident and kept for at least 24 months.
- High level databases have a risk assessment and penetration test within the last 18 months.
- Medium and high databases have an independent audit within the last 24 months.
- The incident plan defines a severe incident and the immediate Registrar notice.
- DPO and highly sensitive data notice decisions under Amendment 13 are documented.
Standards and references
- Government of Israel: Protection of Privacy Regulations (Data Security) 5777-2017, English translation
- Pearl Cohen: Major amendment to Israeli privacy law set to take effect
- Baker McKenzie: Global Data and Cyber Handbook, Israel regulators, enforcement priorities and penalties
- Ius Laboris (Mondaq): Major amendment to privacy law in Israel
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Global Privacy Regulatory Map · GDPR Compliance Guide for Security Teams · DPIA Guide · Privileged Access Management Guide. This guide summarises Israel's Protection of Privacy Law and Data Security Regulations as at November 2026 and is not legal advice.