סיכוני ספקי צד שלישי בארגון – Third-Party Risk Management

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

בדיוק כאן מתחיל Third-Party Risk Management.

Third-Party Risk הוא הרבה יותר משרשרת אספקה

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

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

• מחלקת השיווק מחזיקה מידע על לקוחות בפלטפורמת Marketing Automation
• מחלקת המכירות משתמשת ב-CRM
• המחלקה המשפטית מעלה חוזים ומסמכים לשירותי SaaS
• הכספים עובדים עם מערכות Billing, Expenses או FinTech
• HR משתמשת בפלטפורמות גיוס, שכר וניהול עובדים
• הנהלה עשויה לנהל מידע רגיש באמצעות מערכות Collaboration, BI או Board Management

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

CISA מגדירה Third-Party Risk Management כניהול סיכוני סייבר הקשורים לשירותים ולנכסים התלויים בגורמים חיצוניים. כלומר, Third Party יכול להיות ספק, נותן שירות, שותף עסקי או גורם אחר שהארגון תלוי בו.

איך CISA מסתכלת על Third-Party Risk Management?

בתפיסה של CISA, Third-Party Risk Management אינו מסתכם בבדיקת אבטחה חד־פעמית של ספק לפני חתימת חוזה.

מדובר ביכולת ארגונית לזהות, להעריך ולנהל לאורך זמן סיכוני סייבר הנובעים מתלות בגורמים חיצוניים, בשירותים שהם מספקים ובנכסים שעליהם הארגון מסתמך.
המשמעות רחבה הרבה יותר מספקי IT מסורתיים:
מערכת SaaS של מחלקת הכספים, שירות HR בענן, פלטפורמת Marketing Automation, משרד חיצוני שמקבל גישה למידע או ספק שירות מנוהל, כולם יכולים להפוך ל-Third Party משמעותי מבחינת הסיכון.

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

ספק SaaS הוא צד שלישי לכל דבר

המעבר ל-SaaS יצר שינוי משמעותי במודל הסיכון.

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

במודל SaaS, הספק עשוי:

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

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

לכן השאלה אינה רק:

“האם המוצר טוב?”

אלא:

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

לפעמים, ספק שיווק יכול להיות רגיש לא פחות מספק IT

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

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

שיווק

מערכות CRM, דיוור, Marketing Automation, Webinar ו-Analytics עשויות להחזיק שמות, כתובות דוא"ל, התנהגות לקוחות והיסטוריית אינטראקציות.

משפטית

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

כספים

מערכות Billing, Expense Management, ERP, תשלומים או FinTech עשויות להחזיק מידע פיננסי, פרטי ספקים וחשבונות.

HR

מערכות גיוס, שכר, נוכחות, הערכת עובדים ו-HR SaaS מעבדות לעיתים מידע אישי רגיש במיוחד.

מכירות

CRM וכלי Sales Enablement מחזיקים מידע על לקוחות, הזדמנויות, מחירים, חוזים ותחזיות.

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

Shadow SaaS: כשהספק נכנס לארגון בלי לעבור דרך אבטחת מידע

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

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

כך נוצר Shadow SaaS.

הבעיה אינה רק חוסר שליטה בתקציב.

ייתכן שהספק:

• לא עבר בדיקת אבטחה
• אינו עומד בדרישות פרטיות
• מאחסן מידע במדינות שלא נבדקו
• מאפשר התחברות ללא MFA
• משתמש בספקי משנה
• שומר מידע לאחר סיום ההתקשרות
• או מחזיק הרשאות רחבות מהנדרש

לכן Third-Party Risk Management – TPRM – ניהול סיכוני צד שלישי אפקטיבי צריך להתחיל עוד לפני הרכישה.

מידע נוסף על SHADOW IT

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

בישראל קיימת גם זווית רגולטורית ברורה.

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

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

המשמעות חשובה במיוחד בעולם SaaS:

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

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

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

מידע נוסף על:

• הגנת פרטיות
• רגולציה ותקינה
• שירות DPO – מנהל הגנת הפרטיות במיקור חוץ של אינפוגארד.

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

לא כל ספק צריך לעבור תהליך זהה.

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

לכן השלב הראשון הוא Risk Classification.

כדאי להבין:

• איזה מידע הספק יקבל?
  מידע ציבורי, עסקי פנימי, אישי, פיננסי או רגיש?
• איזו גישה תהיה לו?
  מערכת מבודדת, API, SSO, חשבון Admin או גישה לתשתיות?
• כמה הארגון תלוי בו?
  האם תקלה של שעה היא אי־נוחות או השבתה עסקית?
• האם הוא מעבד מידע עבורנו?
• האם קיימים ספקי משנה?
• מה יקרה אם הספק עצמו ייפגע מאירוע סייבר?

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

שאלון ספקים הוא רק התחלה

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

השאלון חשוב, אבל הוא אינו התהליך כולו.

התשובה “אנחנו ISO 27001 certified” אינה בהכרח מספיקה כדי להבין את הסיכון המסוים לארגון.

צריך להתאים את הבדיקה לספק.

מידע על תזכיר פרטיות לספקים – PIA

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

• ניהול זהויות ו-MFA
• הצפנה
• הרשאות Administrators
• Logging ו-Audit
• הפרדת לקוחות
• Backup ו-Recovery
• Incident Notification
• Vulnerability Management
• מיקום ועיבוד המידע
• ספקי משנה
• Retention ומחיקה
• BCP
• תהליכי סיום התקשרות

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

גם החוזה הוא בקרת אבטחה

בדיקת הספק לפני הרכישה היא שלב אחד.

השלב הבא הוא לתרגם את הדרישות להתחייבויות.

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

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

• חובת דיווח על Incident
• זמני Notification
• שימוש בספקי משנה
• זכויות Audit
• חובת מחיקה או החזרת מידע
• שמירת לוגים
• BCP ו-DR
• סיום גישה
• ודרישות אבטחה ספציפיות

זה המקום שבו Security, Procurement, Legal ו-Privacy צריכים לעבוד יחד.

הסיכון לא נגמר ביום חתימת החוזה

אחת הנקודות החשובות ב-Third-Party Risk Management היא ש-Vendor Assessment אינו אירוע חד־פעמי.

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

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

לכן תוכנית TPRM צריכה לכלול גם Ongoing Monitoring.

ומה קורה כשספק חווה אירוע סייבר?

זו השאלה שבאמת בוחנת את הקשר בין Third-Party Risk לבין Incident Response.

• הארגון עצמו לא נפרץ.
• אבל ספק מרכזי מודיע שהוא חווה Incident.
• האם המידע שלנו הושפע?
• האם יש לספק Token או API שעדיין פעילים?
• האם צריך לאפס Credentials?
• האם השירות העסקי ימשיך לעבוד?
• האם קיימת חובת דיווח?
• מי אחראי לדבר עם הספק?
• האם הספק בכלל מחויב למסור לנו את המידע בזמן שנדרש?

זו הסיבה שתרחיש ספק חיצוני צריך להיות חלק גם מ-Incident Response Plan ומתרגילי Tabletop.

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

ספק SaaS קריטי הוא גם סוגיית BCP

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

נניח שה-CRM אינו זמין יום שלם.

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

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

או שפלטפורמת Customer Support אינה זמינה.

הארגון צריך לשאול:

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

לכן Third-Party Risk אינו רק Cybersecurity.

הוא מתחבר ישירות ל-Business Continuity המשכיות עסקית.

מידע נוסף במאמר: BCP או DRP? שני המסמכים שכל ארגון צריך.

הספק של הספק הוא גם חלק מהתמונה

בעולם SaaS, ספק כמעט אף פעם אינו פועל לבד.

מערכת אחת יכולה להסתמך על ספק Cloud, שירות דוא"ל, שירות Authentication, כלי Analytics וספק Support חיצוני.

אלו הם Subprocessors או Fourth Parties.

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

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

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

Offboarding: המקום שבו הרשאות נשכחות

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

כאשר מפסיקים לעבוד עם ספק צריך לוודא:

• שהחשבונות בוטלו.
• שה-API Keys או Tokens הוסרו.
• שחיבורי SSO בוטלו.
• שהמידע הוחזר או נמחק בהתאם להסכם.
• שספקי משנה אינם ממשיכים להחזיק עותקים.
• ושהאחריות לשימור מידע לצרכים עסקיים או משפטיים ברורה.

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

Offboarding הוא בקרת אבטחה.

מי אחראי על Third-Party Risk?

התשובה אינה “מחלקת אבטחת מידע”.

ניהול ספקים יעיל דורש חלוקת אחריות:

• Business Owner – למה אנחנו צריכים את הספק ומה תהיה ההשפעה אם ייכשל?
• Procurement – כיצד נרכש השירות ומהם התנאים המסחריים?
• IT / Security – אילו חיבורים, הרשאות וסיכוני סייבר קיימים?
• Privacy / DPO – איזה מידע אישי מעובד ומהן דרישות הפרטיות?
• Legal – האם החוזה משקף את הדרישות והסיכונים?
• BCP – מה קורה אם השירות אינו זמין?
• הנהלה / Risk – האם רמת הסיכון מקובלת?

TPRM טוב אינו טופס שמעבירים ל-CISO לאישור, הוא תהליך ארגוני.

מודל פשוט לניהול ספקים לאורך חיי ההתקשרות

אפשר לחשוב על התהליך בחמישה שלבים:

1. Discovery

לדעת אילו ספקים ומערכות SaaS קיימים בכלל.

2. Classification

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

3. Due Diligence

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

4. Contract & Monitoring

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

5. Offboarding

לסגור גישה, להסדיר מידע ולוודא שהתלות הסתיימה.

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

7 שאלות שכדאי לשאול על ספק SaaS חדש

1. איזה מידע אנחנו עומדים להעלות אליו?
2. אילו הרשאות או אינטגרציות יקבל?
3. האם השירות קריטי לפעילות העסקית?
4. מי הם ספקי המשנה המרכזיים שלו?
5. כיצד ומתי הוא מתחייב לדווח על Incident?
6. כיצד נקבל את המידע שלנו בחזרה אם נפסיק לעבוד איתו?
7. מי בארגון אחראי לבחון מחדש את הסיכון בעוד שנה?

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

מ-Vendor Questionnaire ל-Third-Party Risk Management

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

בדיוק להפך.

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

NIST פרסם במהלך 2026 כלים חדשים שמחזקים בדיוק את הגישה הזו: SP 800-18 Rev. 2 מדגיש תכנון משולב של Security, Privacy ו-Cybersecurity Supply Chain Risk Management, ו-SP 1326 נותן מסגרת מעשית יותר לביצוע Due Diligence על ספקים.

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

כיצד אינפוגארד יכולה לסייע?

אינפוגארד מסייעת לארגונים לבנות ולשפר תהליכי Third-Party Risk Management, לרבות מיפוי וסיווג ספקים, בניית שאלוני אבטחת מידע לפי רמות סיכון, ביצוע Vendor Assessments, בחינת ספקי SaaS, הגדרת דרישות אבטחה ופרטיות ובחינת התאמה לתקנה 15.

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

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

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

Third-Party Risk Management: הסיכון של הספקים שלא תמיד נמצאים ברשימת הסיכונים

Third-Party Risk אינו מוגבל לספקים שמייצרים מוצרים או משתתפים בשרשרת אספקה. בעולם SaaS, גם מערכת שיווק, HR, כספים או Legal יכולה להחזיק מידע רגיש ולהפוך לתלות עסקית משמעותית.
ניהול נכון של הסיכון דורש בחינה לפני ההתקשרות, הגדרה חוזית, Monitoring במהלך השירות ו-Offboarding מסודר בסיום.
הגישה הנכונה אינה לשאול רק “האם הספק מאובטח?”, אלא “מה המשמעות עבור הארגון שלנו אם הספק הזה ייפגע, ייכשל או ישנה את אופן הפעולה שלו?”

מקורות

• הרשות להגנת הפרטיות, מדריך פעולה ליישום תקנה 15 לתקנות הגנת הפרטיות (אבטחת מידע) בעת התקשרות עם גורם חיצוני, נוסח מעודכן בעקבות תיקון 13.
• הרשות להגנת הפרטיות, שאלות ותשובות בנושא תקנות הגנת הפרטיות (אבטחת מידע), עודכן 4.3.2026.
• NIST, SP 1326 – Cybersecurity Supply Chain Risk Management: Due Diligence Assessment Quick-Start Guide, יולי 2026.
• NIST, SP 800-18 Rev. 2 – Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems, יוני 2026.
• NIST, SP 800-161 Rev. 1 – Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, עדכון נובמבר 2024.
• CISA, Cybersecurity Capability Maturity Model – Third-Party Risk Management.

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

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

המאמר נכתב בשיתוף מומחי אבטחת המידע והסייבר של Infoguard מקבוצת IDOR, ונערך בעזרת בינה מלאכותית ואנושית על ידי רועי קיש, חובב פרטיות, אבטחת מידע, סייבר ומנהל שיווק בקבוצת חברות עידור (Messagenet, Infoguard, Idornext).