ב-16 בספטמבר 2026 הודיעה הרשות להגנת הפרטיות שהטילה עיצום כספי של 64,000 ש"ח על עיריית בית שמש. לא בגלל פריצה – בגלל תקלה במערכת GIS שהפעיל בשבילה ספק חיצוני, שחשפה לציבור מידע רפואי ונתוני רווחה של כ-4,600 תושבים. מעבר לאירוע עצמו, הרשות קבעה שם משהו שרלוונטי לכל עסק שעובד עם ספקים: ספק שמעבד מידע אישי בעבורכם – למשל מאחסן אותו, מפעיל מערכת שמכילה אותו, או מקבל אליו גישה כחלק משירות שבמסגרתו מתבצע עיבוד המידע – עשוי להיחשב "מחזיק" במאגר. אם פעולות העיבוד באמצעותו ופרטי המחזיק אינם מתועדים כנדרש במסמך הגדרות המאגר, או שההתקשרות איתו אינה מוסדרת כנדרש בנוהל ובהסכם, עשויה להיות כאן הפרה גם בלי קשר לאירוע אבטחה.

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

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

מתי ספק נחשב "מחזיק" במאגר המידע שלכם

ההגדרה הזו רלוונטית לישראל ולחוק הגנת הפרטיות, התשמ"א-1981, בנוסחו המעודכן לאחר תיקון 13 (בתוקף מ-14 באוגוסט 2025). לפי סעיף 3 לחוק, "מחזיק" במאגר מידע הוא גורם חיצוני לבעל השליטה במאגר המידע, המעבד בעבורו מידע. "בעל שליטה" הוא מי שקובע, לבדו או ביחד עם אחר, את מטרות עיבוד המידע במאגר.

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

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

מה כדאי לבדוק עכשיו – רשימת בדיקה קצרה

הדרך הכי יעילה למפות את הספקים היא לא לנסות להיזכר בכולם בבת אחת, אלא לעבור מחלקה-מחלקה או מערכת-מערכת: הנהלת חשבונות, שירות לקוחות, שיווק, IT. בכל אחת מהן שאלו איזה כלים וספקי חוץ מופעלים בפועל – תוכנת CRM, כלי דיוור, מערכת הנהלת חשבונות, ספק אחסון, מתכנת חוץ, מערכת ייעודית כמו GIS אם קיימת אצלכם. מהניסיון שלי, לא פעם הרשימה ארוכה יותר ממה שנדמה בהתחלה.

1. רשימת ספקים – כתבו רשימה של כל הספקים שיש להם גישה למערכת שמחזיקה מידע אישי על לקוחות, עובדים או נרשמים, בהתאם למיפוי שלמעלה.
2. מה כל ספק עושה בפועל – לכל ספק ברשימה, בדקו: האם הוא מעבד מידע אישי בעבורכם כחלק מהשירות – למשל מאחסן אותו, מפעיל מערכת שמכילה אותו, או צופה בו באופן קבוע? משך ותדירות הגישה שלו יכולים לחזק את התשובה, אבל השאלה המרכזית היא אם הוא בכלל גורם חיצוני שמעבד מידע בעבורכם.
3. מה כתוב בהסכם – אם השירות של הספק כרוך בגישה למאגר המידע שלכם, בדקו אם חלה על ההתקשרות תקנה 15, והאם ההסכם מסדיר את הנושאים שהיא דורשת: מטרות העיבוד, סוגי המידע המותרים, מערכות הגישה, משך ההתקשרות, והתחייבות לדווח על אירועי אבטחה. זה נבדק בנפרד מהשאלה אם הספק הוא "מחזיק" – תקנה 15 חלה על גורם חיצוני עם גישה למאגר, לא רק על מי שהוגדר כמחזיק.
4. מה מעדכנים במסמך ובנוהל – אם הספק נחשב מחזיק, ודאו שפעולות העיבוד שלו ופרטיו מתועדים כנדרש במסמך הגדרות המאגר (בסעיף שעוסק בגורם חיצוני/מחזיק), ושנוהל אבטחת המידע שלכם מסדיר את תנאי ההתקשרות איתו – לא רק בהפניה כללית להסכם, אלא בציון מטרות השימוש, סוגי המידע ומערכות הגישה, כפי שהרשות דרשה במקרה של בית שמש.

זה לא קורה רק לרשויות ציבוריות

קל לקרוא את המקרה של בית שמש ולחשוב "זה רלוונטי לרשויות ציבוריות עם מערכות GIS, לא לעסק שלי". זו טעות. ב-26 בספטמבר 2026 לקוחות של מיטב טרייד קיבלו קודי אימות חד-פעמיים (OTP) בהודעות SMS שהם לא ביקשו. הבדיקה שבוצעה העלתה שהמידע נחשף דרך ממשק API של ספק חיצוני – כ-3,000 לקוחות נפגעו, ומהמידע שחלץ הגורם החיצוני ניתן היה לשלוף שם מלא, מספר תעודת זהות ומספר חשבון בנק (מקור: ביזפורטל, כלכליסט). החברה חסמה את הגישה לממשק, ולפי הודעתה לא הייתה גישה לכספי הלקוחות, למערכות המסחר או לסיסמאות.

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

הטענות שהעירייה השמיעה – ולמה הרשות דחתה אותן

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

• "הספק לא היה בגדר מחזיק" – הרשות קבעה שהוא כן, על רקע אופי השירות, עיבוד המידע שבוצע במסגרתו והגישה המתמשכת למערכות המאגר. אם ההנחה שלכם היא "זה סתם ספק טכני, הוא לא 'מחזיק' במובן המשפטי" – זו בדיוק ההנחה שהרשות דחתה. השאלה היא אם הספק מעבד מידע בעבורכם, לא איך הוא מגדיר את עצמו.
• "ההפרה נבעה מפער מנהלי בתום לב, בסמיכות לכניסת תיקון 13 לתוקף" – גם זה נדחה. הרשות קבעה שהיה על העירייה להיערך ולעמוד בדרישות החוק והתקנות במועד, ושלא ניתן להסתפק בנוהל רוחבי כללי ובהפניה להסכמים חיצוניים בלבד. "עדיין לא הספקנו להתעדכן" אינו פוטר מהחובה עצמה.

סיכום

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

The post מתי ספק נחשב "מחזיק" – ומתי צריך להוסיף אותו למסמך הגדרות המאגר appeared first on MindfulWebNerd.

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

אין אתר מאובטח ב-100%, יש אתר שקשה יותר לפרוץ

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

למה אתרי וורדפרס נפרצים, בקצרה

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

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

הבסיס: הרגלים שמגנים יותר מכל כלי

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

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

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

שכבה ראשונה, לפני האתר: Cloudflare בחשבון החינמי

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

מה מקבלים בחינם

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

• הגנה מהתקפות הצפה (DDoS), כלומר ניסיון להפיל אתר בכמות עצומה של בקשות. Cloudflare מצהירים על הגנה ללא הגבלה ובלי מדידת שימוש, בכל החבילות, כולל החינמית. לדעתי זה היתרון הכי משמעותי: בתעבורה שעוברת דרך Cloudflare, ההצפה יכולה להיבלם אצלם לפני שהיא מגיעה לשרת שלכם.
• חומת אש בסיסית (WAF), מערכת שבודקת כל בקשה ומחפשת ניסיונות פריצה מוכרים: סט חוקים מנוהל מצומצם נגד פרצות נפוצות ומשמעותיות (הסט המלא בתשלום), עד 5 חוקים משלכם (למשל הגבלת גישה לעמוד ההתחברות לפי תנאים שהגדרתם), וחוק אחד להגבלת קצב בקשות, עם חלון של 10 שניות ולפי כתובת IP בלבד. שימושי, אבל בסיסי.
• סינון בוטים עם Bot Fight Mode, שמזהה תנועה שמתאימה לדפוסים מוכרים של בוטים ומציב לה אתגר.
• תעודת SSL חינמית (ההצפנה שמאחורי המנעול בשורת הכתובת) לחיבור שבין הגולשים ל-Cloudflare, ש-Cloudflare מנפיקים ומחדשים אוטומטית.
• האצה לקבצים סטטיים (תמונות, קבצי עיצוב, סקריפטים) דרך שרתים ברחבי העולם, מה שנקרא CDN. דפי ה-HTML עצמם לא נשמרים כברירת מחדל, כך שהשיפור במהירות חלקי. אם האתר איטי, כדאי קודם לדעת איך בודקים מה באמת מאט את אתר הוורדפרס שלכם.
• Turnstile, חלופה חינמית ל-CAPTCHA שמסננת ספאם בטפסים בלי לבקש מהגולשים לזהות רמזורים. אפשר להשתמש בה גם בלי להעביר את כל האתר דרך Cloudflare.

מה חשוב לדעת לפני שמחברים

החשבון החינמי טוב, אבל יש לו גם צדדים פחות נוחים:

• תלות בשירות חיצוני. תקלה אצלם היא תקלה אצלכן. ב-18 בנובמבר 2025, למשל, גולשים באתרים רבים שעוברים דרך Cloudflare קיבלו דפי שגיאה במשך כמה שעות. לפי הדוח שפרסמה Cloudflare, הסיבה הייתה שינוי הגדרות פנימי, לא מתקפה. גם לחברות אחסון יש תקלות, אבל זו עוד חוליה בשרשרת.
• שתי הגדרות שיכולות לשבור דברים. מצב SSL שנקרא Flexible משאיר את החיבור בין Cloudflare לשרת שלכן לא מוצפן, ו-Cloudflare עצמם ממליצים לא להשתמש בו באתרים עם פרטים אישיים או התחברות. ו-Bot Fight Mode עלול לחסום גם תנועה לגיטימית של ממשקי API (חיבורים אוטומטיים בין מערכות), ואי אפשר להחריג אותו בחוקים. אם אתן מפעילות אותו בחנות, בדקו שאישורי תשלום מחברת הסליקה עדיין מגיעים.
• ניהול ה-DNS עובר ל-Cloudflare. בדרך כלל מעבירים אליהם את ניהול הגדרות הדומיין, כך שחיבור מייל או אימות מול גוגל נעשים מעכשיו שם.
• אפשר לעקוף את ההגנה. מי שיודע מה כתובת ה-IP האמיתית של השרת יכול לפנות אליו ישירות ולדלג על Cloudflare. הם עצמם ממליצים לבדוק את זה.
• פרטיות. כל התנועה לאתר, כולל כתובות IP של גולשים, עוברת דרכם. אני ממליץ לציין את Cloudflare ברשימת נותני השירות במדיניות הפרטיות. לגבי עוגיות, Cloudflare מגדירים את העוגיות שלהם כנחוצות לפעולת השירות, אלא אם מצוין אחרת.

שכבה שנייה, על שרת האתר: תוסף אבטחה כמו Wordfence

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

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

ומה חסר בגרסה החינמית: לפי עמוד התוסף, חוקי חומת האש וחתימות הנוזקות מגיעים אליה באיחור של 30 יום לעומת הגרסה בתשלום. חסימת מדינות ורשימת IP זדוניים בזמן אמת שמורות גם הן לגרסה בתשלום. זה לא הופך את הגרסה החינמית לחסרת ערך, אבל כשזמן הניצול של פרצות נמדד בשעות, כדאי לדעת את זה. וגם: בניגוד ל-Cloudflare, הבקשה כבר הגיעה לשרת שלכם לפני ש-Wordfence יכול לחסום אותה.

Cloudflare, Wordfence, או שניהם?

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

האם שני הכלים מתנגשים?

בדרך כלל לא, והשילוב נפוץ. אבל יש שתי נקודות חיכוך מוכרות שכדאי לבדוק אחרי החיבור:

• זיהוי כתובת ה-IP של הגולשים. כשהאתר עובר דרך Cloudflare, השרת רואה כברירת מחדל את כתובת ה-IP של Cloudflare, והכתובת האמיתית של הגולש מגיעה בנפרד. אם Wordfence לא מוגדר לקרוא אותה, הוא עלול לחסום או להגביל את Cloudflare עצמו במקום את התוקף, כלומר לפגוע בגולשים אמיתיים, והיומנים שלו יציגו כתובות לא נכונות. ב-Wordfence יש הגדרה ייעודית לזה (How does Wordfence get IPs), עם אפשרות לקרוא את הכתובת האמיתית מהכותרת ש-Cloudflare מוסיפים. ודאו שהיא מוגדרת.
• Cloudflare חוסם את Wordfence. חלק מהפעולות של Wordfence מתבצעות דרך פנייה של האתר לעצמו. הגדרות אבטחה ב-Cloudflare, כולל Bot Fight Mode, עלולות לחסום את הפניות האלה ולפגוע בסריקות, ו-Wordfence אפילו הוסיף זיהוי ייעודי למצב הזה (גרסה 7.10.5). אם אחרי החיבור Wordfence מתריע על תקלה בסריקה או בחומת האש, זה המקום הראשון לבדוק.

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

חלופות נוספות

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

מה הכלים האלה לא עושים

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

מי מחזיק במפתחות של האתר?

נתקלתי כבר בלקוחות שלא ידעו אם האתר שלהם בכלל מחובר ל-Cloudflare. וגם כשהתברר שכן, אף אחד לא ידע איפה פרטי הכניסה ומי מנהל את החשבון. וכשהגיעה מתקפה, לקח זמן עד שאפשר היה להיכנס לחשבון ולהפעיל את מצב "Under Attack", מצב חירום שמוסיף בדיקת אבטחה לפני הכניסה לאתר.

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

• פתחו את החשבונות על כתובת המייל של העסק, לא על המייל הפרטי של מי שבנה את האתר.
• את איש המקצוע הוסיפו כחבר בחשבון (או כמשתמש נפרד באחסון ובוורדפרס), במקום לתת לו את הסיסמה שלכן.
• הפעילו אימות דו-שלבי, ושמרו את פרטי הכניסה במנהל סיסמאות.
• דעו איפה נמצא מצב Under Attack ב-Cloudflare. הוא נועד לשימוש זמני בזמן מתקפה בלבד, כי הוא מציב בדיקה גם לגולשים אמיתיים ומשפיע על נתוני האנליטיקס.

אז איך לאבטח את אתר הוורדפרס שלכם? לפי המצב

השורה התחתונה

אבטחת אתר וורדפרס היא לא כלי אחד, אלא שכבות: הבסיס (עדכונים, סיסמאות, מעט תוספים וגיבויים), שכבה לפני האתר כמו Cloudflare החינמי, ושכבה על השרת עצמו כמו Wordfence. אף אחת מהן לא נותנת הגנה של 100%, אבל יחד הן מקשות מאוד על פריצה. ואם אתם עושים דבר אחד היום: בדקו מי מחזיק בחשבונות של האתר שלכם, ואיפה פרטי הכניסה. ביום של מתקפה, זה מה שיקבע כמה מהר תוכלו להגיב.

The post איך לאבטח אתר וורדפרס: Cloudflare, Wordfence, ומה שום כלי לא עושה במקומכם appeared first on MindfulWebNerd.

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

לגבי הדין החל: הפוסט מתייחס לחוק הגנת הפרטיות הישראלי, תשמ"א-1981, ולשני תיקונים בו – תיקון 9 משנת 2007 (שהוסיף את סעיף 29א) ותיקון 13 משנת 2025 (שהוסיף את סעיף 15א ונכנס לתוקף באוגוסט 2025). 

מה זה בעצם "פיצוי ללא הוכחת נזק"?

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

המסלול הראשון: הפרות ספציפיות לפי סעיף 15א (תיקון 13)

תיקון 13 (מאוגוסט 2025) הוסיף בסעיף 15א אפשרות לפיצוי של עד 10,000 ש"ח ללא הוכחת נזק, בגין רשימה מוגדרת של הפרות שהחוק מונה – לא בגין "פגיעה בפרטיות" במובן הקלאסי שאני מסביר בהמשך. חשוב לדעת: לחלק מההפרות האלה יש תנאים מקדימים, ולכן לא כל הפרה מזכה אוטומטית בפיצוי. כמה דוגמאות:

• מאגר שחייב ברישום ולא נרשם, בכפוף לתנאים שקובע הסעיף.
• הפרת זכות העיון לפי סעיף 13 – לא לאפשר לאדם לראות מידע שקיים עליו אצלכם.
• הפרות מסוימות של החובות הנוגעות לתיקון מידע לפי סעיף 14.

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

המסלול השני: פגיעה "קלאסית" בפרטיות (סעיף 29א)

לצד המסלול שתואר למעלה, קיים גם המסלול הוותיק יותר: העוולה של פגיעה בפרטיות שבפרק א' לחוק הגנת הפרטיות, מ-1981. האפשרות לפסוק פיצוי ללא הוכחת נזק בגין הפגיעה הזו נוספה לחוק מאוחר יותר – בתיקון 9 משנת 2007, בסעיף 29א. סעיף 2 לחוק מונה שורה של מצבים שנחשבים לפגיעה בפרטיות – בין היתר: צילום אדם במקום פרטי, פרסום תמונה שעלולה להשפיל, שימוש בשם או בתמונה של מישהו למטרות רווח בלי רשות, הפרת חובת סודיות, ושימוש במידע אישי למטרה שונה מזו שלשמה הוא נמסר.

אילו מצבים נכנסים לקטגוריה הזו?

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

מתי החוק כן מגן עליכם

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

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

מצבים נפוצים שחושפים עסקים קטנים

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

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

מה עושים כדי לצמצם את החשיפה

זה לא דורש הפיכה למומחי פרטיות – בעיקר סדר:

• תהליך מסודר לבקשות עיון ותיקון, עם זמן תגובה קבוע – גם אם זה רק "מי אחראי לענות ותוך כמה זמן".
• בדיקה חד-פעמית האם המאגרים שלכם חייבים ברישום.
• הרשאות גישה מצומצמות – עובד צריך גישה רק למידע שרלוונטי לתפקיד שלו, ורק למטרה שלשמה הוא נאסף.
• בדקו מי מקבל את המידע מחוץ לעסק – ספקי משנה, כלי דיוור, שירותי משלוחים – וודאו שזה מתועד ומוזכר במדיניות הפרטיות.
• הסכמה מדעת ותקפה. החוק מכיר גם בהסכמה מכללא, אבל במצבים רגישים – פרסום תמונה, עדות, שימוש בשם – עדיף הסכמה מפורשת ובכתב על פני הסתמכות על צ'קבוקס גנרי בתקנון.
• בדקו את מיקום המצלמות, את נחיצות הצילום ואת היידוע. שילוט הוא חלק מהתהליך, לא פתרון בפני עצמו.

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

סיכום

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

לא בטוחים מה מכל זה חל עליכם? בואו נבדוק יחד – שיחת היכרות קצרה בלי התחייבות. דברו איתי

The post פיצוי ללא הוכחת נזק בחוק הגנת הפרטיות: מתי זה אפשרי, ואיך עסק קטן נמנע מזה appeared first on MindfulWebNerd.

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

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

לא רק ציוד משרדי – למה שעון ביומטרי הוא סיפור אחר

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

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

מה קבע בית הדין לעבודה על טביעות אצבע במקום העבודה

מה הרשות להגנת הפרטיות מצפה מעסקים שמשתמשים במערכת ביומטרית

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

הסכמה אמיתית מול הסכמה בלית ברירה

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

למה חלופה לא-ביומטרית היא מרכיב כל כך משמעותי

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

מעבר לזה, כדאי:

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

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

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

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

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

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

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

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

לסיכום

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

לא בטוחים מה בדיוק חל על העסק שלכם? בואו נבדוק יחד – שיחת היכרות קצרה בלי התחייבות. דברו איתי

The post שעון נוכחות ביומטרי בעסק: מתי זה חוקי ומה צריך כדי לעשות את זה נכון appeared first on MindfulWebNerd.

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

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

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

פרטיות עובדים בעסק: גם מאגר העובדים שלכם כפוף לחוק

חוק הגנת הפרטיות לא מבחין בין "מידע על לקוחות" ל"מידע על עובדים". אחרי תיקון 13, ההגדרה של מאגר מידע היא אוסף פרטי מידע אישי המעובד באמצעי דיגיטלי – בכפוף לשני חריגים מצומצמים, וביניהם אוסף שכולל רק שם, מען ודרכי התקשרות, על עד 100,000 בני אדם, בתנאים שקבועים בחוק. גיליון האקסל עם פרטי כל העובדים שלכם, מערכת השכר, ותוכנת ניהול משאבי האנוש כוללים בדרך כלל הרבה יותר מזה – תעודת זהות, שכר, נוכחות ולעיתים גם מידע רפואי – ולכן במקרה הטיפוסי הם עונים על ההגדרה של מאגר מידע, בדיוק כמו רשימת הלקוחות שלכם.

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

מה יש בכלל ב"מאגר העובדים" שלכם

זה לא מאגר אחד אחיד – זה כמה סוגי מידע שונים, עם רמות רגישות שונות:

לא כל מידע "רגיש" הוא "מידע בעל רגישות מיוחדת"

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

אז מה בעצם החוק מצפה מכם לעשות

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

מסמך הגדרות מאגר ורמת אבטחה

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

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

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

אחרי תיקון 13 חובת הרישום צומצמה משמעותית – וגם כשיש במאגר מידע בעל רגישות מיוחדת, כמו ברוב מאגרי העובדים, זה לא אומר אוטומטית שהוא חייב ברישום. חובת הרישום חלה בעיקר על מאגר שמטרתו העיקרית היא איסוף מידע כדי למסור אותו לאחר, כדרך עיסוק או בתמורה, ובו מידע על יותר מ-10,000 בני אדם – או כשבעל השליטה במאגר הוא גוף ציבורי. גם לגוף ציבורי יש חריג מפורש למאגר שמכיל מידע רק על העובדים שלו. במילים אחרות: מאגר עובדים פנימי רגיל של עסק פרטי קטן או בינוני, שמשמש לניהול העסק ולא להעברת מידע לאחרים, בדרך כלל אינו חייב ברישום רק בגלל שיש בו שכר, מידע רפואי, או מספר מסוים של עובדים. יש כן מקרה נפרד שכדאי להכיר: אם מאגר שאינו חייב ברישום כולל מידע בעל רגישות מיוחדת על יותר מ-100,000 בני אדם, קיימת חובת הודעה לרשות להגנת הפרטיות. זו חובה נפרדת מחובת הרישום. כתבתי מדריך מלא על חובת רישום מאגר שעוזר לעבור על הקריטריונים המדויקים – הוא נכתב מנקודת מבט של מאגר לקוחות, אבל אותם קריטריונים חלים גם על מאגר עובדים.

שני נושאים חמים: נוכחות ביומטרית ועבודה מרחוק

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

נוכחות ביומטרית

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

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

מעקב אחר עובדים בעבודה מרחוק

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

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

מה זה לא – הגבול מול דיני עבודה

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

לסיכום

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

לא בטוחים מה חל עליכם? בואו נבדוק יחד – שיחת היכרות קצרה בלי התחייבות.

The post פרטיות עובדים: גם מאגר העובדים שלכם כפוף לחוק הגנת הפרטיות appeared first on MindfulWebNerd.

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

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

מה קרה בפועל: הבקשה לייצוגית נגד מימון ישיר, והבקשה השנייה שהצטרפה אליה

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

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

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

מתי מידע שעובר דרך פיקסל נחשב מידע אישי?

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

מה הרשות להגנת הפרטיות כבר קבעה על הסכמה

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

הסכמה פעילה מול הסכמה פסיבית

גילוי הדעת מבחין בין שני מנגנונים: הסכמה פעילה (Opt-In), פעולה מפורשת כמו סימון תיבה או לחיצה על "אני מסכים", לעומת הסכמה פסיבית (Opt-Out), שבה השימוש מתאפשר כברירת מחדל אלא אם המשתמש פועל כדי לחסום אותו. לפי עמדת הרשות, שתיקה או אי התנגדות אינן מספיקות כשמדובר בשימושים מסוימים.

מתי חובה דווקא הסכמה פעילה

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

מקרה בודד, או מגמה שמתחילה להצטבר?

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

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

איך בודקות אילו פיקסלים רצים באתר שלכן

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

• פתחו את האתר שלכן בדפדפן כרום, לחצו קליק ימני ובחרו "בדוק" (Inspect), עברו ללשונית Network, רעננו את הדף וחפשו בקשות לכתובות כמו facebook.com, tiktok.com או google-analytics.com.
• בדקו את חשבון או הגדרות Google Tag Manager, אם האתר משתמש בו: שם מרוכזים חלק מהפיקסלים, אבל לא כולם, יש כלים שמוטבעים ישירות בקוד, בתוסף, בתבנית או בפלטפורמת פרסום.
• אם האתר בוורדפרס, בדקו את רשימת התוספים הפעילים: לא פעם פיקסל מגיע דרך תוסף שיווק או תוסף אנליטיקס שהותקן ונשכח.
• אם משהו מהזה לא ברור, שלחו את כתובת האתר למפתח או ליועצת שעובדת איתכן ובקשו רשימה פשוטה: אילו סקריפטים חיצוניים טוענים, ולאן הם שולחים מידע.

מה צריך לבדוק ולתקן

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

1. מה חובת היידוע וההסכמה בנקודת האיסוף. צריך לוודא שהמשתמש מקבל את היידוע הנדרש בזמן ובמקום המתאימים, ובמקרים שבהם נדרשת הסכמה פעילה, לפני שהפיקסל מתחיל לפעול. בהתאם למה שהפיקסל עושה בפועל, לפעמים הודעה ברורה מספיקה, ולפעמים נדרשת הסכמה פעילה. כתבתי בהרחבה על כך שמדיניות פרטיות לבדה לא תמיד מספיקה כתחליף להודעה בנקודת האיסוף עצמה.
2. שקיפות במדיניות הפרטיות. מדיניות הפרטיות צריכה לשקף בצורה ברורה את השיתוף שמתבצע בפועל, כולל סוגי הגורמים שמקבלים מידע ומטרות השיתוף.
3. הקשר המשפטי עם הגורם שמקבל את המידע. כאן צריך זהירות: לא כל צד שלישי הוא אוטומטית "מחזיק" במידע כמשמעותו בתיקון 13, ולא כל העברה כפופה לתקנה 15. תקנה 15 רלוונטית כשגורם חיצוני מעבד מידע בשם העסק, כמו ספק שמנהל מערכת בשבילכם, לא כברירת מחדל לכל שיתוף מידע עם כל גורם חיצוני. כתבתי על העיקרון הזה, שרלוונטי כשמדובר בהעברה לספק שפועל בשמכם, בפוסט על תקנה 15 והעברת מידע לספקים חיצוניים. מה שנכון לגבי טיקטוק או פייסבוק ספציפית תלוי באיך בפועל בנוי השילוב הטכני, ולא ניתן להניח את זה מראש.

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

סיכום

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

לא בטוחים מה חל עליכם? בואו נבדוק יחד: שיחת היכרות קצרה בלי התחייבות.

The post פיקסלים באתר שלכם: מה חייבים לגלות למשתמשים, ולמה זה כבר לא תיאורטי appeared first on MindfulWebNerd.

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

במאמר הזה אני עובר איתכם על שני החלקים: איך מחברים אתר ל-Search Console ומאמתים אותו נכון, ואיך בודקים – בפועל, לא בניחוש – שהנתונים באמת נאספים.

מה זה Google Search Console ולמה חיבור אליו חשוב

Search Console הוא כלי חינמי של גוגל שמראה איך האתר שלכן מתפקד בחיפוש האורגני – אילו מילות חיפוש מביאות אליו תנועה, אילו עמודים מאונדקסים (כלומר, נכנסים למאגר של גוגל ומופיעים בתוצאות), ואם יש בעיות טכניות שמונעות מדפים להופיע. בלי לחבר אתר לכלי הזה, אתן עובדות על SEO בעיניים עצומות – אתן לא יודעות מה עובד ומה לא.

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

שלב 1: איזה סוג נכס לבחור – Domain או URL-prefix

כשמוסיפים אתר ל-Search Console, יש שני סוגי נכסי אתר עיקריים לבחור ביניהם:

נכס מסוג Domain מכסה את כל הגרסאות של הדומיין – עם www ובלעדיו, http ו-https, ואפילו תת-דומיינים. הדרך היחידה לאמת נכס כזה היא באמצעות רשומת DNS אצל ספק הדומיין שלכם.

נכס מסוג URL-prefix מכסה רק את הכתובת המדויקת שהזנתם (למשל https://example.co.il/). הוא תומך בכמה שיטות אימות שונות, כולל תג HTML, קובץ להעלאה, או תוסף וורדפרס.

אם יש לכם גישה נוחה ל-DNS – למשל דרך פאנל הניהול של ספק הדומיין – נכס מסוג Domain נותן כיסוי מלא יותר, כי הוא מכסה בבת אחת את כל הגרסאות של הכתובת. אם אתם מעדיפים את הדרך הפשוטה ביותר להתחיל בלי לגעת ב-DNS, נכס מסוג URL-prefix עם אימות דרך תוסף וורדפרס הוא פתרון מצוין. אפשר תמיד להוסיף בהמשך גם את הסוג השני, לאותו אתר ולאותו חשבון גוגל.

שלב 2: איך מוסיפים ומאמתים את הנכס

הדרך הכי נוחה לבעלי אתרי וורדפרס: תוסף

אם כבר מותקן אצלכן תוסף SEO כמו Yoast SEO או All in One SEO, כמעט תמיד יש בו שדה שנקרא "Webmaster Tools" או "כלי מנהל אתרים". שם אפשר להדביק את קוד האימות שגוגל נותן, בלי לגעת בקבצי האתר בעצמכן.

אפשרות נוחה נוספת היא Site Kit by Google – תוסף וורדפרס רשמי של גוגל שמחבר בבת אחת Search Console, Google Analytics ועוד כלים, ומבצע את תהליך האימות אוטומטית דרך התחברות לחשבון גוגל.

לאחר שהדבקתם את הקוד או השלמתם את החיבור דרך Site Kit, לוחצים על "אמת" (Verify) ב-Search Console.

אימות דרך רשומת DNS (לנכס מסוג Domain)

אם בחרתן בנכס מסוג Domain, גוגל ייתן לכן רשומת TXT להוספה בפאנל הניהול של הדומיין (למשל אצל הרשם שממנו קניתן את הדומיין). זו הפעולה הכי טכנית במדריך, ואם אתן לא בטוחות איפה לערוך רשומות DNS – זה בדיוק המקום שבו כדאי לבקש עזרה, כדי לא לגעת בהגדרות אחרות של הדומיין בטעות.

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

שלב 3: מגישים מפת אתר (Sitemap)

מפת אתר (sitemap) היא קובץ שמפרט את כל העמודים שאתם רוצים שגוגל יכיר. אתרי וורדפרס עם תוסף SEO יוצרים אותה אוטומטית, בדרך כלל בכתובת כמו /sitemap_index.xml או /sitemap.xml.

בתוך Search Console, נכנסים לתפריט "אינדוקס" ואז "מפות אתר", מדביקים את כתובת ה-sitemap ולוחצים "שליחה".

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

איך יודעים שהנתונים באמת נאספים – לא רק ש"אומת"

כמה זמן זה אמור לקחת

הנקודה שכדאי לדעת: גוגל מתחיל לאסוף נתונים על נכס כבר מהרגע שהוא נוסף ל-Search Console – עוד לפני שהאימות עצמו הושלם. אבל גם כשהאיסוף כבר רץ, יכול לקחת כמה ימים עד שמתחילים לראות בפועל נתונים בדוח. בנוסף, גם כשכבר יש נתונים, קיים בדרך כלל פער של יומיים-שלושה בין הפעילות בפועל בחיפוש לבין הרגע שבו היא מופיעה בדוח הביצועים (Performance) – כך לפי התיעוד הרשמי של גוגל. לכן לוח בקרה ריק מיד אחרי החיבור אינו בהכרח סימן לתקלה. אם עברו כמה ימים ואין שום נתון, שווה להתחיל בכמה בדיקות בסיסיות (ראו בהמשך).

בדיקה עם כלי בדיקת כתובות URL

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

אם מופיעה ההודעה שהכתובת נמצאת ב-Google, אתם יודעים שהעמוד הזה כבר נמצא באינדקס של Google. זה לא אומר בהכרח שכבר יהיו לו קליקים או חשיפות בדוח הביצועים – זה נתון נפרד לגמרי – אבל זו אינדיקציה חשובה לכך שאין בעיית אינדוקס בסיסית בעמוד. אם הכתובת אינה נמצאת ב-Google, הסתכלו קודם על הסיבה שמופיעה ישירות בתוצאת כלי בדיקת כתובות URL – הוא בדרך כלל מסביר למה. לאחר מכן שווה לבדוק גם שמפת האתר נקלטה בהצלחה (באותו מסך "מפות אתר" מהשלב הקודם – עמודת הסטטוס אמורה להראות "הצליח") ושאין חסימה של העמוד.

מה עושים אם אחרי כמה ימים עדיין לא רואים כלום

אם עברו כמה ימים, מפת האתר מוצגת כ"הצליח", וכלי בדיקת כתובות URL עדיין מחזיר שהעמוד לא נמצא ומציין סיבה כמו חסימת אינדוקס – הבעיה כנראה כבר לא בחיבור ל-Search Console עצמו, אלא במשהו שמונע מגוגל לאנדקס את האתר: הגדרת "חסום אינדוקס" שנשארה דלוקה מתקופת הפיתוח, קובץ robots.txt שחוסם, או בעיה בקוד עצמו. זו שאלה רחבה יותר, וכתבתי עליה מדריך נפרד עם עשר בדיקות שעוברות מהפשוט למורכב: הצ'ק-ליסט המלא לבדיקת אינדוקס.

סיכום

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

רוצות שמישהו יבדוק את זה בשבילכן? שלחו לי את כתובת האתר ואחזור עם אבחון ראשוני.

The post איך לחבר אתר ל-Google Search Console ולוודא שהנתונים באמת נאספים appeared first on MindfulWebNerd.

באוגוסט 2026 התפרסמו שני אירועים נפרדים שבהם פרצת מידע לא קרתה אצל העסק עצמו, אלא אצל ספק שהחזיק את המידע בשמו. חברת הארנקים הדיגיטליים Trezor דיווחה שהספק שמטפל עבורה במשלוחים, ShipMonk, נפרץ וחשף פרטים של עשרות אלפי לקוחות – היקף שגדל משמעותית בעדכון מאוחר יותר, כפי שאפרט בהמשך. במקביל, Valve הודיעה על פרצת מידע אצל ספק המשלוחים האירופי שלה, CEVA Logistics, שחשפה פרטי לקוחות שהזמינו חומרת Steam.

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

מה קרה בפועל – שני מקרי פרצות מידע אצל ספקים ב-2026

Trezor ו-ShipMonk

ב-10 באוגוסט 2026 הודיעה Trezor שהספק שלה, ShipMonk, נפרץ. בהודעה הראשונה דיברה החברה על כ-13,689 לקוחות שנפגעו – שמות מלאים, טלפונים, מיילים וכתובות משלוח עבור רוב הלקוחות שנפגעו, וחשיפה חלקית עבור השאר. אבל בתחילת ספטמבר 2026 עדכנה Trezor את ההודעה: התברר שבמערכות ShipMonk נשמר גם מידע ישן משמעותית יותר – פרטים של כ-67,000 לקוחות אמריקאים נוספים מהתקופה שבין נובמבר 2019 לאוגוסט 2021 – כך שהיקף הפגיעה גדל לכ-80,689 לקוחות בסך הכול. הנקודה החשובה מבחינתנו: לפי Trezor, היא קיבלה בעבר מ-ShipMonk אישורים בכתב שהמידע הישן הזה נמחק. בפועל הוא לא נמחק. לפי הודעת Trezor, המערכות שלה עצמה וארנקי החומרה נשארו בטוחים, והחברה פנתה ללקוחות באזהרה מפני ניסיונות פישינג.

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

Valve ו-CEVA Logistics

בין ה-29 ביולי ל-1 באוגוסט 2026 נפרצה CEVA Logistics, שמטפלת במשלוחי חומרת Steam באירופה עבור Valve, ובעקבות זאת נחשפו שמות, כתובות, טלפונים, מיילים ופרטי הזמנה – לא פרטי תשלום, סיסמאות או קודי Steam Guard. Valve גילתה את האירוע ב-7 באוגוסט 2026, שלחה הודעות ללקוחות ב-10 באוגוסט, ופנתה לרשויות הגנת הפרטיות באירופה.

מתי ספק חיצוני נכנס לתמונה של תקנה 15

תקנה 15 חלה על כל "גורם חיצוני" – כך היא מכנה ספק (שאינו אדם יחיד) שנותן לעסק שירות הכרוך במתן גישה למאגר המידע שלו. אחסון, CRM שמכיל פרטי לקוחות, כלי דיוור שמחזיק רשימת תפוצה, ספק סליקה, מערכת ניהול תורים, ואפילו יועץ שמקבל גישה למערכות שלכם – כל אלה יכולים להיחשב גורם חיצוני, בהתאם לשירות שהוא נותן בפועל.

חשוב לדייק: החובות הספציפיות של תקנה 15 כלפי גורמים חיצוניים חלות מרמת אבטחה בסיסית ומעלה, ולא על "מאגר המנוהל בידי יחיד", כהגדרת המונח בתקנות. תקנה 15 היא לא תוספת של תיקון 13 – היא חלק מתקנות אבטחת המידע משנת 2017, שקיימות כבר כמה שנים. תיקון 13 הוסיף בעיקר את סמכות האכיפה והקנסות של הרשות להגנת הפרטיות, לא את החובה עצמה. אם אתם רוצים את התמונה המלאה של תקנות אבטחת המידע ולא רק את הזווית של ספקים חיצוניים, המדריך המלא לתקנות אבטחת המידע הוא נקודת ההתחלה הטובה.

לפני שחותמים – מה בודקים קודם

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

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

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

לפי תקנה 15, ההסכם עם ספק חיצוני צריך לכלול נקודות ספציפיות:

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

הנקודה האחרונה שווה הרחבה. תקנה 15(א)(2)(ח) עצמה קובעת שההסכם חייב לכלול התחייבות של הגורם החיצוני לדווח לכם לפחות אחת לשנה על עמידתו בהתחייבויות, ולהודיע לכם במקרה של אירוע אבטחה – בלי לקבוע לוח זמנים מפורש להודעה הזו. מבחינה מעשית, מומלץ מאוד לקבוע בחוזה שההודעה תימסר מיד או בתוך פרק זמן קצר ומוגדר: כך תוכלו לעמוד בלוחות הזמנים שלכם מול הרשות להגנת הפרטיות, ששם כן יש דרישה לדיווח מיידי במקרה של אירוע חמור (על כך בהמשך).

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

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

זה לא נגמר בחתימה – הפיקוח השוטף

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

מתגלה פרצת מידע אצל הספק – מה זה אומר עליכם

תקנות אבטחת המידע מחייבות לתעד כל אירוע שמעלה חשש לפגיעה במידע – שימוש ללא הרשאה או חריגה מהרשאה, או פגיעה בשלמות המידע. זה סף נמוך יחסית: "מעלה חשש", לא ודאות. וכפי שהוסבר למעלה, כשהגורם החיצוני הוא גם מחזיק, חובת התיעוד הזו לא חלה רק עליכם – היא חלה גם עליו, מכוח תקנה 19(א). אם המאגר שלכם ברמת אבטחה בינונית או גבוהה, ואירוע כזה אכן קרה בפועל, נכנסת חובת דיווח לרשות להגנת הפרטיות – באופן מיידי, כלשון התקנה. אין בישראל חלון זמן קבוע כמו 24 או 72 שעות; הדרישה היא לדווח מיד כשמתגלה האירוע. פירטתי את כל התנאים והחריגים במדריך נפרד על מתי חובה לדווח על אירוע אבטחה.

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

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

סיכום

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

לא בטוחים מה חל עליכם? בואו נבדוק יחד – שיחת היכרות קצרה בלי התחייבות.

The post פרצת מידע אצל הספק שלכם – זו עדיין הבעיה שלכם appeared first on MindfulWebNerd.

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

The post איך מטפלים בבקשה לעיון, תיקון או מחיקת מידע אישי באתר וורדפרס appeared first on MindfulWebNerd.

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

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

קודם כול – מי בכלל מחליט על בניית אתר או מערכת לעמותה?

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

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

התקציב לא עובד כמו בעסק

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

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

תוכניות תמיכה אמיתיות שכדאי להכיר

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

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

המידע שאתם שומרים הוא לא "רק רשימת תפוצה"

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

לא כל עמותה חייבת למנות ממונה על הגנת הפרטיות (DPO – מי שמייעץ לארגון ומפקח על ניהול הגנת הפרטיות) – החובה תלויה בסוג הפעילות ובהיקף המידע, ולא כל עמותה נכנסת לקריטריונים. אבל כדאי לבדוק את זה מוקדם, ולא אחרי שכבר קיבלתם תרומות דרך האתר במשך שנה. אם יש לכם מאגר כזה, איך בונים מסמך הגדרות מאגר הוא נקודת התחלה מעשית, ואם אתם לא בטוחים אם החובה חלה עליכם, מדריך למינוי ממונה על הגנת הפרטיות מסביר מתי זה רלוונטי.

מה קורה כשהוועד מתחלף?

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

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

מתי אתם בכלל לא צריכים מערכת מותאמת אישית

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

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

אז מה עושים עכשיו

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

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

The post בניית אתר לעמותה: מה באמת שונה בפרויקט טכנולוגי לעמותה appeared first on MindfulWebNerd.