מתי ספק נחשב "מחזיק" – ומתי צריך להוסיף אותו למסמך הגדרות המאגר

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