Most Israeli startups will discover they’re covered by the new cybersecurity law the same way they discovered they needed SOC 2: a customer asked about it right before a procurement call.
Israel’s National Cybersecurity Law (5786-2026) passed the Knesset in early 2026 after years of sector-specific regulation and voluntary INCD frameworks. For the first time, a single binding statute establishes minimum cybersecurity obligations for a broad class of private-sector organizations — not just banks or defense contractors.
If your company is registered in Israel, processes personal data of Israeli residents, or operates digital infrastructure with meaningful dependencies, this law likely applies to you. This post walks through what it requires, what the enforcement timeline looks like, and what an early-stage or growth-stage company actually needs to do to get compliant without derailing the roadmap.
The short version
| Point | Why it matters |
|---|---|
| The law applies beyond critical infrastructure | Technology companies, SaaS platforms, and cloud-hosted services fall under scope — not only utilities and finance |
| Incident reporting is mandatory and time-bound | You have 72 hours to report significant cyber incidents to INCD, and 30 days for a full post-incident report |
| The INCD can audit and penalize | Non-compliance carries fines and, in serious cases, operational restrictions — enforcement starts in Q4 2026 |
What the law actually is
The National Cybersecurity Law 5786-2026 is Israel’s first comprehensive, cross-sector cybersecurity statute. Before it passed, cybersecurity obligations in Israel were scattered across sector regulators — the Bank of Israel for financial institutions, the Ministry of Health for healthcare, the National Infrastructure Authority for energy and water. Every regulator published its own framework, with different terminology and different audit cycles.
The 2026 law doesn’t replace those sector frameworks. It sits above them, establishing a baseline floor that applies to all covered entities. Organizations subject to sector-specific regulation (banking, healthcare, critical infrastructure) still follow their vertical rules, but everyone else now has a binding national standard to meet.
The Israel National Cyber Directorate (INCD) is the supervising body. The INCD already published voluntary frameworks — most notably the Israeli Cyber Defense Methodology — but enforcement was soft. The new law changes that: the INCD now has formal inspection authority, the ability to issue compliance orders, and a penalty structure for non-compliance.
Who is covered
The law establishes two tiers of covered entity, based on the potential systemic impact of a security failure.
Tier 1 — Significant Digital Assets: Organizations that operate digital services or infrastructure classified as having material national significance. The INCD publishes a registry. This tier includes telecom providers, financial market infrastructure, large cloud platforms operating in Israel, and healthcare networks. They face the strictest requirements.
Tier 2 — Covered Private Entities: Companies that fall below the Tier 1 threshold but meet one or more of the following:
- More than 50 employees and primarily a digital or technology business
- Annual revenue exceeding ₪50 million from digital products or services
- Processing personal data of more than 100,000 Israeli residents
- Providing B2B digital services to Tier 1 organizations in a supply chain role
Most Israeli tech startups that have found product-market fit will land in Tier 2 by the time they’re thinking about this law. A Series A SaaS company with 60 employees that processes customer data almost certainly qualifies.
Companies below all Tier 2 thresholds are not directly covered, but may still face contractual requirements from Tier 1 customers who need to demonstrate third-party security controls in their own compliance reporting.
Core obligations
The law establishes four areas of mandatory control. The specific technical standards under each area are being published by INCD as delegated regulations through 2026, but the statutory categories are fixed.
1. Minimum cybersecurity baseline
Covered entities must implement and maintain documented security controls covering:
- Access control — privileged access management, MFA enforcement on all administrative and remote access, periodic access reviews
- Asset inventory — a maintained register of information systems and the data they process
- Patch management — a defined process and SLA for applying security patches to internet-facing systems
- Network segmentation — isolation of critical systems from general office networks
- Endpoint protection — EDR or equivalent on managed devices
- Backup and recovery — tested backup procedures with a defined recovery time objective
For Tier 2 entities, the INCD has indicated these controls map closely to CIS Controls Level 1 and the existing Israeli Cyber Defense Methodology (ICDM) framework. If your organization already completed a SOC 2 Type II audit, you’re likely meeting most of these requirements — but there are Israel-specific additions around incident reporting and INCD coordination that SOC 2 doesn’t cover.
2. Incident reporting
This is the area where the law introduces the most operationally significant change for startups. Voluntary reporting was the prior expectation; mandatory reporting with hard timelines is now the rule.
Significant cyber incident: An event that disrupts or degrades the organization’s digital services, results in unauthorized access to personal data of Israeli residents, or involves ransomware or destructive malware. The INCD definition is intentionally broad.
| Timeframe | Obligation |
|---|---|
| Within 72 hours of detection | Initial incident report to the INCD via the national reporting portal |
| Within 30 days of incident closure | Comprehensive post-incident report including root cause, impact assessment, and remediation steps |
| Ongoing, during active incidents | Cooperation with INCD if the Directorate requests real-time access to forensic data or indicators of compromise |
The 72-hour clock starts from “detection,” not discovery of full scope. If your SOC or SIEM triggers an alert at 2 a.m. on a Tuesday, the clock is running from 2 a.m. on Tuesday regardless of when the incident review meeting takes place. This is the same trigger model as GDPR’s 72-hour personal data breach notification, and Israeli privacy counsel generally advises treating them in parallel.
Reporting goes through the INCD’s national cyber reporting system (CERT-IL interface). There is no fee, but incomplete reports can trigger follow-up requests and delay your incident closure.
3. Designated security responsibility
Covered entities must designate a responsible person for cybersecurity. For most startups, this will be the person who already owns IT or infrastructure — formalized with a written appointment and documented scope of responsibility.
Tier 1 entities are required to appoint a qualified CISO with defined professional criteria. Tier 2 entities have more flexibility: the role can be internal or outsourced, but the designation must be documented and the named person must be reachable for INCD inquiries.
This is where managed SOC and virtual CISO (vCISO) arrangements become relevant. The law does not prohibit outsourcing the cybersecurity function — it requires accountability, not headcount.
4. Supply chain security
If you provide digital services to Tier 1 organizations, you may receive contractual cybersecurity requirements as a downstream obligation. The law requires Tier 1 entities to conduct security assessments of their significant suppliers — which means your enterprise customers in financial services, healthcare, or telecom will likely start sending you vendor security questionnaires with specific reference to 5786-2026.
Conversely, if you’re a startup that depends heavily on third-party SaaS tools and cloud services, you now have your own obligation to understand the security posture of your critical suppliers and document that assessment.
Penalties and enforcement
The law establishes a tiered penalty structure administered by the INCD, with a separate administrative tribunal handling appeals.
| Violation | Maximum fine |
|---|---|
| Failure to report a qualifying incident within 72 hours | ₪500,000 per incident |
| Failure to maintain minimum baseline controls (after notice period) | ₪1,000,000 |
| Failure to cooperate with an INCD inspection | ₪250,000 |
| Repeat violation within 24 months | Double the applicable maximum |
For Tier 1 entities, the INCD can also issue operational restrictions — essentially ordering that certain services be taken offline until remediation is complete. Tier 2 entities are not subject to operational restrictions in the first compliance cycle.
Enforcement timeline: The INCD announced a phased approach. Inspections for Tier 1 organizations begin July 2026. Tier 2 inspections start in Q1 2027, with a grace period for organizations that registered with the INCD before October 2026 and demonstrated good-faith compliance effort. The fine structure activates in Q4 2026.
This means you have roughly a six-month window to get baseline controls documented and an incident response process in place before formal enforcement kicks in for the private sector.
What startups actually need to do
Breaking this down into practical steps:
Step 1: Determine if you’re covered. Check the Tier 2 thresholds against your current employee count, revenue, and data processing volume. If you’re close to any threshold, assume you’re in. The cost of assuming coverage is lower than the cost of a wrongly excluded status becoming apparent during an INCD inquiry.
Step 2: Register with INCD. The INCD opened a self-registration portal in March 2026. Registration is mandatory for all covered entities and triggers the grace period for Tier 2 enforcement. The portal is at cyber.gov.il — you’ll need your company registration number, sector classification, and contact details for your designated security responsible.
Step 3: Document your current baseline. Run a gap assessment against the minimum control list. You don’t need a consultant for this — start with what you have. The gaps are usually in access control documentation, patch management SLAs, and formal backup testing records. Most startups already have the tools; they’re missing the documentation.
Step 4: Build an incident response playbook that includes INCD reporting. Your existing IR playbook probably has escalation to legal, customer success, and C-level. Add INCD reporting to that chain explicitly, with the 72-hour clock called out. Assign who submits the report and what data they need. The INCD reporting form asks for: incident timeline, affected systems, estimated number of Israeli residents affected (if personal data), and initial root cause hypothesis.
Step 5: Get your log pipeline in order. You cannot write an accurate incident report if you don’t know what happened. SIEM coverage across your cloud environment, identity provider, and SaaS tools is what makes the difference between “a ransomware event we detected and reported” and “a ransomware event we discovered three weeks later from a customer complaint.” The law doesn’t mandate a specific logging technology — but it creates strong implicit pressure to have audit-quality logs with enough retention to reconstruct an incident.
Step 6: Review your supplier contracts. If you’re supplying to Tier 1 organizations, expect those customers to send you a security addendum in the next six months. If you’re relying on third parties for critical functions (hosting, identity, payment processing), document their SOC 2 or ISO 27001 certifications and keep them on file for supplier review purposes.
Where logging and SIEM fit in
The most common gap we see when working with covered entities is the same one that makes incident response reports hard to write: there’s no centralized audit trail.
A startup might have:
- CloudTrail enabled in AWS (good)
- Okta system logs (good)
- GitHub audit logs (sometimes)
- No correlation between them
- 30-day retention before logs age off (bad)
Under the 2026 law, your incident post-report needs to reconstruct what happened with specificity — timestamps, affected accounts, data accessed. If your logs are in three places with different retention periods and no centralized query layer, writing that report will take weeks instead of days.
The minimum viable logging setup for a Tier 2 company that wants to be defensible under the law looks like this:
Identity provider (Okta / Entra ID)
-> centralized SIEM
-> 12-month hot retention
-> correlated with cloud API logs (CloudTrail / GCP Audit Logs)
-> alert on privileged access events, login anomalies, data export
Twelve months of hot retention matters because the law’s post-incident obligations extend up to 30 days after closure, and investigations often need to look further back than the triggering event to establish the full attack timeline.
This isn’t a pitch for any particular tool. It’s the architecture that makes the 30-day post-incident report accurate rather than speculative.
The Amendment 13 overlap
The National Cybersecurity Law doesn’t exist in isolation. Amendment 13 to the Privacy Protection Law — which passed in 2025 — already introduced data breach reporting obligations to the Privacy Protection Authority (PPA) with a 24-hour initial notification requirement for breaches affecting personal data.
If a security incident involves unauthorized access to personal data of Israeli residents, you’re looking at parallel obligations: 24 hours to the PPA under Amendment 13, and 72 hours to the INCD under the cybersecurity law. The INCD and PPA are coordinating — a joint working group published initial guidance in February 2026 recommending that organizations notify both authorities simultaneously and cross-reference the reports.
In practice: build one incident notification workflow that covers both clocks, not two separate processes.
Final thought
The 2026 law is less prescriptive than GDPR and less burdensome than US federal cyber incident reporting rules for critical infrastructure. For a well-run startup, getting compliant doesn’t require a massive project — it requires making implicit security practices explicit and getting a logging and response process that could actually support a post-incident report.
The organizations that are going to struggle are those that have been treating security as infrastructure-team overhead. The law creates an external forcing function to treat it as an organizational function with accountable ownership.
If you want help assessing where your log coverage stands relative to what the INCD will expect, contact us — we can run a coverage gap review against your current cloud and identity setup.