פרטיות בתכנון (Privacy by Design): לבנות נכון מהיום הראשון

צוות המוצר מציג את המסך החדש להרשמה. יש בו תשעה שדות: שם, מייל, טלפון, ת״ז, תאריך לידה, כתובת, מקום עבודה, ותיבת סימון של ״אני מאשר לקבל דיוור שיווקי״ — כבר מסומנת מראש. מישהו שואל: ״למה אנחנו צריכים ת״ז כדי לפתוח חשבון?״ ואף אחד לא יודע לענות. ״ככה תמיד עשינו״. הרגע הזה — שבו שדה מיותר נכנס למערכת בלי שאף אחד עצר לשאול אם הוא באמת נחוץ — הוא בדיוק מה שפרטיות בתכנון (Privacy by Design) באה למנוע. הרעיון פשוט: קל בהרבה, וזול בהרבה, לבנות מערכת עם פרטיות מובנית מהשורה הראשונה של הקוד — מאשר לתקן אותה אחרי שכבר אספתם מיליון רשומות שאסור היה לאסוף. במאמר הזה נפרק את שבעת העקרונות של Privacy by Design לשפה מעשית עם דוגמאות לעסק קטן-בינוני, נראה איך זה נראה בפרויקט אמיתי, ונסביר למה בישראל של אחרי תיקון 13 זה כבר לא ״נחמד שיהיה״ אלא ציפייה של הרגולטור.

שבעת העקרונות — בשפה של מי שבונה מוצר

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

1. יוזמה, לא תגובה — מניעה, לא תרופה. לחשוב על הפרטיות *לפני* שהמערכת עולה לאוויר, לא אחרי שהתקבלה תלונה או קרתה פרצה. דוגמה: לפני שמשיקים טופס לידים חדש, שואלים ״מה יקרה אם הרשימה הזו תדלוף?״ — ומצמצמים בהתאם, במקום לגלות את התשובה בדרך הקשה.
2. פרטיות כברירת מחדל. אם המשתמש לא עושה כלום — הפרטיות שלו נשמרת מקסימלית. זה מבחן תיבת הסימון: תיבת ״אני מאשר דיוור שיווקי״ צריכה להיות ריקה כברירת מחדל, לא מסומנת מראש. הרשות להגנת הפרטיות דורשת הסכמה אקטיבית — משתמש שרוצה לקבל דיוור מסמן בעצמו.
3. פרטיות מוטמעת בתכנון. ההגנה על הפרטיות היא חלק מהארכיטקטורה, לא תוסף שמדביקים בסוף. דוגמה: הצפנת שדות רגישים במסד הנתונים מתוכננת ביום הראשון של הסכימה — לא ״נוסיף הצפנה כשיהיה זמן״.
4. פונקציונליות מלאה — Win-Win, לא סכום אפס. פרטיות לא צריכה לבוא על חשבון חוויית המשתמש או המטרה העסקית. הדילמה ״או שירות טוב או פרטיות״ היא כמעט תמיד דילמה מזויפת. דוגמה: אפשר לאמת גיל בלי לשמור תאריך לידה מלא — מספיק דגל ״מעל 18״.
5. אבטחה מקצה לקצה — לאורך כל מחזור החיים. המידע מוגן מרגע האיסוף ועד המחיקה: הצפנה בתעבורה ובאחסון, הרשאות, גיבויים — ובעיקר מחיקה בסוף. מידע ששמור ״ליתר ביטחון״ בלי מטרה הוא התחייבות, לא נכס.
6. נראות ושקיפות — לשמור את זה פתוח. המשתמש יכול להבין איזה מידע נאסף עליו, למה, ומה קורה איתו. מדיניות פרטיות קריאה, לא קיר טקסט משפטי שהועתק מאתר אמריקאי. דוגמה: ליד כל שדה בטופס, משפט שמסביר למה אתם צריכים אותו.
7. כבוד לפרטיות המשתמש — ממוקד באדם. המשתמש במרכז: ברירות מחדל מגינות, אפשרות אמיתית לבחור, ומנגנון פשוט להסרה או למחיקה. לא לקבור את כפתור ה״הסרה מהדיוור״ בעשרה קליקים.

איך זה נראה בפרויקט אמיתי: הקמת CRM חדש

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

• צמצום ברמת השדה. עוברים שדה-שדה ושואלים: ״למה אנחנו צריכים את זה?״ האם באמת צריך ת״ז של הלקוח, או שמזהה פנימי מספיק? תאריך לידה מלא, או רק חודש להברכה? כל שדה שאין לו הצדקה ברורה — לא נכנס.
• תקופת שמירה שנקבעת בהקמה. לכל סוג מידע מגדירים כמה זמן שומרים אותו ומה קורה אחר כך — מחיקה או אנונימיזציה. את זה קובעים עכשיו, כשקל, ולא ״כשנגיע לזה״ (לא מגיעים).
• הרשאות גישה לפי תפקיד. לא כל עובד רואה הכול. איש מכירות רואה את הלקוחות שלו; הנהלת חשבונות רואה נתוני חיוב; מתמחה קיץ לא רואה את כל המאגר. הרשאות מוגדרות ברמת התפקיד, לא ״כולם אדמין״.
• הסכם עיבוד מידע (DPA) עם הספק. אם ה-CRM הוא שירות ענן, הספק הוא ״מחזיק״ של המידע שלכם. צריך חוזה שמגדיר מה מותר לו לעשות עם הדאטה, איפה היא נשמרת, וחובות אבטחה — לא רק ״לחצתי Accept על תנאי השימוש״.
• שלב סקירת פרטיות לפני העלייה לאוויר. לפני שהמערכת עולה, מישהו אחראי עובר על ההחלטות האלה ומאשר. בארגון עם ממונה הגנת פרטיות (DPO) זה חלק מהתפקיד; בעסק קטן זה יכול להיות המנהל שאחראי על התחום — העיקר שיש כתובת ושלב מוגדר.

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

צמצום מידע: השריר המרכזי

אם צריך לבחור עיקרון אחד מכל השבעה שמניב את התשואה הגבוהה ביותר — זה צמצום המידע (Data Minimization). הכלל פשוט עד כדי גיחוך: מידע שלא אספתם לא יכול לדלוף, לא יכול להיגנב, ולא יכול לעלות לכם בקנס. כל שדה שאתם מוותרים עליו מקטין בו-זמנית את משטח התקיפה ואת החשיפה הרגולטורית.

והחשיפה הרגולטורית בישראל כבר לא תיאורטית. תחת תיקון 13, העיצומים הכספיים על עיבוד מידע שלא כדין נגזרים לפי מספר נושאי המידע במאגר: לפי המדריך המקצועי של הרשות להגנת הפרטיות, עיבוד מידע שלא כדין עומד על 4 ₪ לכל נושא מידע (8 ₪ אם מדובר במידע רגיש במיוחד), במינימום 200,000 ₪. הדוגמה של הרשות עצמה: עיבוד לא מורשה במאגר של 200,000 אנשים עם מידע רגיש מגיע ל-1,600,000 ₪. המשמעות המעשית ברורה: ככל שהמאגר גדול ורגיש יותר, כך כל שדה מיותר מכפיל את הסיכון בכסף. מאגר קטן ורזה הוא לא רק היגייני יותר — הוא זול יותר כשמשהו משתבש.

PETs — טכנולוגיות משפרות פרטיות בשפה פשוטה

בפברואר 2025 פרסמה הרשות להגנת הפרטיות מדריך לטכנולוגיות משפרות פרטיות (PETs — Privacy-Enhancing Technologies). השם מאיים, אבל הרעיון פשוט: כלים שמאפשרים להשתמש במידע תוך צמצום הפגיעה בפרטיות. שלושה שכדאי להכיר, ומתי כל אחד מתאים:

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

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

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

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

• תיבות דיוור שיווקי — ריקות כברירת מחדל. הסכמה אקטיבית, לא תיבה מסומנת מראש. זו גם דרישת חוק הספאם וגם עמדת הרשות.
• הרשאות באפליקציה — לבקש גישה (מיקום, אנשי קשר, מצלמה) רק כשבאמת צריך אותה לפעולה, ולא ״הכול מראש בהתקנה״.
• נראות פרופיל / שיתוף — אם המוצר חברתי, ברירת המחדל היא הפרטית ביותר; המשתמש בוחר לפתוח, לא לסגור.
• עוגיות (Cookies) — עוגיות שאינן חיוניות דולקות רק אחרי הסכמה אקטיבית, לא כברירת מחדל. אכיפת הרשות על אתרי מסחר בדצמבר 2025 כללה בדיוק את מנגנוני ההסכמה לעוגיות.

מה עושים כשלא בניתם נכון מלכתחילה?

רוב הארגונים הקוראים את זה לא מתחילים מדף חלק. יש להם מערכות ותיקות, מאגרים שנצברו לאורך שנים, וטפסים שאף אחד לא זוכר מי בנה. זה בסדר — פרטיות בתכנון היא לא הכול-או-כלום, והרטרוֹפיט (התאמה בדיעבד) הוא נתיב הדרגתי:

1. כל פרויקט חדש — מהיום. קל להתחיל נכון מאשר לתקן. כל מערכת חדשה, טופס חדש או פיצ׳ר חדש עובר את שלב סקירת הפרטיות. זה עוצר את הדימום.
2. שלושת המערכות המובילות. אחרי שהחדש מכוסה, בוחרים את שלושת המאגרים הגדולים/הרגישים ביותר — לרוב ה-CRM, מערכת השכר/HR, ואתר האינטרנט — ומריצים עליהם ביקורת שדות ותקופות שמירה.
3. מחיקת מה שלא צריך. הצעד עם התשואה הכי גבוהה: למחוק מידע ישן שכבר אין לו מטרה. פחות דאטה = פחות סיכון, מיד.
4. להמשיך בגלים. מערכת אחר מערכת, בקצב שהארגון עומד בו. העיקר שהכיוון קבוע ושיש שלב סקירה מובנה שלא נותן לפערים חדשים להיפתח.

תבנית: מסמך סקירת פרטיות לפרויקט (עמוד אחד)

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

• שם הפרויקט ובעל האחריות — מי ממלא, ומי מאשר.
• איזה מידע אישי נאסף — רשימת שדות, ולכל שדה: הצדקה קונקרטית. שדה בלי הצדקה יורד.
• מטרת האיסוף — למה, ולפי איזו בסיס (הסכמה / חובה חוקית / צורך בשירות).
• רגישות — האם יש מידע רגיש במיוחד (רפואי, ביומטרי, פיננסי)? זה קובע רמת אבטחה וחשיפה.
• תקופת שמירה ומחיקה — כמה זמן, ומה קורה אחר כך.
• גישה והרשאות — מי ניגש, לפי איזה תפקיד.
• ספקים וצד ג׳ — למי המידע זורם החוצה, ויש DPA?
• ברירות מחדל והסכמה — תיבות ריקות, Opt-in, מנגנון הסרה.

צ׳קליסט להשבוע

1. בחרו טופס אחד פעיל (יצירת קשר / לידים / הרשמה) ועברו עליו שדה-שדה עם מבחן שלוש השאלות. מחקו כל שדה בלי הצדקה.
2. בדקו את תיבות הדיוור והעוגיות — ודאו שאף אחת לא מסומנת מראש.
3. כתבו את מסמך סקירת הפרטיות בעמוד אחד (התבנית למעלה) והפכו אותו לשלב חובה בכל פרויקט חדש.
4. בחרו את המאגר הגדול/רגיש ביותר שלכם והגדירו לו תקופת שמירה — ומחקו מה שכבר עבר אותה.
5. לכל שירות ענן שמחזיק מידע אישי — ודאו שיש DPA חתום, לא רק ״Accept״.
6. מנו כתובת אחת אחראית לסקירת פרטיות. בארגון שחייב ממונה הגנת פרטיות — זה חלק מהתפקיד.

פרטיות בתכנון היא לא פרויקט חד-פעמי ולא תקן שמקבלים עליו תעודה. היא הרגל: שאלה אחת קטנה — ״האם אנחנו באמת צריכים את זה?״ — שנשאלת בכל פעם שבונים משהו חדש. ארגון שמפנים את ההרגל הזה אוסף פחות, מסתכן פחות, וכשמגיע יום הביקורת של הרשות — יש לו הרבה פחות מה להסביר.

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