Israel Protection of Privacy Law (5741-1981)

Regulation 11 requires the database owner to document every security event and to notify the Privacy Protection Authority immediately of a severe security event. The PPA may also direct the owner to notify affected data subjects. A severe security event is one that materially compromises confidentiality, integrity, or availability of personal data. Industry practice and PPA guidance treat 'immediately' as within 24 hours of discovery for severe events.

• Incident response plan defining severe security event
• Severity triage matrix
• PPA notification template and submitted reports
• Subject notification log where directed by PPA
• Post-incident review and lessons learned

• No definition of severe event
• PPA notification missed or late
• Subject notification only after PPA prompt

The Privacy Protection (Data Security) Regulations 5777-2017 classify databases into three security tiers (basic, medium, high) plus a managed-by-individual exemption. Classification depends on the number of subjects, the number of authorised users, sensitivity of the data, and whether the database is used for direct mailing or by a public body. Tier classification determines the depth of mandatory controls.

• Per-database security tier classification record
• Decision memo with subject count, user count, sensitivity, purpose
• Annual revalidation of classification
• Process to reclassify on material change
• Mapping of controls applied per tier

• Defaulting all databases to basic tier
• No recalculation when subject count crosses threshold
• Sensitive data databases classified too low

Regulation 14 requires that medium and high tier database systems be segregated from public networks and protected by appropriate boundary controls. Communication of personal data over public networks must use encryption. Remote access must be via secured channels with MFA. Wireless networks must be encrypted and segregated from the database environment.

• Network diagram showing segregation of database zone
• TLS configuration evidence for all external interfaces
• VPN MFA configuration
• Wireless segregation and encryption settings
• Firewall ruleset review evidence

• Database directly exposed to internet
• Cleartext protocols still in use
• Guest wifi reaching database segment

Regulation 2 requires every database owner to maintain a database definition document covering purposes of the database, types of data, types of subjects, recipients of data and purposes of transfer, transfers abroad, data flows in and out, processors used, and primary security risks. The document must be reviewed at least annually and updated on material change. For high-tier databases additional content is required.

• Database definition document per database with all regulation 2 elements
• Approval signatures by database manager
• Annual review log with date and outcome
• Change history with version numbers
• Cross-reference to data flow diagram

• Definition document missing
• Outdated document not reviewed in last 12 months
• Processor list incomplete
• Transfers abroad not documented

Regulation 4 requires that changes to systems holding personal data are managed through documented change control. Development environments must be separated from production. Test data should not be real personal data unless protective measures are applied. Significant system changes must be reflected in the definition document and risk assessment.

• Change management policy and ticket evidence
• Environment separation diagram
• Test data masking or synthetic data policy
• Definition document update on major changes
• Code review and SAST evidence for high tier

• Production data used in test without masking
• No environment separation
• Definition document not updated after change

Regulation 11 also requires the database owner to maintain an internal register of every security event, severe or not. The register must record the event, its handling, and corrective measures. The database manager must review the register periodically and trends must inform the risk assessment and definition document.

• Security event register covering all events
• Quarterly review minutes by database manager
• Trend report feeding annual risk assessment
• Linkage to corrective action tracker

• Only severe events logged
• No periodic manager review
• No feedback into risk assessment

Regulation 13 addresses portable computing devices and removable media used to process or store personal data. Such devices must be authorised, encrypted, inventoried, and protected against loss. Use of personal devices for database access must be approved and controlled. Loss of devices containing personal data must be reported and investigated as a security event.

• Portable device inventory linked to user
• Full disk encryption proof on laptops and mobiles
• BYOD policy with consent and MDM enrolment
• Lost device incident log
• Removable media authorisation register

• Unencrypted laptops with database access
• BYOD without MDM
• Lost device incidents not treated as security events

Regulation 3 requires appointment of an information security officer where the database owner has five or more databases requiring registration, or where the owner is a public body, a bank, an insurer, or holds a large or high-tier database. The officer must have appropriate knowledge and resources, report to senior management, and not have conflicting operational duties.

• Officer appointment letter and CV
• Reporting line to executive or board
• Annual report from officer to management
• Budget and resource allocation evidence
• Conflict of interest declaration

• Officer combined with operational IT role creating conflict
• No annual report to management
• Triggers met but no officer appointed

Regulation 7 requires physical security for database systems and media commensurate with tier. Servers must be in access-controlled rooms with monitoring. Removable media and printed outputs containing personal data must be tracked, secured, and disposed of securely. Backup media must be stored separately from primary systems.

• Data centre access policy and visitor logs
• Server room CCTV retention proof
• Media inventory and destruction certificates
• Backup offsite location and access controls
• Clean desk and clear screen evidence

• No tracking of removable media
• Backups stored adjacent to primary site
• Destruction without certificate

Regulation 15 governs use of an outsourced data holder. The owner must select a processor with adequate security, sign a written contract specifying purposes, types of data, security obligations, subject rights handling, return or destruction of data, audit rights, and breach notification. The contract must require the processor to comply with the regulations. The owner must supervise the processor including risk-based reviews.

• Pre-engagement due diligence questionnaire
• Signed processor contracts with reg.15 clauses
• Sub-processor register and approvals
• Annual processor audit or assurance report (SOC 2, ISO 27001)
• Termination return or destruction certificates

• Processor contracts missing security clauses
• No periodic processor audit
• Sub-processors used without approval

When systems are decommissioned or media replaced, residual personal data must be securely erased. Regulation 7 requires that disposal methods render data irrecoverable. Decommissioning of databases must be reflected in the database register and the definition document withdrawn or archived. The PPA must be notified of dissolution of a registered database.

• Decommissioning procedure with erasure standards
• Certificates of destruction or secure wipe logs
• PPA notification of database dissolution
• Updated internal register
• Archived definition document

• Decommissioned hardware sold without wipe
• PPA not informed of database dissolution
• Definition document remains live for dissolved database

Although the PPL does not impose a single retention period, the use-limitation principle (s.2 and s.8(b)) requires that information be kept only as long as necessary for the registered purpose. The Data Security Regulations require secure disposal of media and data when no longer needed. Retention schedules should be defined per database and aligned to the definition document.

• Retention schedule per database aligned to purpose
• Disposal procedure for electronic and paper media
• Disposal certificates from approved vendors
• Quarterly purge job evidence
• Linkage to definition document

• Indefinite retention by default
• No disposal certificates
• Purge jobs not scheduled or evidenced

Regulations 5 and 6 require medium and high-tier database owners to conduct a risk assessment at least every 18 months identifying threats to confidentiality, integrity, and availability. High-tier databases must also undergo penetration testing at least every 18 months. Findings must be reported to the database manager and remediated under a tracked plan.

• Risk assessment report dated within 18 months
• Penetration test report for high-tier databases
• Remediation plan with owners and dates
• Status report to database manager
• Evidence of independence of assessor

• Risk assessment older than 18 months
• Penetration test scope excludes the database
• Findings open without remediation tracking
• No independence of internal assessor documented

Where databases are hosted in cloud or with third-party infrastructure providers, the database owner remains accountable under PPL and DSR. Personal data at rest should be encrypted, key management documented, and the cloud provider treated as an outsourced holder under regulation 15. Cross-border hosting must also satisfy the Transfer Regulations.

• Cloud provider DPA covering reg.15 requirements
• Encryption at rest configuration evidence
• KMS key management policy
• Hosting region documented and aligned to transfer basis
• Annual cloud assurance review (SOC 2 / ISO 27001)

• Database hosted in non-adequate region without contractual safeguards
• Unencrypted object storage
• Customer-managed keys not used for sensitive databases

Section 36 of POPL 5741-1981 plus the Privacy Protection (Transfer of Data to Databases Abroad) Regulations 5761-2001 govern cross-border transfers of personal data. (1) Section 36 - Transfer Abroad: personal data may be transferred to a database outside Israel only with permission of the Minister of Justice OR per the 2001 Regulations conditions. (2) Privacy Protection (Transfer of Data to Databases Abroad) Regulations 2001: permitted transfer mechanisms include (a) Transfer to country with equivalent or higher level of protection - Adequacy approach - similar to GDPR Chapter V Article 45; (b) Data subject consent for transfer; (c) Transfer essential for performance of contract between controller and data subject; (d) Transfer based on agreement between controller and foreign recipient where foreign recipient agrees to comply with conditions equivalent to POPL - Standard Contractual Cla

• Section 36 + 2001 Regulations compliance + mechanism per transfer + records
• EU Adequacy + reciprocity + records + cross-border data flow map
• Israeli SCCs + foreign recipient agreement + records + audit
• Cloud transfer + hyperscaler + data residency option + records + customer agreement
• Cross-sectoral + Bank/Medical/National Security + records + sector compliance

• Transfer without lawful mechanism (Section 36 violation)
• EU Adequacy assumed reciprocally without review
• SCCs not in place for non-adequate countries
• Cloud workload offshore without data residency option assessed
• Sector restrictions ignored (e.g. financial data cross-border without Bank of Israel approval)

The Privacy Protection (Data Security) Regulations 5777-2017 (Takhanot Hagannat Hapratiyot - Avtahat Meidah) supplement the 1981 Law with detailed technical and organisational security requirements + graduated by Security Level Classification (Basic/Medium/High). (1) Information Security Officer (ISO/CISO) per Article 3: every controller with medium or high security level database must appoint an ISO Information Security Officer (Mamuneh Avtahat Meidah) responsible for (a) developing + maintaining + implementing the information security policy; (b) advising on database security risks; (c) periodic reporting to management; (d) liaising with PPA on security matters; (e) coordinating incident response; reports to senior management + sufficient independence + qualifications and training appropriate. (2) Information Security Policy + Procedures per Article 4: documented + approved by manageme

• ISO/CISO appointment + medium/high security level databases + records + qualifications
• Information security policy + annual review + management approval + records
• Access control + RBAC + MFA + password complexity + privileged access + records
• Logging + 24-month retention + tamper-evident + SIEM integration + records + reviews
• Risk assessment + annual penetration test (high security) + internal audit + records

• No ISO/CISO appointed (medium/high security database non-compliant)
• Information security policy outdated (not reviewed annually)
• Access control flat (no RBAC or MFA)
• Logging incomplete or retention <24 months
• Penetration testing absent for high-security databases

Sections 13-14 and 23A-23C of POPL 5741-1981 establish data subject rights with Amendment 13 enhancements. (1) Section 13 Right of Inspection/Access: every person who has been registered in a database has the right to inspect any information about themselves in the database + at reasonable times + free of charge + every 12 months (subsequent requests in same year may incur reasonable fee) + database controller must respond within 30 days + may decline if (a) controller establishes that responding would violate other lawful interests including third party rights; (b) information is held for legitimate purposes related to State security or public safety; (c) other limited exceptions per regulations. (2) Section 14 Right of Correction: data subject has the right to request correction of inaccurate or incomplete information + controller must (a) correct + or (b) decline with written justific

• Right of access portal + 30-day SLA + annual free + records + statistics
• Right of correction procedure + justified decline + court petition pathway + records
• Information delivery to third party + lawful basis + consent + records
• Notice templates + 6 elements + records + version control
• Right to object + direct marketing opt-out + records + statistics

• Access portal absent (data subjects cannot exercise rights)
• Correction declined without justification (Section 14 violation)
• Information delivered to third party without lawful basis
• Notice missing elements (Section 11 incomplete)
• Direct marketing opt-out not honoured

Per Sections 7-8 of POPL 5741-1981 + Privacy Protection (Data Security) Regulations 5777-2017 - Israel maintains a unique requirement (distinct from GDPR) of mandatory database registration with the Privacy Protection Authority (PPA) for certain categories of databases. Database (Maagar Meidah) per Section 7: a collection of data + maintained by magnetic or optical means + intended for computer processing - excludes (a) personal collection unrelated to business; (b) public access collection (where information is lawfully publicly disclosed). (1) Database Definition Document (Mismach Hagdarat Maagar) per Article 2 of Data Security Regulations: every controller (Baal Maagar) must prepare a written Database Definition Document covering (a) database name + purpose; (b) categories of data subjects + categories of personal information; (c) database security level classification (basic + medium

• Database inventory + identification + classification per Sec 7 + records + annual review
• Database Definition Document + per database + Article 2 elements + records + version control
• Security level classification + Basic/Medium/High + per database + records
• PPA registration + mandatory categories + records + updates + public registry verification
• Amendment 13 thresholds + reduced burden + records + simplified registration where applicable

• Database inventory absent (no clear identification of databases)
• Database Definition Document missing (Article 2 not complied with)
• Security level not classified (graduated obligations not applied)
• Mandatory PPA registration missed (Section 8 violation)
• Amendment 13 reduced thresholds not leveraged (over-registration)

Enforcement of POPL 5741-1981 is multi-pronged: civil + criminal + administrative + via the Privacy Protection Authority (PPA) under the Ministry of Justice + with significant enhancement under Amendment 13. (1) Privacy Protection Authority (PPA - HaRashut LeHagannat HaPrativut): government regulatory authority + investigatory powers + audit rights + administrative enforcement + guidance issuance + Database Registry administration + complaint handling + cross-border cooperation. PPA Chairperson appointed by Minister of Justice + serves 5-year term + reports to Knesset Constitution Law and Justice Committee. (2) Civil Remedies per Section 29: data subject may file civil suit for damages caused by privacy infringement + court may award (a) actual damages; (b) damages without proof of harm up to NIS 50000 statutory; (c) increased damages for malicious infringement; (d) injunction to cease i

• PPA engagement + database registry + records + cooperation + audit history
• Civil suit risk + Section 29 + NIS 50K + records + insurance coverage
• Criminal risk + Section 5 + imprisonment + Director/Officer + Board records
• Amendment 13 administrative + NIS 5M + Board awareness + records
• International coordination + GDPR Adequacy + Convention 108 + bilateral + records

• No PPA engagement (operating below regulatory radar)
• Civil suit risk unmanaged (no insurance coverage)
• Criminal liability not assessed (Board exposure not understood)
• Administrative fines NIS 5M not Board-level (Amendment 13 not internalised)
• International coordination absent (Israel-only view despite EU adequacy)

Incident response and breach notification governed by Section 32A POPL + Article 11 of Data Security Regulations 5777-2017 + Amendment 13 reinforcement. (1) Section 32A Severe Security Incident: controller must notify the Privacy Protection Authority of a severe security incident defined as an incident that (a) raises a real concern of compromise to information integrity; (b) involves transmission of information without authorisation; (c) involves use of information without authorisation; (d) affects substantial number of data subjects or sensitive data. (2) Article 11 Data Security Regulations 2017 - Notification Timelines: (a) PPA notification - severity-based + typically within 24-72 hours of becoming aware of severe incident; (b) Data subjects affected - notification where there is a real risk of substantial harm + content includes (i) description of incident; (ii) categories of data

• Section 32A + Article 11 notification capability + 24-72 hour + records + drills
• Data subject notification + real risk + content + records + statistics
• IR plan + phases + tabletop + INCD + IL-CERT + records
• Forensics + chain of custody + law enforcement + records + insurer
• Multi-jurisdictional reporting + GDPR + US state + UK ICO + records + matrix

• PPA notification missed (24-72 hour window)
• Data subject notification deferred (real risk underestimated)
• IR plan paper-only (no tabletop or INCD coord)
• Forensics not preserved (chain of custody broken)
• Multi-jurisdictional reporting fragmented (Israel-only)

POPL 5741-1981 plus Data Security Regulations 2017 plus Section 17F + Section 23E address outsourcing + direct marketing + personnel security. (1) Data Holder (Mahzik Maagar Meidah): per Section 7 - any person not the controller (Baal Maagar) who holds or processes personal information on behalf of the controller + subject to direct obligations under POPL + must implement security measures + must operate per controller instructions + must not use for own purposes. (2) Outsourcing per Article 15 Data Security Regulations 2017: controller engaging data processor must (a) ensure data holder implements equivalent security measures; (b) execute written contract specifying security obligations; (c) specify scope and purpose of processing; (d) require notification of subcontractors; (e) retain audit rights; (f) require data return/destruction at end of contract; (g) limit cross-border transfer

• Data holder contracts + Article 15 + written + security equivalent + records + audit
• Section 17F direct marketing + opt-out + do-not-contact + verification + records
• Article 12 employee training + vetting + NDA + records + annual refresher
• Subcontractor flow-down + controller approval + records + audit
• Cross-sector outsourcing + Bank/Medical + records + sector compliance

• Data holder contract missing or generic (no Israel POPL specifics)
• Direct marketing opt-out not honoured
• Employee training one-off (no annual refresher)
• Subcontractor flow-down absent (no controller approval)
• Sector outsourcing restrictions overlooked (Bank/Medical)

Section 8B and related provisions of POPL 5741-1981 establish purpose limitation + lawful processing principles. (1) Section 8B Use Limitations: personal information in a database may be used only for purposes for which it was collected and registered + or for compatible purposes notified to data subjects. Any use beyond the registered purpose requires (a) additional consent; (b) statutory authorisation; (c) compatible purpose extension per regulations. (2) Section 11 Notice Requirement: at time of collection + controller must inform data subject of (a) whether providing data is voluntary or required; (b) purpose for collection; (c) categories of recipients; (d) rights including access and correction. Failure to provide proper notice can void consent + invalidate lawful basis. (3) Lawful Processing Bases (similar to GDPR but distinct framing): (a) Consent - free + specific + informed - t

• Use limitations + registered purpose mapping + compatibility test + records
• Section 11 notice templates + 4 elements + voluntary vs required + records + version control
• Lawful basis matrix + per activity + records + records
• Data minimisation + storage limitation + retention schedule + destruction + records
• Sensitive data + children + genetic + biometric + elevated consent + records + DPIA

• Use beyond registered purpose without additional consent
• Notice missing voluntary/required disclosure (Section 11 incomplete)
• Lawful basis only consent claimed (no other basis assessed)
• Data minimisation ignored (excessive collection or indefinite retention)
• Sensitive data treated as general (no elevated consent or DPIA)

Israeli Protection of Privacy Law 5741-1981 (Hok Hagannat Hapratiyot) enacted by Knesset Israeli Parliament 1981 (5741 in Hebrew calendar) + significant subsequent amendments including Amendment No. 13 of March 2024 modernising the privacy framework towards GDPR-equivalent + Amendment No. 14 contemplated 2025. Constitutional Anchor: Basic Law Human Dignity and Liberty (1992) Section 7 establishes the right to privacy as a constitutional right protected against unauthorised infringement + integrated into Israeli judicial review per High Court of Justice (HCJ) jurisprudence. Israeli law treats privacy as derived from human dignity rather than autonomy alone (distinct from European/American approaches). The 1981 Law remains the primary statute + Amendment 13 (March 2024) modernised key provisions including (a) database registration thresholds raised (less burdensome registration for small d

• Israeli data processing assessment + scope + records + extraterritorial assessment
• 5741-1981 + Amendment 13 compliance + records + gap analysis + roadmap
• Basic Law Human Dignity + constitutional privacy awareness + records + training
• Chapter 1 sections mapped + Sec 1/2/5 + records + lawful basis assessment
• PPA engagement + Knesset monitoring + records + amendment tracking

• Israeli scope not assessed (data of Israeli residents handled without compliance)
• Amendment 13 March 2024 not implemented (operating per pre-2024 framework)
• Constitutional basis not understood (treating as compliance overhead)
• Chapter 1 lawful basis assumed without Sec 2 analysis
• No PPA engagement (operating below regulatory radar)

Section 11 requires that when requesting information from a data subject, the requester must notify the subject whether they are legally obliged to provide the information or whether provision depends on their will and consent, the purpose for which the information is requested, and to whom the information will be transferred and for what purpose. Consent must be informed and may be express or implied depending on context.

• Privacy notices at collection points in Hebrew and English
• Consent capture logs with timestamps and version
• Sample forms showing s.11 disclosures
• Purpose statements per collection channel
• Evidence of distinction between mandatory and voluntary fields

• Generic notices missing purpose or transfer disclosures
• No record of consent version subject saw
• Mandatory vs voluntary fields not marked

Section 13 grants every person the right to inspect information concerning them held in a database. The database owner must respond within 30 days and provide the information in Hebrew, Arabic, or English at the subject's choice. Refusal must cite a permitted ground (s.13(d) and (e)) and be appealable to a court. The subject may inspect personally or via an authorised representative.

• DSAR intake procedure with 30-day SLA
• Access request register with received and response dates
• Sample fulfilled access responses
• Refusal letters citing s.13 ground
• Identity verification procedure
• Language option workflow

• Missing 30-day SLA tracking
• No identity verification process
• Refusals without statutory ground cited
• Failure to offer Hebrew, Arabic, or English

Section 14 provides the right to request correction or deletion of information that is incorrect, incomplete, unclear, or out of date. The database owner must act on the request and notify the subject of the decision within 30 days. If the request is refused, the owner must inform the subject of the right to appeal to court. Any third party who received the data within the prior three years must be informed of the correction.

• Correction and deletion procedure
• Request register with disposition
• Downstream third-party notification log
• Sample correction confirmations
• Refusal letters citing reason and appeal right

• No downstream notification to recipients of corrected data
• Deletion not propagated to backups within reasonable timeframe
• Refusals without court appeal notice

Section 16 imposes a duty of confidentiality on any person who in the course of their duties comes into possession of information in a database. Information may only be used for the purpose for which it was collected. Disclosure outside permitted purposes or to unauthorised persons is a criminal offence. The duty survives termination of employment or engagement.

• Signed confidentiality undertakings by all staff and contractors with database access
• Clauses in employment and processor contracts referencing s.16
• Training records on use limitation
• Access logs showing purpose-bound use
• Disciplinary records for misuse

• No signed confidentiality undertakings
• Contractor agreements missing s.16 language
• Secondary use without re-consent or legal basis

Section 17 requires the database owner, holder, and manager to ensure that the database has appropriate security. Each database must have a designated database manager (responsible for compliance) and a database holder where the data is held by a third party. Larger databases must appoint a security officer. The Data Security Regulations 2017 operationalise this duty in detail.

• Database manager appointment letters per database
• Security officer appointment letter where required
• RACI for owner, holder, manager, officer roles
• Job descriptions including PPL duties
• Annual confirmation of role coverage

• No designated database manager
• Security officer required but not appointed
• Holder role not assigned for outsourced databases

Section 17F regulates direct mailing services where personal data is used to address individuals. Each communication must identify the database, the sender, and the right of the recipient to be deleted from the database. The recipient may demand deletion in writing and the operator must comply without delay. A database used for direct mailing is registrable under s.8 and direct mailing service operators have separate registration obligations.

• Direct mailing database registration with PPA
• Sample direct mail showing required disclosures
• Opt-out suppression list and propagation log
• Source-of-data identifier per record
• Quarterly suppression hygiene audit

• Communications without source database identification
• Opt-out not honoured across all systems
• Direct mailing database unregistered

Section 2 of the Privacy Protection Law defines 'information' broadly as data on personality, personal status, intimate affairs, health, economic status, professional qualifications, opinions and beliefs. 'Sensitive information' (information bearing higher protection) includes data on personality, intimate affairs, health, economic status, opinions, and beliefs. Scope determines registration thresholds and security tier classification.

• Data classification matrix mapping fields to PPL categories
• Database inventory marking sensitive vs ordinary information
• Field-level tagging in source systems
• Data discovery scan results
• Annual classification review record

• Failure to flag health or financial data as sensitive
• No distinction between personal and sensitive triggering wrong security tier
• Free-text fields with embedded sensitive data unclassified

Sections 23 to 23C regulate sharing of information between public bodies and from public bodies to private entities. Sharing requires legal basis (statute, consent, or specific exception), purpose limitation, and documentation. Public bodies must publish their databases and the purposes of sharing. Private sector recipients of public-sector data inherit obligations not to use the data beyond the disclosed purpose.

• Inter-body sharing agreements
• Legal basis memos per sharing arrangement
• Recipient acknowledgement of purpose limitation
• Public register of databases (for public bodies)
• Annual review of sharing arrangements

• Sharing on basis of habit rather than documented authority
• Recipient use beyond original purpose
• No public register

The PPL provides civil liability under s.4 for infringements of privacy with statutory damages up to NIS 50,000 per subject without proof of damage (and up to NIS 100,000 where intent shown). Criminal offences under s.5 and chapter D include operating an unregistered database, using information for unauthorised purposes, and disclosure in breach of duty, punishable by imprisonment up to one year and fines. The PPA also has administrative fining powers under various regulations.

• Legal register noting penalty exposure per scenario
• Cyber liability insurance covering PPL claims
• Board reporting of enforcement risk
• Tracking of PPA enforcement decisions affecting sector

• No board-level awareness of PPL penalty regime
• Insurance excludes regulatory fines without statement of insurability under Israeli law

Section 8 requires registration of databases with the Database Registrar at the Privacy Protection Authority where the database meets thresholds. Registration triggers include databases with more than 10,000 subjects, databases containing sensitive information, databases including data on persons whose consent was not obtained, databases owned by public bodies, and databases used for direct mailing services. Operating an unregistered database that requires registration is a criminal offence.

• Registration application forms submitted to PPA
• Registrar certificate or acknowledgement letter
• Database register internal log with registration numbers
• Analysis memo per database confirming whether registration is required
• Annual review of registered database scope

• Operating databases above 10K subjects without registration
• Failing to update registration when purpose or content changes
• No internal owner tracking registration status

The Privacy Protection Authority is empowered to inspect databases, request information, and issue orders under the PPL and the Data Security Regulations. Database owners must cooperate, provide access to information and personnel, and produce the definition document, risk assessment, audit report, and security event register on request. Obstruction is an offence.

• PPA engagement playbook
• Master document index for PPA requests (definition doc, risk assessment, audit, event register, training, access reviews)
• Designated PPA liaison contact
• Log of past PPA correspondence and outcomes

• No single owner for PPA correspondence
• Documents scattered and not readily produced
• Lessons from prior PPA contact not captured

The Privacy Protection (Transfer of Data to Databases Abroad) Regulations 5761-2001, Regulation 2, prohibit transfer of personal data from Israel except where the destination country provides protection at a level not lower than the Israeli law, or where one of the listed exceptions applies (subject consent, contractual necessity, transfers to EEA, transfers to recipients in countries on the PPA approved list, or where the recipient undertakes equivalent protections by contract). The transferor remains responsible for downstream compliance.

• Cross-border transfer register with destination, basis, and data categories
• Adequacy evidence (EEA listing, PPA approved list)
• Inter-company data transfer agreements with PPL clauses
• Consent records where used
• Downstream onward transfer controls

• Undocumented transfers to non-adequate jurisdictions
• Generic DPAs without PPL-specific clauses
• Onward transfer controls absent