מה זה DPIA – תסקיר השפעה על הגנת הפרטיות?

DPIA הוא ראשי תיבות של Data Protection Impact Assessment, ובעברית: תסקיר השפעה על הגנת הפרטיות.

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

המטרה אינה רק לתעד כיצד הארגון מעבד מידע.

המטרה היא להבין:

1. איזה מידע נאסף?
2. לשם מה?
3. מי ניגש אליו?
4. לאן הוא מועבר?
5. כמה זמן הוא נשמר?
6. אילו סיכונים נוצרים?
7. האם קיימות בקרות מספקות לצמצום הסיכון.

במובן הזה, DPIA הוא הרבה יותר מעוד מסמך Compliance.

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

מתי בכלל נדרש DPIA?

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

לא כל פעילות עיבוד מידע מחייבת DPIA.

אבל יש מספר תרחישים שבהם הצורך הופך משמעותי במיוחד.

לדוגמה:

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

לכן השאלה אינה רק "האם הארגון כפוף ל-GDPR?".

השאלה הנכונה יותר היא:

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

DPIA לפני הפרויקט, לא אחרי התקלה

אחת הטעויות הנפוצות היא להתייחס ל-DPIA כמסמך שמכינים כאשר המערכת כבר פועלת.

הגישה הנכונה היא הפוכה.

DPIA צריך להשתלב כבר בשלב התכנון.

לדוגמה, ארגון מתכנן מערכת חדשה שמבצעת:

• איסוף נתוני עובדים
• ניתוח התנהגות לקוחות
• שימוש בזיהוי פנים
• הטמעת מערכת AI
• או שילוב Data Analytics חדש

זה בדיוק הזמן לעצור ולשאול:

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

זו בדיוק הרוח של Privacy by Design.

לא לתקן פרטיות בדיעבד.

אלא לתכנן אותה מראש.

מה כולל תהליך DPIA?

DPIA טוב אינו מסתכם בטופס.

הוא כולל תהליך שמאפשר לארגון להבין את הפעילות באופן מלא.

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

בשלב הראשון מגדירים מה הארגון עושה.

• מהי המערכת?
• מהו התהליך?
• איזה מידע נאסף?
• מי נושאי המידע?
• מי מקבל גישה?
• אילו ספקים מעורבים?
• האם המידע יוצא מחוץ לארגון?

מטרת העיבוד

לאחר מכן צריך להבין מדוע הארגון בכלל צריך את המידע.

זה שלב חשוב משום שבפרטיות לא מספיק לדעת שאפשר לאסוף מידע.

צריך גם להבין האם האיסוף מוצדק.

Necessity ו-Proportionality

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

לדוגמה:

אם מערכת זקוקה לשם ומייל בלבד, מדוע היא אוספת גם מספר זהות, מיקום והיסטוריית פעילות?

כאן נכנסים שלוש עקרונות מרכזיים כמו:

1. Data Minimization
2. Purpose Limitation
3. Storage Limitation

זיהוי סיכוני פרטיות

בשלב הזה בוחנים מה עלול להשתבש.

לדוגמה:

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

או פגיעה ביכולת של אדם לממש את זכויותיו.

הערכת רמת הסיכון

לא כל סיכון זהה.

צריך להבין גם את:

Likelihood – ההסתברות

וגם את:

Impact – ההשפעה

כך ניתן לתעדף סיכונים ולבנות תוכנית טיפול.

Mitigation

לאחר שזוהו הסיכונים, הארגון צריך להחליט כיצד הוא מצמצם אותם.

למשל:

• Encryption
• Access Control
• Data Minimization
• Anonymization
• Pseudonymization
• Retention Policy
• Logging
• Security Monitoring
• עדכון הסכמים
• שינוי תהליכים
• שינוי ארכיטקטורה

PIA מול DPIA – מה ההבדל?

המונחים PIA ו-DPIA משמשים לעיתים כמעט באותו הקשר, אבל יש ביניהם הבדל חשוב.

PIA – Privacy Impact Assessment הוא מונח רחב המתאר תהליך להערכת השפעת פעילות על פרטיות.

DPIA – Data Protection Impact Assessment הוא המונח המזוהה באופן מפורש עם GDPR ועם מצבים שבהם פעילות עיבוד עשויה ליצור High Risk.

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

ההבדל המרכזי הוא ההקשר הרגולטורי.

PIA יכול לשמש ככלי Privacy GAP Management גם כאשר אין חובה חוקית מפורשת.

DPIA, לעומת זאת, עשוי להיות חובה רגולטורית.

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

DPIA ו-GDPR

הקשר בין DPIA ל-GDPR הוא מהותי.

Article 35 של GDPR עוסק במצבים שבהם נדרש לבצע DPIA.

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

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

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

כלומר, DPIA הוא לא רק כלי פנימי.

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

מה הקשר ל-DPO?

ל-DPO יש תפקיד משמעותי בתהליך.

בארגון שבו מונה Data Protection Officer, ה-DPO אמור להיות מעורב בתהליך ה-DPIA ולספק ייעוץ לגבי:

1. האם DPIA נדרש?
2. כיצד יש לבצע אותו?
3. אילו בקרות יש ליישם?
4. האם הסיכון שנותר לאחר הטיפול סביר?

חשוב עם זאת להבין:

DPO אינו מחליף את בעלי התהליך העסקי והאחריות על פעילות העיבוד נשארת אצל הארגון.

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

DPIA ו-AI

אחד התחומים שבהם DPIA הופך משמעותי במיוחד הוא שימוש ב-AI.

מערכות AI עשויות לכלול:

• Profiling
• Automated Decision Making
• ניתוח כמויות גדולות של מידע אישי
• למידה על התנהגות משתמשים
• שימוש במידע ממספר מקורות
• או הסקת מסקנות חדשות על אנשים

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

לכן DPIA יכול לשמש כלי חשוב לבדיקת השאלות:

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

החיבור בין DPIA, Privacy by Design ו-AI Governance צפוי להפוך משמעותי יותר ככל שארגונים משלבים AI בתהליכים עסקיים.

DPIA כחלק מ-Privacy by Design

Privacy by Design הוא עיקרון שלפיו יש לשלב פרטיות כבר בשלב התכנון.

DPIA הוא אחד הכלים הפרקטיים ביותר ליישם את העיקרון הזה.

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

1. האם באמת צריך את כל הנתונים?
2. האם ניתן לבצע את אותו תהליך עם פחות מידע?
3. האם יש חלופה פחות פולשנית?
4. האם הארכיטקטורה מתאימה?
5. האם הספק עומד בדרישות?
6. האם הגדרות ברירת המחדל שומרות על פרטיות?

כך DPIA הופך מגישה רגולטורית לתהליך Design אמיתי.

DPIA אינו מסמך חד-פעמי

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

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

אם חל שינוי משמעותי ב:

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

צריך לבחון האם נדרש לעדכן את התסקיר.
הדבר חשוב במיוחד במערכות שמתפתחות במהירות, למשל SaaS, Cloud ו-AI.

DPIA כחלק מניהול פרטיות מתמשך

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

הוא מחבר את התהליך לעולמות נוספים:

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

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

זה בדיוק ההבדל בין Privacy Compliance נקודתי לבין Privacy Governance מתמשך.

מתי כדאי לבצע DPIA גם אם לא בטוחים שהוא חובה?

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

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

לדוגמה:

• מערכת AI חדשה
• מערכת ניטור עובדים
• שירות רפואי דיגיטלי
• מערכת Biometrics
• פלטפורמה שמעבדת מידע על ילדים
• פעילות Data Analytics חדשה

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

כיצד אינפוגארד מסייעת בתהליכי PIA ו-DPIA

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

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

• מיפוי פעילות העיבוד
• זיהוי Data Flows
• בחינת מטרות העיבוד
• זיהוי סיכוני פרטיות
• הערכת Likelihood ו-Impact
• בניית Privacy Risk Register
• הגדרת Controls ו-Mitigation
• בחינת ספקים וצדדים שלישיים
• חיבור ל-Privacy by Design
• ליווי DPO
• שילוב עם GDPR, מדיניות פרטיות ותהליכי Governance

המטרה אינה לייצר רק מסמך.

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

DPIA הוא אחד הכלים המרכזיים להפיכת Privacy from Policy ל-Privacy in Practice.

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

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

צרכים ייעוץ בתחום BAI | DPIA | PIA – דברו עם המומחים שלנו

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

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

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