מתיקון 13 ועד GDPR פרטיות נכונה מתחילה בתכנון – Privacy by Design
יש משפט שאנחנו שומעים בארגונים שוב ושוב:
"כשהמערכת תהיה מוכנה, נעביר אותה לפרטיות ולמשפטית."
בעינינו, זו בדיוק הבעיה.
אם צוות המוצר כבר הגדיר אילו נתונים ייאספו, הפיתוח הסתיים, הספקים כבר חוברו, בסיס הנתונים נבנה והמערכת עומדת רגע לפני עלייה לאוויר – ברוב המקרים כבר מאוחר מדי לבצע שינוי מהותי בלי לשלם עליו בזמן, בכסף או בפגיעה בתהליך העסקי.
ואז מתחיל שלב ה"תיקונים":
- מוסיפים Checkbox.
- משנים נוסח הסכמה.
- מעדכנים מדיניות פרטיות.
- מגבילים הרשאות.
- מנסים להבין למה בכלל נשמר שדה מסוים.
ומגלים שמידע שכבר לא צריך ממשיך להישמר כי אף אחד לא הגדיר מנגנון מחיקה.
זה אולי נראה כמו Privacy Compliance.
אבל זו לא Privacy by Design.
Privacy by Design אומר משהו הרבה יותר בסיסי:
פרטיות צריכה להיות חלק מהדרך שבה אנחנו מתכננים את המערכת – לא תיקון שאנחנו מוסיפים אחרי שכבר בנינו אותה.
Privacy by Design הוא קודם כול שינוי בצורת החשיבה
Privacy by Design אינו מוצר, תקן או Checklist.
זוהי תפיסת עבודה שלפיה שאלות פרטיות צריכות להישאל כבר בשלב שבו מקבלים החלטות על המוצר, השירות, המערכת או התהליך.
לפני ששואלים:
איך נאבטח את המידע?
צריך לפעמים לשאול:
למה אנחנו בכלל אוספים אותו?
לפני ששואלים:
כמה זמן נשמור את הנתונים?
צריך לשאול:
האם יש צורך עסקי אמיתי לשמור אותם?
ולפני שנותנים לספק חדש גישה למערכת:
איזה מידע הוא באמת צריך לראות כדי לבצע את השירות?
אלה שאלות פשוטות לכאורה, אבל הן משנות לחלוטין את הדרך שבה ארגון מנהל פרטיות.
GDPR הפך את הרעיון לעיקרון מחייב
ה-GDPR לא מסתפק בדרישה שארגונים ישמרו מידע באופן מאובטח.
סעיף 25 שלו מעגן במפורש את עקרונות Data Protection by Design and by Default.
המשמעות היא שהגנת מידע צריכה להיות משולבת באמצעים הטכנולוגיים והארגוניים כבר בעת קביעת אמצעי העיבוד, ולהמשיך לאורך מחזור החיים של העיבוד.
גם ברירת המחדל צריכה לעבוד לטובת הפרטיות.
כלומר, מערכת חדשה לא אמורה להתחיל מ:
"נאסוף הכול, ניתן גישה לכולם ונצמצם אחר כך."
אלא להפך:
נאסוף רק מה שצריך, נאפשר גישה רק למי שצריך, ונשמור את המידע רק למשך הזמן שנדרש.
ה-European Data Protection Board מדגיש ש-Data Protection by Design and by Default הוא תהליך מתמשך, ולא פעולה חד-פעמית שמבצעים לפני השקת מערכת.
ומה הקשר לתיקון 13 בישראל?
תיקון 13 לחוק הגנת הפרטיות אינו "ה-GDPR הישראלי", ולא נכון להתייחס אליו כאילו שתי המסגרות זהות.
אבל הכיוון הניהולי ברור מאוד.
התיקון, שנכנס לתוקף ב-14 באוגוסט 2025, הרחיב את ההגדרות, חיזק משמעותית את סמכויות האכיפה של הרשות להגנת הפרטיות והעלה את רמת האחריות המוטלת על ארגונים שמנהלים מידע אישי.
במקרים מסוימים הוא גם מחייב מינוי ממונה הגנת פרטיות – DPO – והרשות להגנת הפרטיות עצמה קושרת את התפקיד לעקרון ה-Accountability, כלומר האחריותיות הארגונית.
וזה בדיוק המקום שבו Privacy by Design הופך מרעיון אירופי נחמד לפרקטיקה ניהולית רלוונטית מאוד גם לארגונים בישראל.
כי ארגון שרוצה להראות שהוא באמת מנהל פרטיות צריך להיות מסוגל להסביר:
- איזה מידע הוא אוסף.
- למה הוא אוסף אותו.
- מי מקבל אליו גישה.
- לאילו ספקים הוא מועבר.
- כמה זמן הוא נשמר.
- אילו סיכונים נבחנו.
- ואילו החלטות התקבלו כדי לצמצם את הסיכון מראש.
לא רק אחרי שהמערכת כבר קיימת.
הבעיה: רוב הארגונים עדיין מנהלים פרטיות בדיעבד
אנחנו רואים את זה בהרבה מאוד תהליכים:
- מערכת HR חדשה נבחרת, ואז מערבים את ה-DPO.
- מחלקת השיווק מטמיעה מערכת Lead Generation חדשה – ואז מגלים שהמידע עובר לספקים נוספים.
- מוצר חדש אוסף נתוני משתמשים, ורק לפני ההשקה מתחילים לשאול מה צריך להיות כתוב במדיניות הפרטיות.
- מחלקת IT מחברת שירות SaaS חדש, ורק לאחר מכן עולה השאלה איפה נשמר המידע.
- מחלקת AI מזינה מסמכים למודל- ורק כאשר מתעוררת שאלה משפטית מתחילים לבדוק מה קרה לנתונים.
זו אינה בעיה של אנשים לא מקצועיים, זו בעיקר בעיה של תהליך.
אם פרטיות אינה נמצאת בנקודות קבלת ההחלטות, היא תמיד תגיע מאוחר מדי.
Privacy by Design לא אומר שה-DPO צריך לאשר כל דבר
גם זו תפיסה שחשוב לתקן.
המטרה אינה להפוך את מנהל הפרטיות לצוואר בקבוק.
להפך.
Privacy by Design טוב אמור להפוך הרבה החלטות לשגרתיות יותר.
הארגון יכול להגדיר מראש עקרונות, לדוגמה:
Data Minimization
אוספים רק את הנתונים הנדרשים למטרה שהוגדרה.
Need to Know
גישה למידע ניתנת רק לתפקידים הזקוקים לה.
Retention
לכל סוג מידע קיימת תקופת שמירה מוגדרת.
Purpose Limitation
מידע שנאסף למטרה אחת אינו עובר אוטומטית לשימוש אחר.
Secure Defaults
ברירת המחדל של המערכת צריכה להיות ההגדרה המגינה יותר.
Vendor Review
ספק שמקבל מידע אישי נבחן כחלק מתהליך מסודר.
Privacy Review
פרויקטים בעלי השפעה משמעותית על מידע אישי עוברים בחינת פרטיות לפני יישום.
כאשר העקרונות האלה מוטמעים בתהליך, צוותים יכולים לנוע מהר יותר – לא לאט יותר.
Privacy by Default חשוב לא פחות
יש הבדל קטן אבל חשוב בין Privacy by Design לבין Privacy by Default.
Privacy by Design עוסק בדרך שבה בונים את המערכת.
Privacy by Default עוסק במה שקורה כאשר המשתמש לא משנה שום דבר.
לדוגמה:
- אם משתמש פותח חשבון חדש, האם הפרופיל שלו ציבורי כברירת מחדל?
- האם כל עובד במערכת יכול לראות את כל רשומות הלקוחות?
- האם שיתוף מידע עם צד שלישי מופעל אוטומטית?
- האם המערכת שומרת מידע ללא הגבלת זמן?
- האם הרשאת Location, Camera או Contacts מופעלת כברירת מחדל?
הבחירה בברירות המחדל אינה פרט טכני קטן.
היא משקפת את הגישה של הארגון לפרטיות.
דוגמה פשוטה: טופס לידים
ניקח תהליך שיווקי בסיסי.
החברה רוצה ליצור טופס באתר לקבלת פניות.
גישה אחת היא לבקש:
שם מלא, חברה, תפקיד, טלפון, אימייל, כתובת, גיל, תחום עניין ועוד מספר שדות "שאולי יהיו שימושיים בעתיד".
בגישה של Privacy by Design נשאל קודם:
מה באמת דרוש כדי לחזור לפונה?
אולי שם, טלפון או אימייל מספיקים.
פחות מידע שנאסף פירושו:
- פחות מידע שיש להגן עליו.
- פחות מידע שצריך לנהל.
- פחות חשיפה במקרה של אירוע.
- פחות מורכבות במענה לבקשות פרטיות.
- ולעתים גם חוויית משתמש טובה יותר.
זה בדיוק המקום שבו פרטיות ואפקטיביות עסקית אינן עומדות זו מול זו.
דוגמה מורכבת יותר: מערכת AI
עכשיו נחשוב על מערכת AI ארגונית שאמורה לסייע לעובדים לחפש מידע במסמכים.
אפשר לחבר אותה לכל מאגר המסמכים ולפתור אחר כך את סוגיית ההרשאות.
ואפשר לתכנן מראש:
- איזה מידע המערכת רשאית לקרוא?
- האם היא מכבדת את הרשאות המקור?
- האם מידע רגיש יכול להיכנס למודל?
- האם Prompts נשמרים?
- מי רואה את התוצרים?
- האם הספק משתמש במידע לשיפור המודל?
- מה קורה כאשר עובד עוזב?
- איך מוחקים מידע?
- מי יכול לבצע Export?
Privacy by Design במקרה הזה הוא לא עוד סעיף של Privacy Policy.
הוא חלק מארכיטקטורת המערכת.
Privacy by Design מתחבר ישירות לניהול סיכונים
וזו נקודה שלעתים מפספסים.
פרטיות אינה רק עבודה משפטית.
מידע אישי מתקיים בתוך מערכות, ממשקים, APIs, שרתי Cloud, תחנות קצה, מערכות SaaS, Data Warehouses וספקים.
לכן אי אפשר לנהל פרטיות בלי להבין גם את סביבת הטכנולוגיה ואת הסיכון.
בפרויקטים משמעותיים נכון לשלב גם תהליכים כמו Privacy Impact Assessment – PIA או Data Protection Impact Assessment – DPIA, בהתאם למסגרת החלה ולרמת הסיכון.
המטרה אינה לייצר עוד מסמך.
המטרה היא לעצור לפני שמקבלים החלטה שקשה מאוד יהיה לתקן אחר כך.
ומה תפקידו של ה-DPO?
בעינינו, DPO טוב לא צריך להיות האדם שמגיע בסוף ואומר "אסור".
הוא צריך להיות חלק מהמערכת שמאפשרת לארגון לקבל החלטות נכונות מוקדם יותר.
שירות DPO וניהול פרטיות במיקור חוץ של Infoguard בנוי בדיוק סביב הגישה הזו: חיבור בין מדיניות, תהליכים, ספקים, העברות מידע, סיכונים, תיעוד ובקרה שוטפת.
כי פרטיות טובה אינה אמורה להתקיים רק בקלסר.
היא צריכה להיות נוכחת במקום שבו הארגון עובד.
גם מדיניות פרטיות טובה לא מתקנת מערכת שתוכננה לא נכון
אפשר לכתוב את מדיניות הפרטיות הטובה בעולם.
אבל אם המערכת אוספת מידע מיותר, מעניקה הרשאות רחבות מדי, שומרת נתונים לנצח ומעבירה אותם לעשרות ספקים – המסמך לא פותר את הבעיה.
כבר כתבנו בעבר על האשליה שלפיה מדיניות פרטיות ו-Cookie Banner מספיקים כדי לייצר תאימות.
Privacy by Design לוקח את הרעיון הזה צעד נוסף קדימה:
ציות אינו שכבה שמניחים מעל המערכת. הוא צריך להיות חלק מהמערכת עצמה.
פרטיות צריכה להיכנס ל-Project Lifecycle
אם רוצים להפוך Privacy by Design מרעיון לפרקטיקה, צריך להכניס אותו לתהליכים הקיימים בארגון.
לדוגמה:
- בעת רכישת מערכת חדשה.
- בעת פיתוח מוצר.
- בעת שינוי משמעותי בתהליך עסקי.
- בעת חיבור ספק חדש.
- בעת מעבר לענן.
- בעת שימוש חדש במידע קיים.
- בעת הטמעת כלי AI.
- בעת יצירת אינטגרציה חדשה.
- בעת הקמת אתר, אפליקציה או פורטל לקוחות.
לא כל שינוי דורש פרויקט פרטיות מלא.
אבל צריך להיות מנגנון שמאפשר לזהות מתי יש סיכון שמצדיק בדיקה.
שבע שאלות שהיינו שואלים בתחילת כל פרויקט
עוד לפני מסמך משפטי מפורט, אפשר להתחיל משבע שאלות פשוטות:
- איזה מידע אישי אנחנו עומדים לאסוף או לעבד?
- למה אנחנו צריכים אותו?
- האם אפשר להשיג את אותה מטרה עם פחות מידע?
- מי באמת צריך לקבל אליו גישה?
- לאילו ספקים או מערכות נוספות המידע יעבור?
- כמה זמן אנחנו צריכים לשמור אותו?
- מה יכול להשתבש, ואיך אפשר לצמצם את הסיכון כבר עכשיו?
אם צוות פרויקט מסוגל לענות עליהן בשלב התכנון, הוא כבר נמצא במקום טוב בהרבה.
תיקון 13 צריך לשנות גם את הדרך שבה הנהלות מסתכלות על פרטיות
אחת ההשפעות החשובות של תיקון 13 היא לא סעיף כזה או אחר.
זו העובדה שהפרטיות בישראל הופכת בהדרגה לתחום שדורש יותר Governance, Accountability ו-Evidence.
לא מספיק לומר:
"יש לנו נוהל."
צריך להיות מסוגלים להראות איך הוא עובד.
לא מספיק לומר:
"אנחנו שומרים על פרטיות."
צריך לדעת מי אחראי, אילו סיכונים זוהו ומה נעשה בעקבותיהם.
ולא מספיק לבצע בדיקה פעם אחת.
- מערכות משתנות.
- ספקים משתנים.
- טכנולוגיות משתנות.
- והשימוש במידע משתנה.
לכן ניהול פרטיות צריך להיות תהליך מתמשך. גם הגישה הנוכחית של הרשות להגנת הפרטיות סביב תפקיד ה-DPO מחזקת את המעבר לממשל, אחריותיות ובקרה שיטתית.
Privacy by Design הוא לא מגבלה על חדשנות
יש ארגונים שחוששים שפרטיות מוקדמת תהפוך כל פרויקט לאיטי יותר.
מניסיוננו, בדרך כלל קורה ההפך.
הרבה יותר פשוט לשנות שדה בטופס בשלב האפיון מאשר לאחר שהמערכת בפרודקשן.
הרבה יותר זול לבנות הרשאות נכונות מראש מאשר לבצע Remediation שנה לאחר מכן.
הרבה יותר פשוט להכניס דרישת מחיקה להסכם עם ספק בזמן המשא ומתן מאשר לגלות מאוחר יותר שאין לו יכולת למחוק את המידע.
Privacy by Design אינו אומר:
אל תעשו.
הוא אומר:
תחשבו לפני שאתם עושים.
לעבור מ-Privacy Compliance ל-Privacy Management
זו בעינינו הנקודה המרכזית.
ארגון יכול לעמוד בדרישה נקודתית ולהמשיך לנהל פרטיות בצורה לא טובה.
המטרה צריכה להיות רחבה יותר:
לבנות Privacy Management.
תהליך שבו:
- יודעים איזה מידע קיים
- מבינים את מטרות העיבוד
- מגדירים בעלות ואחריות
- מנהלים ספקים
- מבצעים הערכות סיכון
- מנהלים Retention
- עוקבים אחר שינויים
- מטפלים בזכויות נושאי מידע
- מתעדים החלטות
- מכניסים פרטיות לתהליכי העבודה עצמם
כך גם תיקון 13 לחוק הגנת הפרטיות וגם ה-GDPR הופכים מתיקייה של מסמכי Compliance לשגרת ניהול אמיתית.
הפרטיות הטובה ביותר היא זו שלא צריך לתקן אחר כך
Privacy by Design הוא בסופו של דבר רעיון פשוט מאוד:
החלטות שמגנות על פרטיות קל וזול יותר לקבל לפני שבונים מערכת, ולא אחרי שהיא כבר עובדת.
תיקון 13 מחזק בישראל את הצורך בניהול פרטיות אמיתי.
ה-GDPR כבר הגדיר Data Protection by Design and by Default כמרכיב מרכזי במשטר הפרטיות האירופי.
אבל גם בלי רגולציה, ההיגיון העסקי ברור.
ארגון שאוסף פחות מידע מיותר, מגדיר הרשאות בצורה נכונה, בוחן ספקים מראש ומנהל את מחזור החיים של הנתונים – הוא ארגון עם פחות סיכון, פחות חוב טכנולוגי ויכולת טובה יותר להסביר ללקוחות, לעובדים ולרגולטור מה הוא עושה עם המידע.
מבחינתנו באינפוגארד, זה ההבדל בין לטפל בפרטיות לבין לנהל פרטיות.
אל תחכו לעלייה לאוויר כדי לשאול את שאלות הפרטיות
אם אתם מפתחים מערכת חדשה, מטמיעים SaaS, מחברים כלי AI, יוצרים תהליך חדש או רוצים לבדוק כיצד Privacy by Design יכול להשתלב בתהליכי העבודה בארגון – אנחנו באינפוגארד מסייעים לבנות את מסגרת הפרטיות מהתכנון ועד הבקרה השוטפת.
דרך שירותי DPO וניהול פרטיות, סקרי פערים, DPIA/PIA, עבודה מול ספקים והתאמה לתיקון 13 ול-GDPR – המטרה היא לא רק להיות compliant ביום הבדיקה.
המטרה היא לבנות תהליכים שנשארים נכונים גם ביום שאחריה.
המידע המוצג במאמר זה נועד למטרות מידע והעשרה בלבד ואינו מהווה ייעוץ מקצועי בנושאי סייבר, פרטיות, אבטחת מידע, תקינה ורגולציה, ייעוץ משפטי או טכנולוגי.
אנחנו באינפוגארד מאמינים שכל ארגון נדרש לבחון את צרכיו, הסיכונים והדרישות החלות עליו באמצעות אנשי מקצוע מתאימים ולהתאים את התוכנית והפתרונות ספציפית לארגון, לתקינה ולמצב הקיים.
המאמר נכתב בשיתוף מומחי אבטחת המידע והסייבר של Infoguard מקבוצת IDOR, ונערך על ידי ROY KISCH, חובב פרטיות, אבטחת מידע, סייבר ומנהל השיווק בקבוצת חברות עידור (Messagenet, Infoguard, Idornext).
