The website privacy policy is the most public legal interface of your organization with data subjects. Amendment 13 expanded the transparency duty; GDPR adds another layer for organizations that target or monitor people in the EU. Here is what an updated policy looks like in 2026, the mandatory clauses, the common pitfalls, and the difference from cookie policy and internal privacy policy.
Privacy policy in brief
- Legal basis: Amendment 13 + GDPR (if relevant)
- Required for: Any site that collects personal data
- Typical length: 4-30 pages by complexity
- Update: Quarterly or upon significant change
- Approved by: CEO / Board + DPO
- Language: In the language users actually read
- DPO contact: Mandatory under Amendment 13
- Included in DPO as a Service: Yes
What is a website privacy policy vs. internal policy
These are two different documents that are often confused. A website privacy policy (Privacy Notice) is an external document, intended for site visitors and users, explaining what data the organization collects about them, why, how, and for how long. It is the legal interface between the organization and the public. An internal privacy policy (Privacy Policy) is an internal document, intended for employees, describing how the organization handles personal data inside — what employees are allowed and not allowed to do with the data, what the breach procedure is, who the DPO is. Both are required under Amendment 13, but for different audiences and different purposes. Confusing the two — and especially publishing the internal policy on the website — is one of the most common mistakes we see.
Mandatory clauses under the Law (who collects, what, why, how long)
The statutory core is the notice duty in section 11 of the Privacy Protection Law, expanded by Amendment 13 (effective 2025): disclose the controller’s identity and contact details, the purposes of processing, whether there is a legal duty to provide the data, who it will be shared with, the data subject’s access and correction rights, and the DPO’s details where one is appointed. On top of that statutory core, best practice — aligned with GDPR — is to include: (1) Identity of the controller — full legal name of the organization, registration number, address, phone, contact email; (2) Types of data collected — by data category (contact details, behavioral data, location data, payment data); (3) Purposes of processing — for each data type, why we collect it; (4) Sources — directly from user, from public sources, from third-party vendors; (5) Recipients — to whom data is transferred (CRM vendors, mailing systems, payment processors, foreign subsidiaries); (6) Retention period — how long we retain, and on what basis; (7) Data subject rights — access, correction, deletion, objection; (8) DPO contact; (9) Last update date. Generating these clauses accurately starts with proper data mapping.
Additional clauses when GDPR applies
Precision matters: the mere fact that an Israeli site is accessible from Europe, or has a few European visitors, does not make it subject to GDPR. Under Article 3(2), GDPR applies to an Israeli organization only when it deliberately targets people in the EU — offering goods or services to the European market (EU language or currency, shipping to the EU, targeted marketing) — or monitors their behavior (profiling, targeting). When GDPR does apply in addition to Amendment 13, the policy must add: (1) Legal basis for each processing — consent, contract, legal obligation, legitimate interest; (2) Cross-border transfers — to which countries, on what legal basis (SCCs, adequacy decision); (3) Right of complaint — to the supervisory authority in the user’s EU member state; (4) EU representative if applicable; (5) Automated decision-making if relevant — explanation of logic and ability to challenge — high-risk profiling here typically requires a DPIA. For organizations heavily exposed to the European market, this is a critical layer. See the SaaS & startups sector page for additional context.
DPO contact in the policy
The Law requires the DPO’s contact details to be published accessibly to data subjects (section 17B3). Standard practice: a dedicated section in the privacy policy titled "Contacting the Data Protection Officer" with name, email (a dedicated DPO mailbox like dpo@company.com rather than a personal email), and phone. The DPO appointment must be properly documented internally — see DPO appointment letter. The Authority does verify, in random checks, that the email actually works and that there is a real person responding — not an unmonitored mailbox.
Data subject rights — access, correction, deletion
Under the Privacy Protection Law every data subject has the right to: (a) Access (section 13 of the Law) — request a copy of the data the organization holds about them, answered within 30 days per the Access Regulations, 1981; (b) Correction — request correction of inaccurate data; (c) Deletion — under defined conditions (no longer necessary, withdrawal of consent, illegal collection); (d) Objection — to processing for direct mailing or profiling; (e) Portability — under GDPR — receive data in a machine-readable format. The policy must explain the rights clearly and provide a working channel to exercise them. Many sites write "to exercise rights please contact us" without providing a concrete email — and this is a finding.
Informed consent and cookie policy
The website privacy policy and the cookie policy are two separate documents, even if they sometimes appear on the same page. The privacy policy covers data collection in general; the cookie policy covers specifically tracking technologies — cookies, pixels, fingerprinting. In an Israeli site marketing to European users, an explicit consent mechanism is required (cookie banner with granular opt-in) — not just notice. The cookie policy must include a list of all cookies in use, by category (necessary, functional, analytics, marketing), with details of vendor and retention period.
Updating the policy and versioning
A privacy policy is a living document. Every time the organization changes how it processes data — adds a new vendor, launches a new product, changes the retention period — the policy must be updated. Best practice: (1) Last update date at the top of the policy; (2) Versioning — keep an internal log of versions; (3) User notification upon material change — email or login banner; (4) Quarterly review alongside the security procedure. Major changes (new data type, new significant vendor) require explicit re-consent — not just publication.
Common pitfalls I see in clients
The five most common pitfalls: (1) Generic template translated from English that does not match the actual organization — referencing data types not collected, omitting types that are; (2) Buried under another menu — Amendment 13 requires the policy to be easily accessible, meaning a clear footer link on every page; (3) No update for years — last update date 2019, while in 2025 Amendment 13 came into effect and demands new disclosures; (4) Mixing with terms of use — these are two different legal documents and merging them creates legal mess; (5) Inconsistency with the database definition document — see database definition document. Anything in the database definition document that does not appear in the policy is a transparency failure under Amendment 13.
How we help
In our DPO as a Service retainer we deliver an Amendment 13 + GDPR compliant privacy policy as part of the initial onboarding package — usually within 3-4 weeks from start, after a brief mapping of databases and vendors. The policy is delivered in Hebrew and English, aligned with the database definition document, and updated quarterly as part of the retainer. For organizations that just want a one-off policy without ongoing service — we offer a 12,000-25,000 ILS project with one-year handoff and update.
Need a privacy policy that actually fits your organization?
30-minute call, draft within two weeks, signed final within a month.