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

באוגוסט 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 בכלל חלה על ההתקשרות – ובמקרים שבהם היא כן חלה, לוודא שיש הסכם שמכסה את הנקודות שעברנו עליהן כאן.

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