Written by: Guy Bakshi
This is the monthly edition of “Ask the DPO”. Our Head of DPO Services, Guy Bakshi, looks at frequent questions that the DPO is asked. This time, we look at how to prepare for a personal data breach – and what to do when one arrives.
Earlier this month, the Israeli Privacy Protection Authority (PPA) imposed a monetary sanction of NIS 256,000 (approximately USD 83,000) on Meuhedet Health Maintenance Organization (HMO) for failing to report a severe security incident immediately, as required by the Protection of Privacy Law and, specifically, the Protection of Privacy (Data Security) Regulations. The significance of the sanction lies not only in the amount, but also in its signaling: the regulator views delayed reporting as a substantive compliance failure in its own right, arguably because delay can impair containment efforts, frustrate oversight, and increase the risk of harm to affected individuals. Meuhedet did report the incident, but roughly two months after it became aware of it. This is the first monetary sanction the PPA has imposed since Amendment 13 to the Protection of Privacy Law entered into force nearly a year ago, making it a particularly clear warning that reporting obligations are being actively enforced, rather than merely treated as formal requirements.
The lesson is worth stating plainly: when a breach occurs, the clock starts running immediately, and preparation is what allows you to move at the pace the law expects. That is not simply an operational preference, but a legal and risk-management necessity. In the early hours of an incident, organizations must often determine what happened, contain the event, preserve evidence, assess legal exposure, and decide whether notification duties have been triggered, all under significant time pressure and often with incomplete information. Without advance preparation, those decisions are more likely to be delayed, inconsistent, or wrong. Here is where to start.
Prepare a practical breach management and notification procedure. Make sure the procedure reflects your organization’s specific characteristics and activities; it should not be a document that sits in a drawer, unread, nor merely a box-ticking exercise. A good procedure is one that takes your organization’s real risks into account, allocates responsibility to the relevant stakeholders, and is practical, meaning that once you have read it, you know what to do. It should clearly set out escalation paths, decision-making authority, internal reporting lines, documentation requirements, and the process for assessing whether notification is required. The more concrete the procedure is, the less room there will be for hesitation or duplication of effort when time is critical.
Train your people and build awareness. If no one knows about the procedure you prepared, it is worthless. Make sure the relevant stakeholders learn it and understand what their jobs are when a breach occurs. Beyond that, run privacy and security training across the whole organization, not generic training, but training that focuses on your actual risks and on what you expect from your employees: how to recognize suspicious activity, what to document, and when to involve the relevant stakeholders. This matters because incidents are often first identified by employees in business, support, or technical roles rather than by the legal or privacy team. If those employees do not recognize warning signs or do not understand the importance of immediate escalation, valuable time may be lost before the organization even realizes that a reportable event may have occurred.
Assemble a dedicated group for handling data breaches. This is one of the most important steps, and it will largely dictate whether you are ready to handle a breach. Assemble a group that includes the DPO or privacy function, the CISO or security/IT function, Legal counsel, and senior management (the CTO or equivalent). Define this group as the Data Breach Committee. Draft the procedure collaboratively, ensuring everyone understands their respective roles and how the group operates as a cohesive unit. Once a breach occurs, the Committee should convene immediately to review the findings and agree on next steps. This structure is critical because breach response is inherently cross-functional: technical teams may understand the intrusion, but not the notification thresholds; legal teams may understand the regulatory framework, but not the operational realities of containment; management must weigh business continuity and strategic risk. A standing committee brings those perspectives together quickly enough to support defensible and timely decisions.
Allocate responsibilities in advance. The CISO manages the technical aspects in conjunction with the forensics team. The DPO manages the privacy risk. Legal counsel manages the commercial, intellectual property, and legal exposure. The CTO maintains oversight throughout, ensures a comprehensive understanding of the situation, and guides the process to protect the organization’s business goals and interests. Defining these roles in advance reduces the risk of confusion, overlap, or gaps in ownership at the very moment when clarity is most needed. It also helps ensure that key questions are addressed in parallel rather than sequentially, allowing the organization to investigate, assess, and respond more efficiently.
Map out the applicable notification requirements. This mapping must be completed before a breach occurs. Assess which laws apply, map out every relevant notification requirement, and document them in a comprehensive table. If you act as a processor, map out your contractual notification obligations towards your customers as well. Identify the large enterprise customers and those whose sensitive data you process, as this is where the greatest risk lies. Once a breach occurs, you will already know which timeframes bind you. This exercise requires time; therefore, ensure it is completed proactively, rather than hastily during an active breach. This advance mapping is crucial not only for efficiency, but also because notification duties often arise from multiple sources simultaneously: statute, regulation, contract, and sometimes sector-specific expectations. An organization that has not reconciled those obligations in advance may miss a deadline, notify the wrong party, or apply the wrong legal standard under pressure.
Conduct a meaningful assessment. Every breach deserves a thorough assessment covering the facts, the mitigation steps taken, the remediation plan, and the legal and privacy analysis of whether the incident is reportable and what risk it poses to the data and to the individuals concerned. Concluded that the risk is low or non-existent, and that the breach is not reportable to the authorities, to customers or to data subjects? Document that conclusion and how you reached it. A decision not to report is a decision you may have to explain later. That is precisely why the assessment must be disciplined and evidence-based rather than intuitive or overly optimistic. Regulators often scrutinize not only whether an organization reported, but whether its decision-making process was reasonable in light of the facts known at the time. A well-supported assessment can therefore be as important as the ultimate conclusion itself.
You will never know when a breach will knock on your door (or just surprise you through the back door) – but one will. That is its nature. What you can control is the level of preparation. Implement the steps above, and you will be managing the risk instead of letting it manage you. More importantly, preparation does not merely improve operational readiness; it strengthens legal defensibility, reduces the likelihood of preventable harm, and puts the organization in a far better position to demonstrate that it acted responsibly, promptly, and in good faith when tested.
