Fourth-Party Risk: בדקתם את הספק, אבל מי בדק את הספקים שלו?

את הספק בדקתם. הוא ענה על שאלון אבטחה, הציג ISO 27001 והחוזה כולל סעיפי Incident Notification. אבל מי מפעיל את תשתית הענן שלו? מי מספק את שירות ה-AI? מי מטפל ב-Support ומי עוד מקבל גישה למידע?
בעולם SaaS, הספק שאנחנו מתקשרים איתו הוא לעיתים רק השכבה הראשונה.

מהו Fourth-Party Risk?

Third Party הוא ספק או נותן שירות שהארגון מתקשר איתו ישירות.

Fourth Party הוא גורם שהספק שלנו מסתמך עליו לצורך מתן השירות.

לדוגמה:

• הארגון משתמש בפלטפורמת SaaS
• הפלטפורמה משתמשת ב-AWS
• היא נעזרת בשירות Authentication חיצוני
• חלק מה-Analytics מועברים לספק נוסף
• ופיצ'ר חדש מסתמך על API של Generative AI

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

זהו Fourth-Party Risk.

למה הסיכון הזה גדל בעולם SaaS?

שירותי SaaS מודרניים מורכבים לעיתים מעשרות רכיבים ושירותים חיצוניים.

המודל הזה מאפשר לפתח מוצרים במהירות, אבל הוא גם מייצר תלות.

ספק SaaS יכול להסתמך על:

• Cloud Infrastructure
• Authentication
• Email Delivery
• Payment Processing
• Data Analytics
• CDN
• Customer Support
• AI APIs
• Backup
• Monitoring
• שירותי Development ו-DevOps

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

Fourth-Party Risk אינו רק סיכון אבטחה

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

אבל הסיכון יכול להתבטא גם ב:

• Availability – שירות של הספק מושבת בגלל תקלה אצל Cloud Provider.
• Privacy – מידע מועבר ל-Subprocessor נוסף.
• Compliance – ספק משנה פועל באזור גיאוגרפי שלא נלקח בחשבון.
• Incident Response – זמן הדיווח מתעכב כי הספק עצמו ממתין למידע מהגורם שמאחוריו.
• BCP – מספר ספקים משתמשים למעשה באותה תשתית, ולכן קיימת Concentration Risk.
• AI – מידע עובר לשירות חיצוני כחלק מיכולת AI שהתווספה למוצר.

לכן Fourth-Party Risk הוא שילוב של Cyber, Privacy, Operational Risk ו-Business Continuity.

NIST כבר מכניס את שכבות הספקים לתוך הבדיקה

NIST SP 1326 מגדיר Supply Chain Tiers כאחד מחמשת הרכיבים המרכזיים ב-Due Diligence של ספקי ICT, לצד FOCI, Provenance, Resilience ו-Foundational Cyber Practices. כלומר, בבדיקת ספק יש חשיבות גם להבנת השכבות שמאחוריו ולא רק לישות שאיתה הארגון חותם חוזה.

גם פרויקט C-SCRM של NIST ממקם את SP 1326 כחלק מהמסגרת הרחבה של SP 800-161 Rev. 1, שמטרתה לנהל סיכוני סייבר לאורך שרשרת המוצרים והשירותים.

תקנה 15: גם ספק המשנה נכנס לתמונה

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

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

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

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

צריך לשאול גם:

“על מי הספק שלנו מסתמך כדי לעמוד בהן?”

מהו Subprocessor?

בעולם הפרטיות וה-SaaS נפוץ המונח Subprocessor.

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

לדוגמה:

• מערכת HR משתמשת בספק Cloud לאחסון הנתונים.
• מערכת Marketing משתמשת בשירות Email Delivery.
• מערכת Legal Tech שולחת חלק מהמידע לשירות AI.
• הספק הישיר הוא זה שאיתו הארגון התקשר, אך Subprocessor עשוי לקבל בפועל חלק מהמידע.

לכן רשימת Subprocessors היא מקור מידע חשוב ב-Vendor Assessment.

האם צריך לבדוק כל ספק של הספק?

לא, וזו נקודה חשובה.

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

גם כאן נדרשת גישה מבוססת סיכון.

כדאי להתמקד ב:

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

המטרה אינה להגיע ל-Infinite Vendor Assessment.

המטרה היא להבין את התלויות המהותיות.

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

במסגרת Vendor Assessment כדאי להוסיף מספר שאלות ממוקדות:

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

השאלות האלה מאפשרות להבין האם הספק מנהל בעצמו Third-Party Risk ולא רק אם הוא מאובטח פנימית.

Concentration Risk: כאשר הרבה ספקים תלויים באותו גורם

Fourth-Party Risk יוצר גם סיכון מערכתי פחות ברור.

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

במקרה כזה, קיימת Concentration Risk.

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

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

מי הספקים שלנו?

אלא:

באילו תשתיות משותפות הספקים שלנו תלויים?

זהו חיבור ישיר לתוכנית המשכיות עסקית – BCP ול-Cyber Resilience.

Fourth-Party Risk ו-Incident Response

תרחיש ספק משנה צריך להיכנס גם לתוכנית Incident Response.

לדוגמה:

ספק SaaS מודיע שאחד מה-Subprocessors שלו נפגע.

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

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

מידע נוסף על Incident Response

תרגיל Tabletop צריך לכלול גם תרחיש ספק

תרגיל Tabletop טוב לא חייב להתחיל בפריצה לרשת הארגונית.

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

“ספק SaaS קריטי דיווח שאחד מספקי התשתית שלו חווה אירוע אבטחה.”

ומכאן לבדוק:

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

תרחיש כזה בודק בפועל את החיבור בין TPRM, Incident Response ו-BCP.

מידע נוסף על תרגילי שולחן בסייבר ואבטחת מידע

גם AI מגדיל את שכבת ה-Fourth Party

אחד השינויים המהירים ביותר כיום הוא שילוב AI בתוך שירותי SaaS קיימים.

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

לכן כאשר ספק מוסיף יכולות AI כדאי להבין:

• מי מספק את המודל
• איזה מידע נשלח אליו
• האם המידע נשמר
• האם הוא משמש ל-Training
• האם נוסף Subprocessor
• והאם תנאי ההתקשרות השתנו

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

Offboarding מורכב יותר כשיש כמה שכבות

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

אבל אם המידע עבר גם ל-Subprocessors, צריך להבין האם תהליך המחיקה חל גם עליהם.

לכן כדאי שההסכם והנהלים יתייחסו ל:

• מחיקת מידע אצל הספק.
• מחיקה אצל Subprocessors.
• סיום אינטגרציות.
• ביטול Tokens ו-API Keys.
• Retention.
• גיבויים.
• ואישור מתאים שהמידע אינו ממשיך להיות מעובד.

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

7 שאלות שכדאי לשאול על Fourth-Party Risk

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

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

מהספק שלנו לאקוסיסטם שלו

Third-Party Risk Management מתחיל בספק הישיר.

אבל בארגון מבוסס SaaS ו-Cloud, הוא לא יכול להסתיים שם.

ספקים הם חלק מאקוסיסטם.

הם משתמשים בתשתיות, שירותים, API, Subprocessors ושותפים נוספים.

לכן ניהול סיכונים בשל צריך לעבור מהשאלה:

“האם הספק שלנו מאובטח?”

לשאלה רחבה יותר:

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

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

אינפוגארד מסייעת לארגונים לבנות תהליכי Third-Party ו-Fourth-Party Risk Management, לרבות מיפוי ספקים, Vendor Assessments, בחינת Subprocessors, שאלוני אבטחת מידע, Due Diligence והערכת תלויות עסקיות וטכנולוגיות.

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

הספק של הספק הוא גם הסיכון שלכם: כך מנהלים Fourth-Party Risk

Fourth-Party Risk הוא הסיכון שנוצר מהגורמים שעליהם הספק שלנו מסתמך — Cloud, AI, Authentication, Analytics, Support וספקים נוספים. בעולם SaaS, שכבות אלה יכולות להשפיע על אבטחת מידע, פרטיות, זמינות ויכולת התאוששות.
הארגון אינו צריך לבדוק כל ספק משנה לעומק, אך כן צריך לזהות תלויות קריטיות, לדרוש שקיפות ולהבין כיצד הספק מנהל את הסיכון שלו.
המטרה היא לעבור מ-Vendor Assessment של ישות בודדת להבנה של האקוסיסטם שעליו השירות העסקי שלנו באמת נשען.

מקורות

NIST, SP 1326 – Due Diligence Assessment Quick-Start Guide, יולי 2026; המדריך כולל Supply Chain Tiers כאחד מרכיבי ה-Due Diligence.

NIST, פרויקט Cybersecurity Supply Chain Risk Management ומשאבי SP 800-161 Rev. 1.

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

את הספק בדקתם. הוא ענה על שאלון אבטחה, הציג ISO 27001 והחוזה כולל סעיפי Incident Notification. אבל מי מפעיל את תשתית הענן שלו? מי מספק את שירות ה-AI? מי מטפל ב-Support ומי עוד מקבל גישה למידע?
בעולם SaaS, הספק שאנחנו מתקשרים איתו הוא לעיתים רק השכבה הראשונה.

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

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

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