Israel's Privacy Protection Law Amendment 13: what changed for your security programme

Amendment 13 to Israel's Protection of Privacy Law, 5741-1981, was approved by the Knesset on 5 August 2024 and took effect a year after publication, on 14 August 2025. The reform is broad, and a year in, the Privacy Protection Authority (PPA) has started to use its new powers: in July 2026 it imposed its first administrative fine specifically for failing to report a security incident in time. For a security programme, the technical duties still come mainly from the Data Security Regulations of 2017. What Amendment 13 changed is the cost of ignoring them, and the evidence you need to show that you did not. This guide is not legal advice; confirm classification decisions with your privacy counsel.

What Amendment 13 changed

Who must appoint a data protection officer

• Controllers of databases that must be registered.
• Controllers or processors whose main activities involve regular and systematic monitoring of individuals at significant scale.
• Controllers or processors whose main activities involve highly sensitive data at significant scale, such as banks, insurers, hospitals and health funds.

Draft PPA guidelines on the role, reported in January 2026, stress that the officer must be meaningfully involved from the earliest planning stages of new systems that use personal data. Under Amendment 13 the officer is also responsible for ensuring that a data security procedure and a database definitions document exist, which ties the role directly to the Data Security Regulations.

The Data Security Regulations still set the controls

The Protection of Privacy Regulations (Data Security), 5777-2017, have applied since 8 May 2018. They give every database a security level, and the level decides which duties apply. The PPA publishes an English translation, but only the Hebrew text is binding. The table summarises the levels and the duties most relevant to testing and incident handling; Regulation 21 lists exactly which regulations apply at each level.

Penetration tests, risk assessments and audits

Regulation 5 is the clearest testing duty in Israeli privacy law. For a database at high security level, the controller must carry out a data security risk assessment at least once every 18 months, and penetration tests of the database systems at least once every 18 months to test their vulnerability to external and internal threats. The controller must discuss the results and act to fix the faults found. An organisation with several databases at the same level may cover them in a single risk assessment or a single penetration test.

Regulation 16 adds an audit at medium and high levels: at least once every 24 months, internal or external, by an auditor trained in data security who is not the database's own data security officer. The audit report must say whether the security measures follow the procedure and the regulations, identify shortcomings and recommend fixes. At high level the audit can be carried out together with the risk assessment.

The regulations do not define how deep a penetration test must go, so the scope is yours to justify. In our view a test that will stand up to scrutiny covers the routes an attacker would take to the data:

• The database servers and managed database services themselves, including network exposure and authentication
• The applications and APIs that read and write the data, tested with an account for every role
• Administrative and remote access: VPNs, bastion hosts, cloud consoles and support tooling
• The cloud accounts and identities that can reach the data or its backups
• Internal network paths from an ordinary employee device, since the regulation names internal threats as well as external ones

A database security audit produces the configuration and access evidence an auditor asks for under Regulation 16, and a penetration test shows whether those controls hold under attack, which is what Regulation 5 asks. Keep the reports, the decision you took on each finding and the evidence of each fix: under Amendment 13, that file is what you show the PPA.

Breach reporting: immediately means immediately

Under Regulation 11, the controller of a medium or high level database must immediately notify the Registrar of Databases at the PPA of a severe security incident and report the measures taken, and the Registrar may order the controller to notify people who may be harmed. At high level a severe incident is any use of data without authorisation or beyond it, or damage to data integrity; at medium level it is the same, but involving a substantial part of the database. Every level must keep a record of security incidents.

The PPA reads immediately strictly. Its earlier published guidance treated 24 hours from discovery as the appropriate timescale; in 2022 it changed the policy to require immediate notification of incidents that are discovered or reasonably suspected. On 21 July 2026 it fined a health maintenance organisation, a public body, NIS 256,000 for failing to report a security incident in time: the organisation had reported it roughly two months after becoming aware of it. Pearl Cohen described it as the first administrative fine the PPA has imposed specifically for a breach notification failure, using the powers Amendment 13 created.

1. 1

   Classify before you need to

   Record each database's security level now, so on the day you know whether the severe-incident duty applies and what severe means for that database.

2. 2

   Name the decision makers

   A standing group of the data protection officer, the security lead, legal counsel and a member of senior management, with the authority to report without waiting for a board meeting.

3. 3

   Draft the first report in advance

   Keep a template for the facts the PPA will ask for: what happened, which database, which data, when you found it and what you have done so far.

4. 4

   Map every other clock

   The GDPR's 72 hours for EU personal data, contractual notice periods to customers and any sector regulator, so one incident does not start four improvised processes.

5. 5

   Rehearse it

   Run a tabletop exercise at least once a year on a realistic scenario, such as a leaked database backup or a compromised administrator account.

How Amendment 13 sits alongside the GDPR

Israel holds an adequacy decision from the European Commission, so personal data can flow from the EU to Israel without further safeguards. Adequacy does not switch the GDPR off for Israeli companies, though. If you offer goods or services to people in the EU, or monitor their behaviour there, the GDPR applies to that processing under Article 3(2), and Article 27 generally requires you to designate a representative in the EU in writing.

In practice, build one incident process that meets the stricter rule at each step: notify the PPA immediately, and run the GDPR's 72-hour clock in parallel for EU data. The same evidence serves both regimes. A penetration test and risk assessment that satisfy Regulation 5 also support the regular testing process that Article 32(1)(d) of the GDPR asks for.

Seven steps before the PPA asks for your file

1. 1

   Map your databases

   List every system that holds personal data, including SaaS tools, analytics, logs and backups, with its controller, any processors, the number of people it covers and the number of authorised users.

2. 2

   Classify each one

   Decide whether it holds highly sensitive data, assign its security level, and check the registration and 30-day notification duties.

3. 3

   Settle the officer question

   Check the three Amendment 13 criteria. If you must appoint a data protection officer, involve them in every step that follows.

4. 4

   Refresh the two core documents

   Bring the database definitions document and the data security procedure up to date. They are the first things an investigator or auditor will ask for.

5. 5

   Test on the regulation's clock

   For high level databases, schedule the risk assessment and penetration test within 18 months of the last ones; for medium and high, the audit within 24 months, by someone independent of the database's data security officer.

6. 6

   Fix, and keep the file

   Record each finding, the decision taken and the evidence of the fix. That record is your answer under Amendment 13.

7. 7

   Rehearse the report

   Agree what counts as a severe incident for each database and who decides to report, then rehearse it alongside the GDPR's 72 hours if you hold EU data.

The evidence file an investigator or auditor will expect to see:

• A database inventory with the security level, number of data subjects and number of authorised users for each database
• Current database definitions documents and an approved data security procedure
• Registration or notification records, where required
• The data protection officer's appointment, where required
• Access logs for medium and high level systems, retained for at least 24 months
• The latest risk assessment and penetration test reports for high level databases, with retest evidence
• The latest audit report for medium and high level databases, and the actions taken on it
• An incident log that includes the reasoning for incidents you decided not to report

As an Israel-based team we scope tests and audits to the Data Security Regulations directly. The scoping call is the place to work out what testing your highest-level databases need, and the compliance overview sets Israeli and EU frameworks side by side.