מהו Article 35 של GDPR? ומתי DPIA הופך לחובה

Article 35 הוא הסעיף ב-GDPR העוסק ב-Data Protection Impact Assessment – DPIA, או תסקיר השפעה על הגנת הפרטיות.

הסעיף קובע שכאשר סוג מסוים של עיבוד מידע, בהתחשב ב-Nature, Scope, Context and Purposes שלו ובמיוחד כאשר נעשה שימוש בטכנולוגיות חדשות, צפוי לגרום ל-High Risk לזכויות ולחירויות של אנשים, על ה-Data Controller לבצע DPIA לפני תחילת העיבוד.

המילה החשובה כאן היא "לפני".

Article 35 אינו בנוי כמנגנון לבדיקת נזק שכבר התרחש, אלא ככלי שמטרתו לזהות מראש סיכוני פרטיות ולהשפיע על הדרך שבה המערכת, המוצר או התהליך מתוכננים.

במובן הזה, Article 35 הוא אחד הביטויים הפרקטיים ביותר לעקרונות של Privacy by Design וניהול סיכונים מבוסס פרטיות.

מה המשמעות של High Risk?

Article 35 אינו אומר שכל עיבוד מידע אישי מחייב DPIA.

נקודת המבחן היא האם הפעילות Likely to Result in a High Risk לזכויות ולחירויות של נושאי המידע.

הערכת הסיכון אינה עוסקת רק בשאלה האם מידע עלול לדלוף.

הסיכון עשוי לכלול גם:

• פגיעה בפרטיות
• אפליה
• אובדן שליטה על מידע אישי
• פגיעה בזכויות
• נזק כלכלי
• נזק תדמיתי
• חשיפה של מידע רגיש
• החלטות אוטומטיות שמשפיעות משמעותית על אדם
• מעקב או ניטור נרחבים

בבחינת High Risk צריך להתחשב הן בסבירות להתרחשות הנזק והן בחומרתו. עצם קיומם של סימני סיכון משמעותיים יכול להספיק כדי להצדיק ביצוע DPIA מפורט יותר.

שלושה מקרים מרכזיים שמופיעים במפורש ב-Article 35

Article 35(3) מצביע על שלושה סוגי פעילות מרכזיים שבהם DPIA נדרש.

1. Profiling וקבלת החלטות אוטומטית

כאשר הארגון מבצע הערכה שיטתית ונרחבת של היבטים אישיים באמצעות Automated Processing, לרבות Profiling, ומשתמש בתוצאות כדי לקבל החלטות בעלות השפעה משפטית או השפעה משמעותית דומה על האדם.

לדוגמה:

• מערכת שמדרגת מועמדים לעבודה
• מערכת שמחליטה על זכאות לאשראי
• מערכת Fraud Detection שמקבלת החלטות אוטומטיות
• מנוע AI שמבצע Profiling ומשפיע על שירות שהאדם יקבל.

Article 35 מתייחס במפורש לתרחישים כאלה כחלק מהמקרים המחייבים תשומת לב מיוחדת.

2. עיבוד בהיקף גדול של מידע רגיש

המקרה השני הוא Large Scale Processing של Special Categories of Personal Data לפי Article 9, או מידע על הרשעות ועבירות לפי Article 10.

מדובר בין היתר במידע כמו:

• מידע רפואי
• מידע גנטי
• מידע ביומטרי לצורך זיהוי
• מידע על אמונות או השקפות מסוימות
• מידע רגיש נוסף המוגדר ב-GDPR

כאשר מידע כזה מעובד בהיקפים משמעותיים, רמת ההשפעה האפשרית על נושאי המידע עולה בהתאם.

3. ניטור שיטתי של מרחב ציבורי בהיקף גדול

Article 35 מתייחס גם ל-Systematic Monitoring של אזורים הנגישים לציבור כאשר הניטור מתבצע ב-Large Scale.

דוגמאות עשויות לכלול:

• מערכי מצלמות
• Video Analytics
• Facial Recognition
• מעקב אחר תנועה
• מערכות ניטור אחרות

החשיבות של DPIA בתרחישים כאלה גבוהה במיוחד משום שהאדם לא תמיד יכול לבחור אם להיות חלק מתהליך איסוף המידע.

צרכים ייעוץ בתחום הגנת הפרטיות ו -GDPR Article 35 – דברו עם המומחים שלנו

Article 35 אינו מוגבל לשלושת התרחישים האלה

זו נקודה חשובה.

שלושת המצבים המפורטים ב-Article 35(3) אינם רשימה סגורה.

הכלל הרחב נשאר זה של Article 35(1):

אם סוג העיבוד עשוי להביא ל-High Risk, ייתכן שנדרש DPIA.

בנוסף, Article 35(4) מחייב רשויות פיקוח לפרסם רשימות של סוגי פעילויות עיבוד שעבורם נדרש DPIA. ה-EDPB מציין במפורש כי רשויות הגנת המידע במדינות השונות מפרסמות רשימות כאלה, והן מסייעות לארגונים לקבוע האם חלה עליהם החובה.

לכן ארגון שפועל באירופה לא צריך להסתפק רק בקריאת Article 35 עצמו.

צריך לבדוק גם:

איזה Regulator רלוונטי, באיזו מדינה מתבצעת הפעילות והאם קיימת רשימת DPIA מחייבת של הרשות המקומית.

איך יודעים אם צריך DPIA?

Guidelines שאומצו על ידי ה-EDPB מספקים קריטריונים נוספים המסייעים לזהות Processing שעלול להיחשב High Risk.

בפועל, כדאי לבדוק האם הפעילות כוללת אחד או יותר מהמאפיינים הבאים:

• Evaluation או Scoring של אנשים
• Automated Decision Making
• Systematic Monitoring
• עיבוד Sensitive Data
• עיבוד בהיקף גדול
• הצלבה של מספר Data Sets
• עיבוד מידע של אוכלוסיות פגיעות
• שימוש חדשני בטכנולוגיה
• פעילות שעלולה למנוע מאדם גישה לשירות או לממש זכות

ככל שמצטברים יותר מאפיינים כאלה, כך מתחזק הצורך לבחון DPIA.

צרכים ייעוץ בתחום הגנת הפרטיות ו-GDPR Article 35 – דברו עם המומחים שלנו

Article 35 וטכנולוגיות חדשות

Article 35 מתייחס במפורש לשימוש ב-New Technologies כאחד הגורמים שצריך לקחת בחשבון.

הסיבה ברורה.

כאשר הארגון מטמיע טכנולוגיה חדשה, קשה יותר להסתמך על ניסיון קיים כדי להבין את מלוא ההשלכות על הפרטיות.

וזה הופך היום את Article 35 לרלוונטי במיוחד לעולמות כמו:

• AI
• Generative AI
• Facial Recognition
• Biometrics
• IoT
• IoMT
• Behavior Analytics
• Employee Monitoring
• Location Tracking
• Automated Decision Making

אבל חשוב לדייק:

עצם השימוש בטכנולוגיה חדשה אינו בהכרח אומר שחייבים DPIA.

השאלה היא האם השימוש בה, בהתחשב בהיקף, במטרה, בסוג המידע ובפגיעה האפשרית, צפוי ליצור High Risk.

Article 35 ו-AI – חיבור שהולך ונעשה חשוב יותר

אחד היישומים המעניינים ביותר כיום של Article 35 הוא בהטמעת AI.

נניח שארגון רוצה להפעיל מערכת AI שמנתחת התנהגות עובדים.

לפני ההטמעה כדאי לשאול 8 שאלות מרכזיות:

1. איזה מידע מוזן למערכת?
2. האם מדובר במידע אישי?
3. האם המערכת מבצעת Profiling?
4. האם היא מייצרת Scoring?
5. האם התוצאה שלה משפיעה על קידום, פיטורים או תנאי העסקה?
6. האם קיימת Human Review?
7. האם העובד יודע שהניתוח מתבצע?
8. ומה הסיכון אם האלגוריתם טועה?

בתרחיש כזה DPIA אינו רק דרישה רגולטורית אפשרית.

הוא גם כלי חשוב של AI Governance.

מה Article 35 דורש לכלול בתוך DPIA?

Article 35 אינו מסתפק בדרישה "לבצע הערכה".

הוא מגדיר רכיבים שצריכים להיכלל בתהליך.

בין היתר:

תיאור שיטתי של פעולות העיבוד

צריך להבין ולתעד:

1. מהו העיבוד,
2. איזה מידע מעורב,
3. מי נושאי המידע,
4. מי מקבל גישה,
5. לאיזו מטרה מתבצע העיבוד.

בחינת Necessity ו-Proportionality

הארגון צריך לבחון האם העיבוד באמת נחוץ להשגת המטרה.

לדוגמה:

• האם ניתן להשיג את אותה מטרה עם פחות מידע?
• האם נדרשת שמירה למשך חמש שנים?
• האם באמת חייבים לזהות את האדם?

הערכת הסיכונים

יש לזהות סיכונים לזכויות ולחירויות של נושאי המידע.

לא רק Cyber Risk, גם Privacy Risk.

אמצעים לצמצום הסיכון

ה-DPIA צריך להתייחס ל-Safeguards, Security Measures ומנגנונים נוספים שנועדו להתמודד עם הסיכונים שזוהו.

ה-EDPB מתאר DPIA כתהליך שצריך לתאר את העיבוד, לבחון האם הוא נחוץ ומתאים, ולהגדיר כיצד מפחיתים את הסיכונים לנושאי המידע.

מה תפקיד ה-DPO לפי Article 35?

Article 35 קובע שכאשר בארגון קיים DPO – Data Protection Officer, על ה-Controller לפנות אליו לקבלת ייעוץ במסגרת ביצוע ה-DPIA.

זו נקודה משמעותית – ה-DPO אינו רק מי שמקבל את המסמך בסוף.

הוא צריך להיות חלק מהתהליך ולהביא לתוכו את נקודת המבט של Privacy ו-Data Protection.

למשל:

• האם בכלל נדרש DPIA?
• האם זוהו הסיכונים הנכונים?
• האם אמצעי ההפחתה מספיקים?
• האם התהליך תואם את דרישות ה-GDPR?

כך מתחבר Article 35 באופן טבעי גם לתפקיד ה-DPO ולמערך Privacy Governance רחב יותר.

ומה קורה אם הסיכון נשאר גבוה?

זו אחת הנקודות החשובות ביותר בתהליך.

נניח שהארגון ביצע DPIA, זוהו מספר סיכונים והוגדרו בקרות.

אבל גם לאחר הפעלתן נשאר Residual High Risk.

במצב כזה לא תמיד ניתן פשוט לתעד את הסיכון ולהמשיך.

Article 36 של GDPR עוסק ב-Prior Consultation ומחייב במקרים הרלוונטיים לפנות לרשות הפיקוח לפני תחילת העיבוד אם הסיכון הגבוה לא צומצם באופן מספק.

ה-EDPB מדגיש כי כאשר לא ניתן להפחית את הסיכון באמצעות אמצעים מתאימים, על ה-Controller להתייעץ עם רשות הגנת המידע לפני ההמשך.

כלומר:

DPIA אינו רק Risk Assessment. הוא יכול לעצור או לשנות פרויקט.

צרכים ייעוץ בתחום הגנת הפרטיות ו -GDPR Article 35 – דברו עם המומחים שלנו

Article 35 ו-Privacy by Design

יש חיבור חזק מאוד בין Article 35 לבין Article 25 של GDPR – Data Protection by Design and by Default.

Article 25 אומר:

תכננו פרטיות בתוך המערכת.

Article 35 נותן כלי מעשי לשאול:

מהם הסיכונים שאנחנו צריכים לתכנן החוצה?

ה-EDPB אף מדגיש שהערכת סיכוני הגנת מידע ו-DPIA יכולים להיות חלק חשוב מיישום Data Protection by Design.

לכן DPIA שמתבצע שבוע לפני Go Live רק כדי לקבל אישור Compliance מפספס חלק גדול מהמטרה.

DPIA טוב מתחיל כאשר עדיין אפשר לשנות:

• Architecture
• Data Flow
• Permissions
• Retention
• Vendor
• Default Settings
• או אפילו את המודל העסקי עצמו.

Article 35 כחלק מ-Continuous Privacy Management

Article 35 אינו צריך לעמוד לבד.

ארגון בוגר צריך לחבר אותו לתהליכים נוספים:

• RoPA
• Data Mapping
• Privacy Risk Assessment
• DPO
• Vendor Risk Management
• Privacy by Design
• Information Security
• Data Governance
• AI Governance
• Retention
• ו-Incident Response

כך DPIA הופך מפעילות רגולטורית נקודתית למנגנון עבודה שחוזר בכל פעם שהארגון מכניס מערכת, טכנולוגיה או תהליך חדש.

עדכון חשוב ל-2026: ה-EDPB מקדם Template אחיד ל-DPIA

באפריל 2026 הודיע ה-European Data Protection Board על אימוץ Template חדש ל-DPIA, שנועד לסייע לארגונים לבנות תהליך עקבי, מובנה ומתועד יותר ברחבי אירופה. נכון לפרסום ההודעה, התבנית הועמדה להתייעצות ציבורית, וה-EDPB הבהיר כי השימוש בה אינו חובה בפני עצמו.

המהלך מעניין משום שהוא מדגים את הכיוון שאליו הולך עולם הפרטיות:

פחות הסתמכות על מסמכים כלליים,

יותר תהליך מובנה, יותר Evidence ויותר יכולת להראות כיצד הארגון זיהה וניהל את הסיכון.

עבור ארגונים שפועלים במספר מדינות באירופה, סטנדרטיזציה כזו עשויה להקל על בניית מתודולוגיית DPIA אחידה ברמת הקבוצה.

האם Article 35 רלוונטי גם לחברה ישראלית?

בהחלט יכול להיות.

ארגון ישראלי עשוי להיכנס לתחולת GDPR בהתאם לפעילותו מול אנשים הנמצאים באיחוד האירופי, השירותים שהוא מציע והאופן שבו הוא עוקב או מעבד מידע.

אם הארגון כפוף ל-GDPR ומבצע פעילות Processing שמגיעה לרמת הסיכון המתוארת ב-Article 35, הדרישה ל-DPIA יכולה לחול גם עליו.

תרחישים רלוונטיים במיוחד יכולים לכלול:

• חברת SaaS ישראלית המשרתת לקוחות אירופיים
• חברת MedTech המעבדת מידע רפואי
• פלטפורמת HR המבצעת Profiling
• מערכת AI המעבדת מידע על משתמשים
• מערכת ניטור
• ארגון המחזיק מאגרי מידע רגישים בהיקף משמעותי

צרכים ייעוץ בתחום הגנת הפרטיות ו -GDPR Article 35 – דברו עם המומחים שלנו

Article 35 הוא לא רק Compliance – הוא מנגנון לקבלת החלטות

קל לקרוא את Article 35 ולראות בו עוד סעיף רגולטורי.

אבל יש בו תפיסה רחבה יותר.

לפני שאנחנו מעבדים מידע באופן שעלול להשפיע משמעותית על אנשים, אנחנו צריכים להבין את ההשלכות.

לפני Go Live, לפני הפגיעה ולפני שהרגולטור שואל שאלות.

מנקודת המבט הזו, DPIA הוא אחד הכלים החשובים ביותר לחיבור בין:

Privacy, Cybersecurity, Risk Management, Technology ו-Governance.

כיצד אינפוגארד מסייעת ביישום Article 35 ו-DPIA

באינפוגארד אנו מסייעים לארגונים לבחון האם פעילות עיבוד מסוימת מחייבת או מצדיקה DPIA ולבצע תהליך מובנה של PIA / DPIA – תסקיר פרטיות, בהתאם לאופי הארגון, המידע, הטכנולוגיה והרגולציה הרלוונטית.

התהליך עשוי לכלול:

• DPIA Screening
• מיפוי פעילות העיבוד ו-Data Flows
• זיהוי Special Categories of Data
• בחינת Necessity ו-Proportionality
• זיהוי Privacy Risks
• הערכת Likelihood ו-Impact
• בניית Privacy Risk Register
• הגדרת Mitigation ו-Controls
• שילוב DPO בתהליך
• Privacy by Design
• בחינת מערכות AI וטכנולוגיות חדשות
• Vendor ו-Third Party Assessment
• תיעוד הממצאים והחלטות הארגון

המטרה היא לא רק לסמן שהארגון "ביצע DPIA".
המטרה היא לוודא שהחלטות משמעותיות על מידע אישי מתקבלות כאשר הסיכון ידוע, מובן ומנוהל.

צרכים ייעוץ בתחום הגנת הפרטיות ו -GDPR Article 35 – דברו עם המומחים שלנו

Article 35 של GDPR מחייב ארגונים לבצע DPIA כאשר פעילות עיבוד מידע צפויה ליצור High Risk לזכויות ולחירויות של אנשים.
הסעיף הופך את הערכת השפעת הפרטיות לחלק מתכנון מערכות, פרויקטים וטכנולוגיות חדשות, ומחבר בין GDPR, DPO, Privacy by Design וניהול סיכונים.
עבור ארגונים שמטמיעים AI, מעבדים מידע רגיש או מפעילים ניטור ו-Profiling, Article 35 צריך להיות חלק מתהליך קבלת ההחלטות ולא רק מסמך Compliance.

המידע המוצג במאמר זה נועד למטרות מידע והעשרה בלבד ואינו מהווה ייעוץ מקצועי, רגולטורי, משפטי או טכנולוגי.
אנחנו באינפוגארד מאמינים כי כל ארגון נדרש לבחון את צרכיו, הסיכונים והדרישות החלות עליו באמצעות אנשי מקצוע מתאימים על מנת להכין תוכנית הרלוונטית בדיוק לארגון ולחברה.

המאמר נכתב בשיתוף מומחי אבטחת המידע והסייבר של Infoguard מקבוצת IDOR, ונערך על ידי ROY KISCH, חובב פרטיות, אבטחת מידע, סייבר ומנהל שיווק בקבוצת חברות עידור (Messagenet, Infoguard, Idornext).