הבהרה, כי היא חשובה כאן
אני CTO, לא עורך דין, וזה לא ייעוץ משפטי. מה שאני כן יכול לתת זה את הצד שאני רואה מקרוב: מה מתוך התיקון הזה מתורגם לשורות קוד, לטבלאות במסד הנתונים ולסעיפים בהסכם מול ספק. את הניסוח המשפטי והבדיקה הפרטנית תעשו עם עורך דין שמתמחה בפרטיות. פרויקט של 60,000 ש"ח מצדיק שעתיים כאלה.
המקרה שהופך את זה מתאורטי למוחשי
ב-21 ביולי 2026 הוטל העיצום הכספי הראשון מסוגו מאז שהתיקון נכנס לתוקף: 256,000 ש"ח על קופת חולים מאוחדת. שווה לקרוא את הפרטים, כי הם מלמדים.
התקלה עצמה הייתה פגם במערכת דיגיטלית שאיפשר למבוטחים לראות מידע רפואי של בני משפחה. הקופה גילתה אותה בנובמבר 2025 והגישה דיווח רשמי לרשות רק בינואר 2026. העיצום לא הוטל על הפגם — הוא הוטל על האיחור בדיווח. הרשות הבהירה שהחובה היא לדווח מיד עם הגילוי, וששמירת הדיווח עד שמסיימים לחקור סותרת את דרישת המיידיות.
זה הלקח המרכזי לכל מי שמפעיל מוצר: התרחיש שיעלה לכם כסף הוא לא בהכרח הבאג. הוא מה שעשיתם בשעות שאחרי.
מה בעצם השתנה ב-14 באוגוסט 2025
התיקון אושר בכנסת באוגוסט 2024 ונכנס לתוקף שנה לאחר מכן, ב-14 באוגוסט 2025. ארבעה שינויים נוגעים כמעט לכל מי שמפעיל מוצר דיגיטלי בישראל.
1. פחות בירוקרטיה, יותר אכיפה
חובת רישום המאגרים, שהייתה במשך שנים הטופס שכולם מילאו ושכחו, בוטלה עבור רוב הגופים ונשארה בעיקר לגופים ציבוריים ולסוחרי מידע. במקומה נכנסה חובת הודעה לרשות על מאגר שמכיל מידע בעל רגישות מיוחדת על יותר מ-100,000 אנשים.
בתמורה קיבלה הרשות להגנת הפרטיות סמכויות אכיפה מנהליות: לבצע ביקורות, לדרוש מסמכים, להטיל עיצומים כספיים בעצמה ולפנות לצו שיפוטי שיורה על הפסקת עיבוד או מחיקת מידע. זו החלפה של מסלול פלילי איטי במסלול מנהלי מהיר. פחות טפסים, יותר שיניים.
2. ההגדרות התרחבו — וזה משנה מה נחשב "אצלכם"
"מידע אישי" כולל היום גם מידע שמזהה אדם בעקיפין או במאמץ סביר. "עיבוד" מכסה כמעט כל פעולה: איסוף, שמירה, העתקה, עיון, גילוי, העברה ומתן גישה. וקטגוריית המידע בעל הרגישות המיוחדת התרחבה גם היא.
ההשלכה ההנדסית ישירה: טבלת אירועים עם מזהה מכשיר, לוגים עם כתובות IP, אירועי אנליטיקס עם מזהה משתמש קבוע — כל אלה מידע אישי, גם אם אין בהם שם. ההנחה שנפוצה בצוותי פיתוח, שדאטה בלי שם ואימייל הוא דאטה אנונימי, לא נכונה.
3. ממונה הגנת פרטיות
לראשונה נקבעה בחקיקה חובת מינוי ממונה הגנת פרטיות, החלה על גופים ציבוריים, סוחרי מידע, ארגונים שעיסוקם העיקרי כולל עיבוד מידע בעל רגישות מיוחדת בהיקף ניכר, וארגונים שעוסקים במעקב שיטתי אחר אנשים בהיקף ניכר. הרשות נתנה ארכה באכיפה עד 31 באוקטובר 2025.
הממונה יכול להיות עובד או שירות חיצוני, אסור שיכהן בתפקיד שיוצר ניגוד עניינים, והוא מדווח למנכל או למי שכפוף לו ישירות. סטארטאפ עם מאגר לקוחות רגיל בדרך כלל לא נכנס להגדרה. מוצר דיגיטלי בתחום הבריאות, מוצר שמנטר עובדים או משתמשים, ופלטפורמה שמעבדת מידע רגיש בהיקף — כן צריכים לבדוק את זה, ולא בעל פה.
4. חשיפה אזרחית, לא רק רגולטורית
תקופת ההתיישנות בתביעות פרטיות הוארכה משנתיים לשבע, ובחלק מהמקרים אפשר לתבוע בלי להוכיח נזק. בשילוב עם תביעות ייצוגיות, זה משנה את פרופיל הסיכון של מוצר עם מאגר לקוחות גדול — ולא רק מול הרשות.
מה זה אומר בקוד: שמונה דברים שאני בודק
מיפוי דאטה שמישהו באמת החזיק ביד
מסמך אחד שאומר איזה שדות אישיים נשמרים, באיזו טבלה, למה, כמה זמן, ומי בצוות יכול לגשת אליהם. בלי זה אי אפשר לענות על שום שאלה אחרת, וזו גם השאלה הראשונה שתישאלו בביקורת. אצל רוב הלקוחות שביקשנו מהם את המסמך הזה, החלק שהפתיע היה כמה שדות נאספים בלי שאף אחד יודע למה.
מינימיזציה — לא לאסוף מה שלא צריך
כל שדה במסד הנתונים הוא התחייבות. אם אתם אוספים תאריך לידה מלא בשביל לדעת אם המשתמש מעל 18, אתם מחזיקים מידע רגיש יותר משאתם צריכים. שמירת בוליאני במקום תאריך מוחקת סיכון שלם.
יידוע שכתוב בעברית של בני אדם
החובה היא ליידע את מי שנותן את המידע מה נאסף, לאיזו מטרה, למי הוא עלול לעבור ומה זכויותיו — בשלב האיסוף, לא בקישור למדיניות פרטיות בת 4,000 מילה בפוטר. משפט אחד ברור מתחת לשדה בטופס ההרשמה עושה כאן יותר מאשר עשרה עמודים משפטיים.
מחיקה שבאמת מוחקת
כשמשתמש מבקש למחוק את המידע שלו, צריך שיהיה תהליך — ושהוא יטפל גם בעותקים: גיבויים, לוגים, מערכת התמיכה, כלי האנליטיקס, וכל אינטגרציה שהעתיקה את הדאטה לאנשהו. מחיקה שמסמנת שורה כלא-פעילה ומשאירה את הנתונים במקום היא לא מחיקה, וזה ההבדל בין שעה של פיתוח לבין יומיים.
הצפנה ובקרת גישה
הצפנה במנוחה ובתעבורה, הרשאות לפי תפקיד ולא גישה כללית לכל הצוות, ואימות דו-שלבי לפאנל הניהול. תקנות הגנת הפרטיות בנושא אבטחת מידע מגדירות רמות אבטחה לפי סוג המאגר והיקפו, והן לא בוטלו בתיקון — הן דווקא קיבלו שיניים.
לוגים שמאפשרים לענות "מה בדיוק קרה"
כשיש אירוע, השאלה הראשונה היא איזה רשומות נגעו ומי ניגש אליהן. בלי לוג גישה מסודר אין תשובה, ובלי תשובה אי אפשר לדווח כראוי ולא להוכיח את היקף האירוע. זו אחת ההשקעות שנראות מיותרות עד היום שבו הן היחידות שמשנות.
נוהל דיווח שכתוב מראש
אחרי המקרה של מאוחדת זה כבר לא תיאורטי. צריך מסמך של חצי עמוד: מי מזהה, למי מודיעים בתוך החברה, מי מחליט שזה אירוע מדווח, מי מדווח לרשות ותוך כמה זמן, ומתי מודיעים למשתמשים. בזמן אמת אף אחד לא מאלתר טוב.
ספקים — כולל ספקי AI
כל שירות חיצוני שנוגע בדאטה הוא חלק מהחשיפה שלכם: אחסון, שליחת מיילים, כלי תמיכה, אנליטיקס וספק המודל. מול כל אחד צריך להיות ברור מה נשלח, איפה זה נשמר, כמה זמן, והאם הוא מתחייב לא לאמן על הנתונים. את ההיבטים הטכניים של שליחת דאטה למודל חיצוני פירטנו במאמר על שילוב AI במערכת קיימת, ואת הסעיפים שצריכים להופיע בחוזה מול הספק — כאן.
מה נדרש ממי, בקצרה
| סוג הגוף | רישום מאגר | הודעה לרשות | ממונה הגנת פרטיות |
|---|---|---|---|
| אפליקציה או SaaS עם מאגר לקוחות רגיל | לא נדרש | לא נדרש | בדרך כלל לא |
| מאגר עם מידע רגיש במיוחד על מעל 100,000 איש | לא נדרש | נדרש | לבדוק — סביר שכן |
| מוצר שמעבד מידע רגיש בהיקף ניכר (בריאות, פיננסים) | לא נדרש | לפי היקף | נדרש |
| מוצר שמנטר אנשים באופן שיטתי בהיקף ניכר | לא נדרש | לפי היקף | נדרש |
| גוף ציבורי או סוחר מידע | נדרש | נדרש | נדרש |
הטבלה היא כיוון, לא פסיקה. ההגדרות של "היקף ניכר" ושל "עיסוק עיקרי" הן בדיוק המקום שבו צריך עורך דין ולא בלוג.
שלושה דגלים אדומים שראיתי במערכות קיימות
- לוגים שנשמרים לנצח. "אנחנו לא מוחקים לוגים, מי יודע מתי נצטרך" זה משפט נפוץ ומסוכן. לוג עם מזהי משתמשים הוא מאגר לכל דבר, וללא מדיניות שמירה הוא רק גדל.
- גישת דיבוג לפרודקשן שהיא גישה מלאה. ברוב הסטארטאפים שראיתי, כל מפתח יכול לשלוף כל רשומה. זה לא נדרש כדי לתקן באגים, וזה החשיפה הגדולה ביותר שקיימת בפועל.
- מדיניות פרטיות שהודבקה מאתר אחר. אם היא מזכירה שירותים שאתם לא משתמשים בהם או לא מזכירה את אלה שכן, היא לא מגינה עליכם — היא רק מתעדת שלא בדקתם.
שורה תחתונה
אם אתם בונים מוצר חדש, כל מה שכתוב כאן עולה מעט מאוד כשעושים אותו מההתחלה: מיפוי דאטה, מחיקה אמיתית, לוגים והרשאות הם ימי עבודה בודדים בתוך פרויקט. אם המוצר כבר חי, זה פרויקט קטן בפני עצמו — וזול בהרבה מהחלופה.
אצלנו זה חלק מהאפיון של כל מערכת SaaS או מערכת ניהול שאנחנו בונים, ולא סעיף שמוסיפים בסוף. אם יש לכם מערכת קיימת ואתם לא בטוחים איפה אתם עומדים, כתבו לנו — נסתכל על הארכיטקטורה ונגיד לכם בכנות מה חסר, גם אם התשובה היא שאתם בסדר.
נכתב על ידי אביתר אדלר, CTO ב-FlowDev. המאמר מתאר את ההיבטים ההנדסיים ואינו מהווה ייעוץ משפטי. נכון לאוגוסט 2026.
