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	+ Annual audit, incident response plan, DPO

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

Step 2: Database Registration Check

Following the established database registration requirements, registration with the Privacy Protection Authority is required only if:

• Database owned by a public body, OR
• Database contains data on 10,000+ individuals AND the primary purpose is transferring data to others (data brokers)

The previous broad requirement covering any database with sensitive data no longer applies.

Registration URL: For registration information, contact the Privacy Protection Authority at gov.il

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

Under 2017 regulations:

1. Severe security incident: Report to Privacy Protection Authority "without delay"
2. No specific hour deadline (unlike GDPR's 72 hours), but "without delay" interpreted as quickly
3. Notify affected individuals if breach may cause them significant harm
4. Document: All incidents, response actions, and decisions

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). Under Amendment 13, the following entities must appoint a Privacy Protection Officer:

• Public bodies
• Data brokers (entities whose primary purpose is transferring personal data to others)
• Entities processing sensitive data at significant scale

The PPO is the contact point with the Privacy Protection Authority and is responsible for monitoring compliance.

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 transferring data to others (data brokers). The broader pre-Amendment requirement for any database with sensitive data no longer applies.

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, data brokers, and large-scale sensitive data processors	Broader requirement
Breach notification	"Without delay", no specific hours	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:

1. Assess data types for sensitivity level
2. Check if destination country has adequate protection
3. Determine transfer mechanism (adequacy, consent, contractual clauses)
4. 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:

1. 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.
2. Optional categories (explicit opt-in): analytics, session replay (Clarity / Hotjar / FullStory), error monitoring with user data (Sentry Session Replay), marketing, personalization.
3. 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 (0 or 1) 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 is 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)

// 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"

<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).

// 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:

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.
• Israeli Privacy Protection Law predates GDPR (1981 vs 2016) and still has key differences even after Amendment 13: no specific 72-hour breach notification deadline (still "without delay"), narrower right to erasure, and database registration still exists (though narrowed to public bodies and data brokers). 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.