Israeli Privacy Shield

Critical Note

This skill provides compliance GUIDANCE. It does not replace legal counsel. Recommend consulting a privacy attorney (orech din specializing in prati'ut) for specific compliance decisions.

Instructions

Step 1: Assess Security Level

The 2017 regulations define three security levels:

Level	Criteria	Key Requirements
Basic	< 10,000 records, non-sensitive	Access controls, logging, backup
Medium	10,000+ records OR sensitive data	+ Encryption, security officer appointment
High	Government, health, financial, 100K+ records, or authorized access for 100+ people	+ Incident response plan, DPO, plus a security risk assessment and a penetration test at least once every 18 months with documented findings and remediation

Sensitive data includes: Health, genetics, sexual orientation, political views, criminal record.

Step 2: Database Registration Check

Under the Amendment 13 regime, registration with the Privacy Protection Authority (PPA) is required only if:

Database owned or managed by a public body, OR
Database contains data on 10,000+ individuals AND the primary purpose is collecting and disclosing personal data to third parties as a business or for value (data brokers)

The broad pre-Amendment requirement covering any database with sensitive data (and the old "Form 1" five-trigger list) no longer applies.

Notification tier (separate from registration). Even where registration is not required, a controller of a database that holds especially-sensitive data on more than 100,000 individuals must submit a notification to the PPA within 30 days. The notification includes the controller's identity and contact details, the privacy officer's details (if one is required), and the database definition document prepared under the Data Security Regulations.

Registration and notification are handled through the PPA: https://www.gov.il/en/departments/the_privacy_protection_authority

Step 3: Consent Requirements

Israeli law requires consent for:

Collection of personal data
Use beyond the original purpose
Transfer to third parties
Cross-border transfer

Consent must be: Informed, specific, freely given Exceptions: Legal obligation, vital interests, public interest, legitimate interest (limited)

Step 4: Cross-Border Transfer Rules

Personal data transfer outside Israel requires:

Recipient country has adequate protection (EU, UK, few others), OR
Contractual safeguards (similar to GDPR SCCs), OR
Data subject consent (informed and specific), OR
Listed exemptions (necessary for contract, legal proceedings, etc.)

Note: Israel has EU adequacy decision, transfer TO EU is generally straightforward.

Step 5: Breach Notification

Amendment 13 introduced a hard deadline (replacing the old "without delay, no specific hours" rule):

Notify the Privacy Protection Authority within 72 hours of discovering a reportable breach. The notification must cover the nature of the breach, the categories and approximate number of affected individuals, the likely consequences, and the measures taken or proposed.
Notify affected individuals "without undue delay" where the breach is likely to result in a high risk to their rights and freedoms. The notice must be in clear, plain Hebrew and explain the nature of the breach, the data affected, the potential consequences, and the protective steps individuals can take.
Reportable breach standard: an incident (unauthorized access, disclosure, loss, alteration, or destruction of personal data) that poses a risk to the rights and freedoms of the affected individuals.
Document: all incidents, response actions, and decisions, regardless of whether they cross the reporting threshold.

Step 6: Compliance Checklist

For each assessed entity, verify:

Database registration (if required)
Privacy policy published (Hebrew, accessible)
Consent mechanisms in place
Security measures per level (basic/medium/high)
Data processing agreements with processors
Cross-border transfer safeguards
Breach response plan
Data subject request handling process
Employee training
Privacy Protection Officer appointed (if required under Amendment 13)
AI governance policy for automated decision-making (if applicable)
Personal data inventory includes IP addresses, geolocation, and online identifiers

Step 7: Amendment 13 (Effective August 14, 2025)

Amendment 13 is the most significant reform of Israeli privacy law since 1981. It took effect on August 14, 2025 and expands the Privacy Protection Authority's enforcement powers, broadens the definition of personal data, and introduces new obligations for data brokers and AI systems.

Expanded definition of personal data. Amendment 13 explicitly includes digital identifiers:

IP addresses
Geolocation data
Device identifiers and online identifiers
Biometric and genetic data (already sensitive)

Standard web analytics, session logs, and mobile app telemetry now fall within the scope of the Privacy Protection Law.

Mandatory Privacy Protection Officer (PPO / DPO). Under Amendment 13, the following entities must appoint a Privacy Protection Officer:

Public bodies (government ministries, municipalities, universities, HMOs and similar), except national-security entities
External suppliers and processors acting for those public bodies
Data brokers, with a concrete threshold: a controller whose database holds personal data on more than 10,000 individuals AND whose main purpose is collecting personal data to disclose it to third parties as a business or for value (including direct-mailing services)
Entities that systematically monitor individuals on a large scale, or whose core business includes processing especially-sensitive data on a large scale

The PPO is the contact point with the Privacy Protection Authority and is responsible for monitoring compliance. Note: the PPA announced it would not enforce the appointment obligation until October 31, 2025.

AI governance for automated decision-making. Amendment 13 requires transparency and oversight for AI systems that make decisions affecting individuals (credit scoring, hiring, insurance, fraud detection). Requirements include:

Documentation of the decision logic and data inputs
Ability to explain outcomes to affected individuals
Human oversight for high-impact decisions
Bias and accuracy monitoring

Enforcement powers and fines. Amendment 13 significantly expands the Authority's administrative powers:

Direct supervisory inspections without prior notice
Administrative fines up to approximately NIS 3.2 million for serious violations
Ability to issue binding compliance orders

Entities that were previously under the radar of enforcement now face real financial exposure.

What changed for database registration. Amendment 13 narrowed the registration requirement. Registration with the Authority is now required only for public bodies and databases of 10,000+ individuals whose primary purpose is collecting and disclosing personal data to third parties as a business or for value (data brokers). The broader pre-Amendment requirement for any database with sensitive data no longer applies. Separately, a controller of a database that is not subject to registration but holds especially-sensitive data on more than 100,000 individuals must file a notification with the Authority within 30 days, including the database definition document.

GDPR vs Israeli Law Key Differences

Aspect	Israeli Law (post Amendment 13)	GDPR
Legal basis	Consent primary, limited exceptions	6 legal bases
Privacy officer requirement	Public bodies (and their processors), data brokers (10,000+ records), large-scale sensitive-data processors, and large-scale systematic monitors	Broader requirement
Breach notification	72 hours to the PPA; affected individuals "without undue delay" where high risk	72 hours
Administrative fines	Up to ~NIS 3.2M for serious violations + criminal liability	Up to 4% global revenue
Right to erasure	Limited	Comprehensive (right to be forgotten)
Database registration	Public bodies and data brokers only (10,000+ records)	Not required (replaced by ROPA)
Personal data scope	Includes IP, geolocation, online identifiers (Amendment 13)	Includes online identifiers
AI governance	Required for automated decision-making (Amendment 13)	Article 22 automated decision-making rules
Extra-territorial scope	Limited	Broad

Examples

Example 1: SaaS Startup Compliance

User says: "I'm building a SaaS with Israeli customers, what privacy requirements apply?" Result: Assessment of security level, database registration need, privacy policy requirements, recommended consent mechanisms.

Example 2: Data Breach Response

User says: "We discovered a data breach affecting Israeli users" Result: Step-by-step breach response: contain, assess, notify authority, notify users if significant harm, document.

Example 3: Cross-Border Data Transfer

User says: "We need to transfer Israeli customer data to our US servers" Actions:

Assess data types for sensitivity level
Check if destination country has adequate protection
Determine transfer mechanism (adequacy, consent, contractual clauses)
Document compliance steps Result: Transfer compliance checklist with specific steps for US data transfer under Israeli Privacy Protection Law.

Bundled Resources

Scripts

```
scripts/compliance_checker.py
```
, Runs a full Privacy Protection Law compliance assessment: determines security level (basic/medium/high), checks database registration requirements, and generates a compliance checklist with all applicable controls. Run:
```
python scripts/compliance_checker.py --help
```

References

```
references/privacy-law-requirements.md
```
, Detailed breakdown of the Privacy Protection Law 1981 and 2017 Security Regulations including database registration process, security level requirements, consent rules, cross-border transfer rules, breach notification procedures, and penalties. Consult when you need specific legal requirements, section numbers, or GDPR comparison details beyond what the instructions cover.
```
references/consent-banner-implementation.md
```
, Copy-pasteable TypeScript/React code for an Amendment 13 + GDPR compliant consent banner: pub-sub store with SSR sentinel, localStorage + companion cookie (12-month TTL,
```
CONSENT_VERSION
```
-bumped re-prompt), cross-tab sync via
```
storage
```
event, server-side cookie check for SSR gating, Sentry pre-init hydration pattern and mid-session Replay attach, essential-event allowlist, dismissal-as-refusal handling. Consult when the user wants to ship the consent UI itself, not just understand the law.

Implementing a Compliant Consent Surface

The Privacy Protection Law after Amendment 13, GDPR for EU visitors, and the 2017 Security Regulations all require explicit, opt-in, granular consent before collecting personal data beyond what is strictly necessary to deliver the service. The consent surface is where that requirement becomes code. A banner copy-pasted from a generic template almost always fails one of the legal tests below. This section covers the UI patterns that satisfy all three legal frames at once.

State Model

Model consent as three layers:

Essential (always on, never toggled): session auth, CSRF, consent cookie itself, bot protection (Turnstile), accessibility preferences, anything required to deliver the requested service. The user has no choice here, by design.
Optional categories (explicit opt-in): analytics, session replay (Clarity / Hotjar / FullStory), error monitoring with user data (Sentry Session Replay), marketing, personalization.
No consent yet (first visit): distinct from "rejected all" and from "accepted all". Treat as null.

The persisted state is a tagged version + category map + timestamp:

interface ConsentState {
  version: number;          // bump to force re-prompt when adding a category
  categories: {
    analytics: boolean;
    session_replay: boolean;
    error_monitoring: boolean;
    // add categories as needed; each gets its own opt-in
  };
  timestamp: string;        // ISO; used for 12-month re-prompt
}

Persistence

Store the state in both

localStorage

and a companion cookie.

localStorage

is the source of truth for the client; the cookie exists so Server Components can gate SSR work (e.g.

incrementBundleViews

inside

after()

) without a client round-trip. The cookie only needs a single bit (

) because Server Components rarely distinguish individual categories.

// lib/consent/store.ts
export const CONSENT_VERSION = 1;
export const CONSENT_STORAGE_KEY = 'site_consent_v1';
export const CONSENT_COOKIE_NAME = 'site_consent';
export const CONSENT_REPROMPT_MS = 365 * 24 * 60 * 60 * 1000;

function writeCookie(state: ConsentState | null) {
  const maxAge = Math.floor(CONSENT_REPROMPT_MS / 1000);
  const secure = location.protocol === 'https:' ? '; Secure' : '';
  if (!state) {
    document.cookie = `${CONSENT_COOKIE_NAME}=; Path=/; Max-Age=0; SameSite=Lax${secure}`;
    return;
  }
  const value = state.categories.analytics ? '1' : '0';
  document.cookie = `${CONSENT_COOKIE_NAME}=${value}; Path=/; Max-Age=${maxAge}; SameSite=Lax${secure}`;
}

Re-prompt rules.

readStorage()

returns

null

if the stored

version

mismatches

CONSENT_VERSION

or the timestamp is older than 12 months. Bumping

CONSENT_VERSION

when adding a new tracker category forces a fresh prompt, this is how you stay compliant when you add a new analytics vendor.

SSR Safety: The SSR_SENTINEL Pattern

Naive

useSyncExternalStore

with a

null

server snapshot renders the banner in the initial SSR HTML, which means a) the banner is visible for a moment before hydration replaces it, and b) search engines index pages with the consent dialog overlaying the content. The fix is a sentinel object that is identity-compared to distinguish the server/hydration render from "user hasn't decided yet":

export const SSR_SENTINEL: ConsentState = Object.freeze({
  version: -1,
  categories: ALL_CATEGORIES_OFF,
  timestamp: '1970-01-01T00:00:00.000Z',
});

// In the provider:
const rawState = useSyncExternalStore(
  consentStore.subscribe,
  consentStore.getSnapshot,
  consentStore.getServerSnapshot,  // returns SSR_SENTINEL
);
const isHydrated = rawState !== SSR_SENTINEL;
const state = isHydrated ? rawState : null;

const needsPrompt = isHydrated && state === null;

Only when

isHydrated

is true AND

state

null

does the banner render. The sentinel is identity-compared with

!==

, which is why it is frozen and exported as a module constant.

Cross-Tab Sync

Users open multiple tabs. If they reject consent in one, the others must respect that immediately. Listen for the

storage

event, which fires across tabs sharing the same origin:

function onStorageEvent(e: StorageEvent) {
  if (e.key === null || e.key === CONSENT_STORAGE_KEY) notify();
}
// Attach in subscribe() when first listener is added, detach when last leaves.

Dismissal-As-Refusal

GDPR Article 4(11) and the EDPB guidance require that dismissing a consent banner counts as refusal. Amendment 13 is aligned. That means:

Escape key = reject all
Close button (X) = reject all
Clicking outside the banner = leave banner visible (do NOT treat as accept)

tsx

// ESC handler inside the banner component
useEffect(() => {
  if (!promptOpen) return;
  function onKey(e: KeyboardEvent) {
    if (e.key === 'Escape') rejectAll();
  }
  window.addEventListener('keydown', onKey);
  return () => window.removeEventListener('keydown', onKey);
}, [promptOpen, rejectAll]);

Visual Equal Weight for Reject and Accept

GDPR Recital 42 + multiple DPA enforcement decisions require that Reject and Accept carry equal visual weight. In practice:

Same button style (both primary, or both outline)
Same width
Same position (side by side, not one hidden behind "Customize")
"Customize" is a third action, not a replacement for "Reject"

tsx

<div className="grid grid-cols-3 gap-2">
  <Button size="sm" variant="outline" onClick={rejectAll}>{dict.rejectAll}</Button>
  <Button size="sm" variant="outline" onClick={openPreferences}>{dict.customize}</Button>
  <Button size="sm" onClick={acceptAll}>{dict.acceptAll}</Button>
</div>

Gating the Trackers

The consent state must actually prevent non-consented trackers from running. A banner that does not stop scripts is worse than no banner (it creates a paper trail of false compliance).

tsx

// components/consent/consent-gated-trackers.tsx
export function ConsentGatedTrackers() {
  const { isAllowed } = useConsent();
  return (
    <>
      {isAllowed('analytics') && <Analytics />}
      {isAllowed('analytics') && <SpeedInsights />}
      {isAllowed('session_replay') && <ClarityScript />}
    </>
  );
}

Also gate the client-side

trackEvent

helper, events emitted before consent is granted should be dropped, not queued:

const ESSENTIAL_EVENTS = new Set([
  'consent_banner_shown', 'consent_accepted', 'consent_rejected',
  'consent_customized', 'consent_reopened', 'auth_sign_in',
]);

export function trackEvent(event: string, data?: Record<string, unknown>) {
  if (!ESSENTIAL_EVENTS.has(event) && !window.__consent?.analytics) return;
  // ...send to analytics backend
}

The essential-event allowlist is for legally transactional events (the consent choice itself, auth), not a general escape hatch.

Sentry Integration: Two Pieces

Sentry is unusual because

Sentry.init()

runs in

instrumentation-client.ts

before React hydrates, which is before

useConsent()

can tell you what the user wants. Two pieces:

1. Hydrate
window.__consent
from storage BEFORE
Sentry.init()
. Without this, any errors thrown during early hydration are captured even if the user previously rejected consent.

// instrumentation-client.ts
import { hydrateWindowFromStorage } from '@/lib/consent/store';

hydrateWindowFromStorage();  // sets window.__consent from localStorage

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  integrations: window.__consent?.session_replay ? [Sentry.replayIntegration()] : [],
  beforeSend(event) {
    return window.__consent?.error_monitoring ? event : null;
  },
});

2. Attach Replay mid-session when the user later grants consent. Don't re-run

Sentry.init()

, that breaks the existing client. Use

Sentry.addIntegration()

// lib/consent/sentry-gate.ts
import * as Sentry from '@sentry/nextjs';

export function enableSentryReplay() {
  const client = Sentry.getClient();
  if (!client) return;
  if (client.getIntegrationByName?.('Replay')) return;  // idempotent
  Sentry.addIntegration(Sentry.replayIntegration());
}

The React provider calls

enableSentryReplay()

the first time

state.categories.session_replay

flips to true. Dynamic-import it so the Replay bundle is not shipped to users who rejected it:

useEffect(() => {
  if (state?.categories.session_replay) {
    import('./sentry-gate').then((m) => m.enableSentryReplay());
  }
}, [state?.categories.session_replay]);

Server Component Gating

Server Components can read the companion cookie directly:

// lib/consent/server.ts
import { cookies } from 'next/headers';
import { CONSENT_COOKIE_NAME } from './store';

export async function isAnalyticsAllowedServerSide(): Promise<boolean> {
  const store = await cookies();
  return store.get(CONSENT_COOKIE_NAME)?.value === '1';
}

Use it to gate

after()

calls that increment analytics counters:

tsx

if (await isAnalyticsAllowedServerSide()) {
  after(() => incrementBundleViews(slug));
}

Audit Trail

Amendment 13 and GDPR require you to demonstrate consent on demand. Emit five analytics events through your existing pipeline:

```
consent_banner_shown
```
(first show only)
```
consent_accepted
```
```
consent_rejected
```
```
consent_customized
```
```
consent_reopened
```
(user re-opens from the footer link)

Store them through the same

analytics_events

pipeline you already have, no new table needed. These are the events the allowlist in

trackEvent

lets through even when consent is denied, precisely so you have the refusal on record.

See

references/consent-banner-implementation.md

for complete copy-pasteable code covering the pub-sub store, the

ConsentProvider

, the banner, the preferences dialog, the tracker gate, and the Sentry hydration hook.

Consent UI Anti-Patterns

Israeli DPA enforcement, GDPR DPAs, and the French CNIL have published repeated guidance on UI patterns that look compliant but are not. Any of these will cost you on enforcement even if the underlying law text is satisfied.

Anti-pattern	Why it fails	Fix
Pre-checked boxes for analytics / marketing	Consent must be explicit opt-in. CJEU Planet49 (C-673/17) is the binding precedent.	Default unchecked; user must actively flip the switch.
"Accept" button styled larger/colored, "Reject" styled as a text link	Fails the equal-weight test.	Same component, same size, same visual prominence.
"Reject" hidden behind a "Customize" or "Learn more" submenu	Forces extra clicks to refuse, not to accept.	Reject + Accept on the first screen, side by side.
"By continuing to use the site, you accept cookies" banners	Implicit consent is invalid under GDPR and Amendment 13.	Banner blocks nothing visually, but trackers do not run until explicit choice.
Cookie wall ("You must accept cookies to read this article")	EDPB guidance treats conditioning service on consent to non-essential cookies as invalid.	Provide full service regardless of the choice; degrade only genuinely analytics-dependent features (e.g. hide a session-replay-powered debug button).
Single "Accept all" with no granular option on the first screen	GDPR Article 7(2) requires granularity for distinct purposes.	Either expose the per-category toggles on the first screen, or ensure "Customize" reaches them in one click.
Re-prompting every session	Consent fatigue, treated by DPAs as a dark pattern.	Re-prompt only on `CONSENT_VERSION` bump or after 12 months.
Burying the "withdraw consent" path	Amendment 13 Article 8C + GDPR Article 7(3) require withdrawal to be as easy as granting.	"Privacy preferences" link in the footer that opens the same dialog.
Storing a consent cookie without an expiry / with multi-year TTL	User has not re-consented; stale consent is no consent.	12-month max. Bump `CONSENT_VERSION` whenever you add a tracker.
Loading the analytics SDK script and calling it with `consent=denied` instead of not loading it	Loading itself is a data transfer (IP, UA, referer).	Gate the `<script>` tag, not just the SDK's internal flag.

The banner you ship is one layer. The other layers, a published privacy policy in Hebrew, a named Privacy Protection Officer where required under Amendment 13, a data subject request handling process, a breach response plan, and the database registration for public bodies and data brokers, all have to exist independently. No consent UI substitutes for those.

Gotchas

Amendment 13 took effect on August 14, 2025 and is live law, not a pending proposal. Agents trained on pre-2025 data may treat Amendment 13 as a future change or miss it entirely. Always assume it applies when advising on Israeli privacy compliance today.
Amendment 13 expands "personal data" to include IP addresses, geolocation, and online identifiers. This pulls standard web analytics and mobile telemetry into scope. Agents may still apply the older narrower definition and underestimate what counts as personal data.
Administrative fines under Amendment 13 can reach approximately NIS 3.2 million for serious violations, on top of the existing criminal liability. Agents may cite only the pre-Amendment "relatively low fines" framing and underestimate real exposure.
Amendment 13 introduced a 72-hour deadline for notifying the Privacy Protection Authority of a reportable breach (measured from discovery), with notification to affected individuals "without undue delay" where the breach poses a high risk to their rights and freedoms. The old "without delay, no specific hours" rule no longer applies. Agents trained on pre-2025 data often still cite the outdated framing.
Israeli Privacy Protection Law predates GDPR (1981 vs 2016) and still has key differences even after Amendment 13: a narrower right to erasure, and database registration still exists (though narrowed to public bodies and data brokers, plus a separate 100,000-record especially-sensitive notification tier). Agents may incorrectly apply GDPR rules to Israeli contexts.
Israel has an EU adequacy decision, meaning data transfers FROM Israel TO the EU are generally straightforward. Agents may incorrectly flag Israel-to-EU transfers as requiring additional safeguards.
The 2017 Security Regulations define three security levels (basic/medium/high) based on record count and data sensitivity. Agents may apply a one-size-fits-all approach instead of the tiered model.
Penalties under Israeli privacy law include criminal liability (up to 5 years imprisonment) in addition to administrative fines. Agents may understate the severity by comparing only to GDPR's monetary penalties.

Troubleshooting

Error: "Unsure about security level"

Cause: Borderline case between basic/medium/high Solution: When in doubt, apply the higher level. The cost difference is small compared to non-compliance risk.

Reference Links

Source	URL	What to check
Privacy Protection Authority (gov.il)	https://www.gov.il/en/departments/the_privacy_protection_authority	Enforcement, database registration and notification, guidance
Amendment 13 page (gov.il)	https://www.gov.il/he/pages/13_amendment	Overview of the reform and its obligations
Amendment 13 professional guide (gov.il)	https://www.gov.il/he/pages/guide_tikon13_professional	Detailed implementation guidance for controllers and processors
Amendment 13 FAQ (gov.il)	https://www.gov.il/he/pages/tikun13_qa	Common questions on registration, DPO, breach reporting
Protection of Privacy Law, 5741-1981	https://www.gov.il/he/pages/the_privacy_protection_law	Primary statute text

gov.il pages may return HTTP 403 to automated clients; open them in a browser.

Recommended MCP Servers

```
israel-law
```
MCP, surfaces Israeli primary legislation and regulations (including the Protection of Privacy Law and related regulations). Use it to pull the current statutory text when a compliance question turns on exact wording. Verify the live gov.il pages above for PPA guidance and forms, which an MCP statute index does not cover.

israeli-privacy-shield

NPX Install

Tags

SKILL.md Content