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

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

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

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

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

זו אינה רק סוגיה משפטית.

זו שאלה ניהולית שכל מנכ"ל צריך לדעת לענות עליה:

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

מה קרה בעיריית בית שמש?

ב־16 בספטמבר 2026 פרסמה הרשות להגנת הפרטיות את תוצאותיו של הליך בירור מנהלי שנערך בעקבות אירוע אבטחת מידע במערכת המידע הגיאוגרפית העירונית, GIS.

בעקבות תקלה במערכת התאפשרה גישה דרך אתר העירייה למידע אישי מתחום הרווחה על כ־4,600 תושבים.

המידע שנחשף כלל גם מידע רפואי בעל רגישות מיוחדת.

המערכת סופקה לעירייה באמצעות ספק חיצוני.

לאחר גילוי האירוע הושבתה המערכת ונחסמה הגישה למידע.

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

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

בסיום ההליך הוטל על העירייה עיצום כספי בסך 64,000 ש"ח. Gov.il

שתי ההפרות המרכזיות שנמצאו

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

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

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

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

"אבל הספק אחראי על המערכת"

את המשפט הזה שומעים לא מעט בארגונים.

ספק התוכנה אחראי על האפליקציה.

ספק ה־IT אחראי על השרתים.

חברת הענן אחראית על התשתית.

ספק הגיבוי אחראי על הגיבויים.

לכל אחד יש תחום אחריות מקצועי וחוזי.

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

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

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

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

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

זו גם הגישה המשתקפת במדריך הרשמי של הרשות להגנת הפרטיות להתקשרות עם ספקי מיקור חוץ. Gov.il

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

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

צריך לבחון את מהות השירות ואת הפעולות שמבוצעות במידע.

ספק IT שמנהל שרתים והרשאות

נניח שחברת IT חיצונית מתחזקת עבור ארגון שרתי Windows, סביבת Microsoft 365, מערכת ERP וגיבויים.

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

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

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

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

ספק SaaS שמאחסן נתוני לקוחות

נניח שהארגון משתמש במערכת CRM בענן.

המערכת כוללת פרטי לקוחות, היסטוריית התקשרויות, מסמכים והערות שירות.

ספק השירות מאחסן ומעבד את המידע לצורך מתן השירות.

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

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

ספק גיבוי

חברת גיבוי עשויה להחזיק עותק משמעותי של המידע הארגוני.

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

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

ספק שמוכר רישיונות בלבד

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

המסקנה היא שאין לקבוע את מעמד הספק לפי השם שלו או סוג החשבונית.

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

מה דורשת תקנה 15 לתקנות הגנת הפרטיות?

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

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

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

בדיקת סיכונים לפני ההתקשרות

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

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

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

זו אינה רק המלצה מקצועית.

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

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

תקנה 15(א)(2) מפרטת שמונה נושאים שיש להסדיר במפורש בהסכם, בשים לב לסיכוני ההתקשרות.

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

הסכם סודיות לבדו אינו מספיק

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

זו התחלה, אבל לא תחליף להסדרת כל הנושאים הרלוונטיים.

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

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

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

העיקר הוא שהתוכן המחייב אכן מוסדר.

האם מספיק לחתום על DPA?

לא.

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

מסמך ההתקשרות הוא רק חלק מתהליך הציות.

תקנה 15(א)(3) דורשת לכלול בנוהל האבטחה של המאגר את הנושאים הרלוונטיים שנקבעו בתקנה ולהפנות במפורש להסכם עם הספק ולנוהל האבטחה שלו.

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

כלומר, קיימים שלושה רכיבים שצריכים לעבוד יחד:

הסכם: מגדיר את חובות הצדדים.

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

בקרה: מאפשרת לבדוק שהדרישות מיושמות בפועל.

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

איך נראית בקרה אמיתית על ספק IT?

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

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

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

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

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

האם משתמשי הניהול מזוהים אישית?

האם נדרש MFA?

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

ומה קורה כאשר עובד של הספק עוזב?

השאלות האלה אינן מחייבות בהכרח רכישה של מערכת אבטחה נוספת.

הן מחייבות הגדרת אחריות וביצוע בדיקות.

1. זיהוי אישי של בעלי ההרשאות

ככל האפשר, נכון לתת לכל איש תמיכה זהות נפרדת.

שימוש בחשבון ניהול משותף מקשה על ייחוס פעולות לאדם מסוים.

2. הגבלת הרשאות

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

יש להגדיר את ההרשאות לפי הצורך המקצועי.

3. אבטחת הגישה מרחוק

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

בהתאם לסביבה ולסיכון, ניתן ליישם MFA, פתרונות גישה מנוהלת, הגבלת כתובות, גישה זמנית או מנגנוני PAM.

4. תיעוד פעולות

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

לוגים מאפשרים לבדוק פעילות חריגה ולתחקר אירועים.

5. בדיקה תקופתית

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

תקנה 15 אינה מחייבת באופן גורף להשתמש דווקא ב־PAM, ב־ZTNA או במוצר אבטחה מסוים.

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

מה לגבי ספקי SaaS וענן בינלאומיים?

כאן האתגר מורכב יותר.

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

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

זה לא אומר שאפשר להתעלם מהדרישות.

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

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

האם תקן ISO 27001 של הספק מספיק?

לא באופן אוטומטי.

הסמכה לתקן ISO 27001 עשויה לשמש ראיה חשובה לבקרות ולתהליכי אבטחת מידע.

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

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

ומה לגבי SOC 2?

דוח SOC 2 יכול לספק מידע מועיל על הבקרות שנבדקו אצל הספק.

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

מסמך אבטחה הוא ראיה לבקרה מסוימת.

הוא אינו מחליף את האחריות להבין את הסיכון.

האם הספק חייב לדווח על אירוע אבטחה?

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

מבחינה מקצועית הייתי מגדיר גם נוהל הסלמה ברור.

נניח שספק שירות מגלה שאחד מחשבונות הניהול שלו נפרץ.

ייתכן שבשלב הראשון אין לו תמונה מלאה של כל המערכות שהושפעו.

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

הוא צריך לקבל הודעה שתאפשר לו להתחיל לבחון את המשמעות עבורו.

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

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

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

לקריאה נוספת באתר SEC-IT: דיווח על אירוע אבטחה חמור – מה החוק דורש.

מה קורה כאשר הספק משתמש בספק משנה?

זהו סיכון שקל לפספס.

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

חברת התוכנה משתמשת בשירות ענן בינלאומי.

הענן עשוי להסתייע בספקי משנה נוספים.

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

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

אבל הארגון צריך להבין את שרשרת העיבוד הרלוונטית.

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

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

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

כאן יש הבחנה משפטית שחשוב להכיר.

תקנה 15(ג) קובעת כי הוראות התקנה אינן חלות על התקשרות של בעל מאגר עם יחיד.

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

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

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

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

איך בונים תהליך ניהול ספקים בארגון קטן או בינוני?

ארגון אינו חייב להתחיל מפרויקט ארוך ויקר.

אפשר להתחיל ממיפוי וממספר החלטות ברורות.

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

לא רק ספק ה־IT.

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

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

שלב שני: מי מהספקים נחשב למחזיק?

יש לבחון את מהות פעילות הספק בהתאם להגדרות הדין.

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

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

שלב שלישי: לבדוק את הסכמי ההתקשרות

לא להסתפק בכך שקיים חוזה.

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

שלב רביעי: לבדוק הרשאות בפועל

כאן נכנס הצד הטכנולוגי.

צריך לוודא שהגישה של הספק תואמת את השירות שהוא אמור לספק.

שלב חמישי: לקבוע מנגנון בקרה

יש להגדיר מי בארגון אחראי לבדוק את עמידת הספק בדרישות.

הבדיקה צריכה להיות מותאמת לסיכון.

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

שלב שישי: להסדיר את סיום ההתקשרות

זו אחת הנקודות החשובות ביותר.

כשמחליפים ספק IT, האם כל חשבונות הניהול שלו מבוטלים?

האם בוטלו חיבורי VPN, הרשאות ענן, משתמשי שירות ומפתחות גישה שאינם נדרשים עוד?

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

האם נותרו גיבויים אצל הספק?

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

איזה דוח הייתי מבקש ממנהל ה־IT ומה־DPO?

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

לא צריך בשלב הראשון מערכת GRC מורכבת.

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

זו תבנית מומלצת לניהול תהליך.

התקנות אינן מחייבות להשתמש דווקא בטבלה הזאת.

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

מי אחראי לניהול הסיכון?

מנהל ה־IT

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

מנהל אבטחת המידע

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

ממונה הגנת הפרטיות

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

הגורם העסקי האחראי להתקשרות

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

ההנהלה

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

החלוקה המדויקת תלויה במבנה הארגון.

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

להרחבה: מנהל אבטחת מידע כשירות – CISO as a Service.

האם תיקון 13 יצר את תקנה 15?

לא.

תקנה 15 היא חלק מתקנות הגנת הפרטיות (אבטחת מידע), התשע"ז–2017.

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

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

לכן חשוב להבחין בין מועד היווצרות החובה לבין השינוי ביכולת לאכוף אותה.

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

לקריאה נוספת: עיצומים כספיים בעקבות תיקון 13 – מה המשמעות לעסקים.

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

לא.

תקנה 15 אינה קובעת חובה כללית לבצע מבדק חדירה לכל ספק חיצוני.

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

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

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

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

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

מה לעשות אם אין לארגון תהליך ניהול ספקים?

לא הייתי מתחיל ברכישת תוכנה.

הייתי מתחיל במיפוי הספקים בעלי הגישה הרגישה ביותר.

לאחר מכן הייתי בודק שלושה דברים:

האם ההסכמים מתאימים לדרישות הדין?

האם ההרשאות בפועל תואמות את מה שהוסכם?

והאם מישהו בארגון בודק את הדברים האלה באופן שוטף?

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

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

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

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

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

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

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

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

ובעיקר, צריך לזכור:

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

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

מי אצלנו בארגון בדק לאחרונה את הרשאות הספקים ואת ההסכמים שלהם?

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

שאלות ותשובות נפוצות

האם ארגון אחראי לדליפת מידע שהתרחשה אצל ספק חיצוני?

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

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

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

האם חובה לחתום על הסכם DPA עם ספק חיצוני?

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

האם תקנה 15 חלה גם על ספק SaaS?

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

האם ספק שמאחסן גיבויים יכול להיחשב למחזיק?

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

האם תקן ISO 27001 פוטר מהדרישות החוזיות של תקנה 15?

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

האם חייבים לבצע ביקורת שנתית לכל ספק?

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

האם תקנה 15 חלה על פרילנסר עצמאי?

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

האם ספק חייב להודיע לארגון על אירוע אבטחה?

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

מה ההבדל בין אחריות ספק ה־IT לאחריות ה־CISO?

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

עידן צברי, יועץ אבטחת מידע והגנת פרטיות

מייסד SEC-IT, עם מעל 15 שנות ניסיון. משלב רקע משפטי (תואר במשפטים) עם ניסיון IT מבצעי ומומחיות סייבר (CISM, CISO), ומתמחה ביישום תיקון 13 והגנת פרטיות לעסקים קטנים ובינוניים. עוד על עידן ←