All guides

// guide

Amendment 13 to the Israeli Privacy Protection Law — what does it mean in practice?

Amendment 13 changed one thing above all: it turned the Privacy Protection Law from something hard to enforce into a law with teeth. For most organisations the significance is not a new technical requirement but an expectation that you can show what you did — and when.

What changed, broadly

The amendment substantially expanded the Privacy Protection Authority's enforcement powers and raised the financial penalties that can be imposed. Alongside that it sharpened duties that already existed but were barely enforced — chiefly the duty to secure personal information in a manner proportionate to its sensitivity, and the duty to report serious security incidents.

In practice, much of what the amendment requires was already written into the 2017 Privacy Protection (Information Security) Regulations. What changed is the likelihood that somebody checks.

Who it applies to

Almost every organisation. If you hold information about customers, employees or job applicants, you are operating a database, even if you never thought of it in those terms.

The extent of the duties varies with the sensitivity of the information and its volume. Medical information, financial information and information about personal circumstances are treated as especially sensitive, and the requirements around them are stricter.

Some organisations are also required to appoint a privacy protection officer. Whether that applies to you depends on the nature of the activity and the volume of data, and it is a question to settle with a lawyer rather than infer from an article.

What it means in practice

Three questions worth being able to answer, because they are exactly what gets asked after an incident.

What do you hold, and where? A map of the personal information you hold, where it sits and who reaches it. Most organisations discover systems at this stage that they did not know held data.

How would you know something happened? Without monitoring and access to logs, you depend on somebody telling you — and a late report of an incident is itself a problem.

What can you show? Not what you did, but what you can demonstrate you did. That is the difference between an organisation that handled things properly and one that can also show it handled things properly.

Where to start

Not by buying a product. Start with mapping — what is held, where, and who reaches it. A risk assessment does exactly this, and its output is also a document you can produce.

The decisions follow from there: what needs encrypting, where permissions need narrowing, how long to retain logs, and what is monitored.

That order matters. An organisation that buys tools before mapping usually protects what it already knew about very well, and what it did not, not at all.

The question asked after an incident is not what you did, but what you can show you did.

This is general information, not legal advice. What applies to a particular organisation depends on its activity, the data it holds and its regulator.