Skip to content
HACKTECH
RegulationReported Published 4 sources

Israel's privacy regulator fines Meuhedet NIS 256,000 for late breach report

Israel's Privacy Protection Authority (PPA) imposed a NIS 256,000 sanction on the Meuhedet health fund on 21 July 2026 for failing to report a serious security incident immediately. Legal commentaries say a fault in a digital system let insured persons, in certain circumstances, view relatives' medical files, and that Meuhedet knew of it by November 2025 but reported it on 27 January 2026. Commentators describe it as the first financial sanction since Amendment 13 to the Protection of Privacy Law took effect on 14 August 2025. Further sanctions followed, including NIS 64,000 against Beit Shemesh Municipality in September 2026.

  • Israel
  • Privacy Protection Authority
  • Amendment 13
  • breach notification
  • healthcare
  • access control

What the sources report

  • On 21 July 2026 the PPA imposed a NIS 256,000 monetary sanction on Meuhedet Health Fund for breaching the duty to report a serious security event immediately, under Regulation 11(d) of the Protection of Privacy (Data Security) Regulations (DPOAS; INPLP).
  • INPLP (AYR Lawyers) reports that a technological fault in a digital system allowed insured persons, in certain combinations of circumstances, to view relatives' medical files. It surfaced when an insured person reported that he could see a relative's medical file.
  • Meuhedet became aware of the incident in November 2025, established about six weeks later that the fault was systemic, fixed it at the end of January 2026 and reported it to the PPA on 27 January 2026, roughly two months after the initial complaint (INPLP; DPOAS). DPOAS says NIS 256,000 is the amount left after statutory reductions and that the base figure was not published.
  • Pearl Cohen describes it as the first administrative fine the PPA has imposed specifically for failing to comply with the breach notification obligation, under enforcement powers expanded by Amendment 13, which took effect on 14 August 2025.
  • In September 2026 the PPA imposed NIS 64,000 on Beit Shemesh Municipality after a fault in its GIS system exposed personal and medical information on about 4,600 residents through the municipality's public website. The breaches cited were failing to identify a supplier with continuous database access as a holder (Regulation 2(a)(7)) and a security procedure that did not regulate external parties' access (Regulation 15(a)(3)) (INPLP; Arnon, Tadmor-Levy).
  • Arnon, Tadmor-Levy reports a matter involving the Ministry of Education in which sensitive data on about 21,000 students was exposed. The PPA cited the absence of a Database Specification Document, a compliant information security procedure and an Information Security Risk Assessment, and rejected the argument that ISO/IEC 27001 certification substitutes for them.

What it means for your organisation

The penalty was for the delay, not for the fault itself: the regulator treats the reporting duty as starting when an organisation becomes aware of a serious incident, not when its investigation ends. The underlying fault, insured persons able to view relatives' files, is an authorisation failure of the kind application testing is designed to catch. The Beit Shemesh and Ministry of Education matters add that supplier access rules and documented risk assessments are enforced in their own right, and that a certification does not replace them.

What we check

  • Test object-level authorisation in patient and customer portals, including linked or family accounts, to confirm users cannot view other people's records.
  • Review the breach-notification runbook: the severity criteria, and who decides to notify the PPA once a serious incident is known, without waiting for the forensic investigation to finish.
  • Confirm the database specification document lists every processor and holder, and that contracts set rules for external service providers' database access.
  • Confirm a current information security risk assessment and security procedure exist as documents in their own right, rather than being assumed from an ISO/IEC 27001 certificate.

Sources

Services that cover these checks

  • Application security audit

    A white-box review of your application: source code, architecture, dependencies and build pipeline. Automated analysis finds the candidates; reviewers confirm each one by reading the code path, and only confirmed defects reach the report, each with a file and line reference.

    Duration: 5 to 15 working days, depending on codebase size

  • Web application testing

    Authenticated, role-aware testing of your application and its API surface, with an account for every role. We chain small findings into the access they lead to, such as a sequential invoice ID and a missing tenant check that together let one customer read another's invoices.

    Duration: 5 to 10 working days

  • Database security audit

    A configuration and access review of your production databases: who can connect, from where and with which privileges, whether data is encrypted at rest and in transit, what is logged, and whether backups would survive the same attacker. We read each instance's live configuration.

    Duration: 3 to 7 working days

  • Incident response

    Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow the scoping call works