A recent NIS 256,000 sanction against an Israeli health service provider sends a message to all Israeli companies: fixing the technical failure which was the source of the cyber incident is no longer enough. Under Amendment 13 of the Israeli Privacy Protection Law, and similar global privacy regimes, regulators increasingly expect fast escalation, documented decisions, and early assessment of reporting obligations.
According to the PPA’s announcement, the failure allowed, in certain cases, unauthorized access to medical information. The provider became aware of the incident in November 2025 but reported it only at the end of January 2026. The Authority determined that the report was not submitted immediately as required, and that organizations should not wait until all examinations are complete before submitting an initial report based on the information known at that time.
This assessment is made based solely on the official publication, and without drawing conclusions regarding the provider’s conduct in real time.
It should be emphasized that the sanction was not imposed because the organization failed to completely prevent the failure. Security incidents may occur even in organizations that invest significant resources in protection. The regulatory test begins when the organization discovers the incident, or when there are indications requiring an immediate assessment of its significance. Therefore, the main question is not who is to blame, but whether there is a mechanism that enables the organization to identify in time an incident that requires escalation, examine whether reporting is required, document who made the decision and on what data, and act even when the information is still incomplete.
Why Amendment 13 of the PPL Matters in a Global Context
Amendment 13 to the Israeli Privacy Protection Law entered into force on August 14, 2025, and is the most comprehensive update to the law since it was enacted in 1981. The amendment expanded the definition of personal information, established new obligations regarding the management and processing of information, strengthened the status and powers of the Privacy Protection Authority, and gave it the legal basis to impose significant financial sanctions, which in certain cases may reach millions of shekels for each violation.
This direction is not unique to Israel. Under frameworks such as GDPR and UK GDPR, organizations must assess personal data breaches quickly, notify regulators within strict timelines when required, and document the facts, impact, and remedial actions taken. In many cases, notification may be required before the technical investigation is complete. Almost every company that manages a customer list, employee system, consumer club, security cameras, application, service center, or digital marketing activity is subject to the provisions of the law. The fact that a certain database is not required to be registered does not exempt the organization from the other obligations relating to privacy and data security.
When Should Reporting Be Considered?
Reporting obligations vary by jurisdiction, sector, database classification, and the nature of the incident. But the common direction is clear: organizations are expected to assess reporting duties early, even when information is still incomplete. An initial report can often be based on the information available at the time, with updates provided later. Moreover, a reporting obligation to the Police, the Israel National Cyber Directorate, a sectoral regulator, or the insurance company does not replace the reporting obligation to the Privacy Protection Authority.
A Practical Guide for Organizations: How to Reduce Regulatory Exposure
1. Know What Information You Hold
Start with a real map of the personal information your organization holds, including formal databases, shared files, cloud systems, backups, forms, marketing systems, call recordings, and supplier-held data. Without this visibility, it is difficult to understand in real time whether an incident triggers reporting obligations.
An organization that does not know what information it holds, where it is located, and who can access it will find it very difficult to understand in real time whether a particular incident requires reporting.
2. Define in Advance What Constitutes an Incident That Triggers an Emergency Procedure
Not every technological failure is a reportable incident, but the decision should not be improvised during a crisis. Define in advance who assesses the event, who joins the situation assessment, who is authorized to decide on reporting, and how quickly the first decision must be made.
The team should include, at a minimum, representatives of information security, management, legal, and privacy. In significant incidents, cyber incident response and crisis management experts should also be involved during the first hours. Ideally, readiness should not rely only on a contact list or a static procedure, but on a mechanism that centralizes, in real time, the facts, decisions, role owners, timelines, and open tasks.
3. Do Not Let Technological Investigation Delay the Legal Assessment
Security teams naturally seek a complete technical answer: how the attacker entered, how long they remained, and exactly what they did. But regulation does not always allow organizations to wait until all answers are available.
The technological investigation and the legal assessment should be conducted in parallel. While the technical teams collect findings, the legal stakeholders and the privacy officer should assess whether the information already available triggers a reporting obligation, to the extent required by law. For this to happen, the organization needs an organized work environment where it is possible to see who knows what, what has not yet been clarified, which decisions have already been made, and what the deadline is for an additional regulatory assessment.
4. Appointing a Data Protection Officer Where Required
Where required, organizations should appoint a Data Protection Officer or equivalent privacy leader. Even where this is not formally mandatory, clear privacy ownership helps prevent critical decisions from falling between legal, IT, security, marketing, HR, and operations.
The role of the Privacy Protection Officer is not only to appear in the company’s documents. He must be involved in decisions regarding information collection, contracting with suppliers, introducing new technologies, handling customer requests, and of course managing security incidents.
5. Require your Processors to Notify You Immediately
Many incidents begin with a cloud provider, software company, service center, payroll provider, or business partner that holds information on behalf of the organization. From a regulator’s perspective, outsourcing data processing does not necessarily outsource responsibility.
Service Agreements should include an immediate notification obligation for any suspected incident, defined response times, sharing of findings, preservation of evidence, and assistance with reporting to regulators and data subjects.
6. Document Every Decision in Real Time
Document when the incident was discovered, who was updated, what was known at each stage, what actions were taken, which alternatives were considered, and why the organization decided to report immediately or wait, and continue assessing.
Organized documentation is not only an operational requirement. In the event of a regulatory review, it enables the organization to show that it exercised professional judgment and acted as quickly as possible based on the information available to it at the time. Without such documentation, even a decision that seemed reasonable in real time may later appear to be an unfounded delay.
7. Practice the Scenario Before It Happens
A procedure that sits in a folder will not be enough in an emergency. Organizations should run management exercises that simulate data exposure, ransomware, supplier compromise, or operational disruption.
The exercise should test not only how systems are restored, but also who contacts the Authority, who updates employees and customers, who manages communications, and who make decisions when the information is partial and time is short. An effective exercise should also test the ability to activate an organizational situation room, centralize documents and decisions, manage tasks across teams, and produce a timeline that can later be presented to management, the regulator, or the insurer.
Privacy Is Now an Operational Risk
It is clear now that privacy is no longer a narrow legal issue into but a central component of organizational risk management. Responsibility cannot remain solely with the legal counsel, the information systems manager, or the information security officer. It requires joint work by management, technology teams, human resources, marketing, operations, and suppliers.
Every organization should ask itself: if an incident happens tomorrow, can we identify it, convene the right team, assess reporting duties, document our decisions, and act before the full picture is known?
In the era of pro-active regulators, proper incident management does not begin when all the facts are known. It begins much earlier: with information mapping, management exercises, defined authorities, decision documentation, and the ability to manage a cyber and privacy incident from one clear, updated situational picture. The goal is not to assume that every failure can be prevented, but to ensure that the organization can make responsible, documented, and evidence-based decisions in real time.
*The content of this article is general information only and does not constitute legal advice.
Adv. Michal Bartov, DPO
Head of the Legal Department at Code Blue, which specializes in supporting organizations in managing privacy, regulatory, and cyber incident risks.
