DPIA Guide — Data Protection Impact Assessment

Precision matters: Israeli law contains no general, explicit DPIA obligation — even after Amendment 13. The Privacy Protection Authority recommends a DPIA as a core privacy risk-management tool, and in practice expects documented risk management for processing "with high risk to privacy": sensitive data processing at scale; systematic public-space monitoring; automated decisions with significant impact on individuals (including AI); third-party sharing at scale; new technologies. Sector-specific duties or special circumstances may still require one. Under GDPR, by contrast, a DPIA is a genuine obligation (Article 35) where it applies.

GDPR Article 35 imposes a genuine DPIA obligation, with a specific EDPB list. An Israeli organization subject to GDPR conducts a DPIA as a duty; in Israel the same assessment also satisfies the Authority’s recommendation — one document serves both frameworks. In both, the assessment happens before processing begins.

Six steps: (1) Scope definition — which project, which database, who are users; (2) Data flow mapping — from where, to where, to which vendor, cross-border? Foundation work covered in data mapping; (3) Risk identification — what can go wrong, at what probability and severity; (4) Mitigations — what controls can reduce; Privacy by Design (Pseudonymization, Minimization, Encryption, Access Control, short retention); (5) Residual risk — after everything, is risk acceptable? If not — Authority consultation; (6) Documentation and decision — formal report, signed, with update date.

A good DPIA report is 20-40 pages, containing: system and processing description; purpose and legal basis; data flow diagram; risk matrix; mitigations per risk; residual risk assessment; decision (proceed, modify, consult); stakeholder approval documentation; and update date.

When residual risk after mitigation is still high — the recommended step is consulting the Israeli Privacy Authority before processing begins (in Israel this is recommended practice, not a statutory duty; under GDPR it is an Article 36 obligation). The submission is drafted by the DPO, includes all documentation, and is filed through an online system. Authority typically responds within 8-12 weeks, sometimes asking for clarifications.

AI systems require an expanded DPIA. Beyond standard topics, a layer of questions: (a) Explainability — can the system explain decisions?; (b) Bias — is the model trained on representative data?; (c) Human in the loop — does every automated decision pass human review?; (d) Data transfer to foundation models (OpenAI, Claude, Gemini) — where processed, is it used for training; (e) Prompt and log retention period. SaaS-specific dynamics: see DPO for SaaS.

Public CCTV systems, employee monitoring, location apps, store behavior analytics — require DPIA. Questions: who are subjects? Is there signage? Proportionate purpose? Retention period? Controlled access? Automated actions (face recognition, plate recognition)? Every "yes" raises the risk level. Medical and clinical settings demand additional rigor — see DPO for healthcare. When a privacy incident actually fires during processing, the response is governed by incident response.

In an organization with internal DPO — they lead. Without internal DPO — external consultant (like us). In small organization — sometimes by "privacy team" including project manager, IT, legal. Criterion: performer’s independence from the specific project. Project owner cannot be the assessor.